[webmasterbslnl]

1 year, 10 months 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 1 year, 10 months ago by wpsolr.

[wpsolr]

1 year, 10 months ago #30062

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

[wpsolr]

1 year, 10 months 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]

1 year, 10 months 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]

1 year, 10 months 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]

1 year, 8 months ago #30728

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

[wpsolr]

1 year, 8 months 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]

1 year, 8 months 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]

1 year, 8 months 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]

1 year, 8 months 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]

1 year, 8 months 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).