autocomplete_solr.js drives an endless reload loop in Chrome when url has #

  • webmasterbslnl
    Participant
    5 months, 1 week ago #30061

    Hi,
    We have an issue in Chrome (not in FF) where code in autocomplete_solr.js keeps reloading the page whenever a hash (#) is in the url.
    Steps to reproduce:
    – Go to https://www.(removed).nl/
    – Accept cookies (or not, its not relevant)
    – scroll down to “Beheer cookievoorkeuren” and click the link
    In your developer console you see and endless loop of page refreshes. For the end user is will seem as is you cannot scroll down the page, you keep returning to the top of the page.

    I found that om https://www.(removed).nl/content/plugins/wpsolr-pro/wpsolr/core/js/autocomplete_solr.js?ver=22.2 line 115 you register a listener on popevent. However, when an hashchange event occurs (junp to another location on same page where the location can be found after the # sign in the url) the popevent is fired too. Whether this is a Chromium bug or not I do not know but if you Google it you can find links hinting it may be so (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1254926). It may be that it is normal (in Chrome, in FF the same popevent is NOT fired). The result is that a reload is triggered further down autocomplete_solr.js. The reload triggers another popevent en there we are in an endless loop.

    I would like a solution for this problem. But as I have no idea why the event listener for popevent is there and what it is for I can’t fix it. For instance: setting is_show_url_parameters to false would break the loop but it will surely break some function of WPSolr too. Also I do not know where to set the value of that variable. Also, fiddling with the WPSolr code I would rather avoid. Do you have any ideas?

    Thanks for your help,
    Harmen

    • This topic was modified 5 months, 1 week ago by wpsolr.
    wpsolr
    Keymaster
    5 months, 1 week ago #30062

    I confirm your issue. For chrome, and Safari.
    Digging in the issue right now…

    wpsolr
    Keymaster
    5 months, 1 week ago #30063

    As a workaround, Line 114 you could add a condition to prevent ‘#’ urls to trigger the event:

    window.addEventListener("popstate", function (e) {
        if (wp_localize_script_autocomplete.data.is_show_url_parameters && !window.location.href.indexOf('#')) {
            call_ajax_search_timer(window.location.search, false, true);
        }
    });
    webmasterbslnl
    Participant
    5 months, 1 week ago #30064

    Thanks, you were quick to answer! I will implement it on our site. This will not break any functionality of WPSolr itself? Will you be adding it to the next version of the plugin?

    wpsolr
    Keymaster
    5 months, 1 week ago #30065

    It’s already part of the next release: https://trello.com/c/40zHUwhX/193-fix-url-with-hash-caracter-triggering-endless-popstate-events

    This code is about managing the back button history with WPSOLR Ajax. I can’t see this small fix breaking anything, but We will be sure only after all automated tests prior to next release.

    srhosting
    Participant
    2 months, 4 weeks ago #30728

    This is not fixed. We do have this issue with a client site on v22.3

    wpsolr
    Keymaster
    2 months, 4 weeks ago #30731

    As mentioned in our last answer, the fix had to pass automated tests. But it didn’t. We had to remove it.

    srhosting
    Participant
    2 months, 4 weeks ago #30734

    Thanks for clarification.
    It was not clear that it did break the tests from your answer, and looking at the roadmap, it was marked as completed for v.22.3.
    When can we expect the fix to be released and working ?
    The client site currently runs without search, as the plugin breaks the usability of the site.

    wpsolr
    Keymaster
    2 months, 4 weeks ago #30735

    Unfortunately, this is something we could not fix without breaking other WPSOLR features.
    It should only happen when the ‘(Deprecated) Use WPSOLR custom Ajax search templates’ search template option is selected on screen 2.1
    If you can, you should switch to your own theme archive loop template instead.

    srhosting
    Participant
    2 months, 4 weeks ago #30737

    Sorry, i cannot confirm.

    We have the following setting activated and see this issue happening:
    “Use my current theme search template with Ajax (with widget Facets and widget Sort)”

    wpsolr
    Keymaster
    2 months, 4 weeks ago #30740

    My mistake, nothing to do with the theme selected.

    It seems to be a Chrome bug (I just tested with Safari and Firefox).

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.