healow.com - Page become unresponsive when accessed

[jat-247]

URL: https://healow.com/apps/provider/thakur-allergyshot-1873706

Browser / Version: Firefox 103.0 Operating System: Windows 10 Tested Another Browser: Yes Chrome

Problem type: Site is not usable Description: Buttons or links not working Steps to Reproduce: When I click the link that opens this URL in a new tab it loads the contents of the page but when I go to try to interact with the page in any way (like selecting a radio button) Firefox tells me at the top "This page is slowing down Firefox. To speed up your browser, stop this page." with a "Stop" button. The page is completely frozen and I'm unable to interact with it at all unless I hit that "Stop" button that Firefox recommends. But after I click the "Stop" button, the functionality of the page doesn't work (probably because the page didn't fully load, or the scripts have been stopped), like selecting a radio button or clicking the drop down list doesn't do anything. This site used to work fine but it looks like they recently updated/changed it, and now the site does not work in Firefox. I tested this page in Google Chrome and it loads just fine (though the debug console does still say the page is trying to do things it shouldn't or it's failing to find referenced resources) and I'm able to interact with the page and use it as intended.

View the screenshot

Browser Configuration

• None

From webcompat.com with ❤️

[softvision-oana-arbuzov]

Thanks for the report, I was able to reproduce the issue.

Console:

Note: The issue is not reproducible on Chrome.

Tested with: Browser / Version: Firefox Nightly 105.0a1 (2022-08-15), Firefox Release 103.0.2 Operating System: Windows 10 Pro

Moving to Needsdiagnosis for further investigation.

[qa_33/2022]

[jat-247]

Thanks! If there's anything I can do to help please just let me know.

[wisniewskit]

This is quite subtle. They are basically mixing synchronous XMLHttpRequests with asynchronous ones (never a great idea), and Firefox behaves differently to Chrome in some cases when XHR stuff gets subtle.

Basically, they call this function twice (trimmed down for brevity):

function getOAProvidersForPracticeByLocation(...) {
    $.ajax({
        url: "/apps/HealowWebController?action=GetOAProvidersForPracticeByLocation",
        async: true,
        success: function(msg) {
                $('#providerAtLocationCount').html(cnt+" "+healow.i18n("more.provider"));

So each call will start an async Ajax request. And each one, upon success, will call i18n, which starts a synchronous XHR call inside of it:

var ajaxRequestProcessing = false;

healow.i18n = function (msg) {
    while(ajaxRequestProcessing == true){} // This is the issue
    if (i18nJson === "" || jsonLocale !== _healowLocale) {
        ajaxRequestProcessing = true;
        $.ajax({
            url: localeJsonUrl,
            async: false,
            success: function (response) {
                ajaxRequestProcessing = false;
            }
        });
    }

So basically, whichever async call succeeds first, its success will set ajaxRequestProcessing = true and begin a synchronous XHR.

Now we're in a weird situation: what should happen first after that is done? Should the success of that sync XHR happen first, or the success of the other, earlier async call? Chrome/webkit goes with the sync one, but Firefox goes with the pending async one.

And of course, that will also call i18n, see that ajaxRequestProcessing === true, and loop forever, without anything ever being able to stop it (until the user is prompted and stops the script, since JS will never process any DOM events while in such a loop).

So this is partly the site's fault for using sync XHR in the first place, and not handling XHR errors very gracefully. It's fully possible that the page will hang in Chrome as well if the first sync XHR fails, because they don't even handle the error case, only success (meaning ajaxRequestProcessing will never be false again, and any subsequent i18n calls will get stuck in the infinite loop).

Beyond that, the Firefox-specific hang should be resolved if https://bugzilla.mozilla.org/show_bug.cgi?id=697151 is addressed. I'm not sure if there is anything we can do otherwise, except perhaps try a relatively complicated site patch.

Honestly the site should be using a more modern approach to i18n to avoid all of this sync XHR risk, as that API has long been known to be a minefield, and is highly discouraged precisely because it can cause these sorts of subtle bugs and hangs (even discounting their error handling).

[webcompat-bot]

Generate outreach template

[ksy36]

intervention https://bugzilla.mozilla.org/show_bug.cgi?id=1799980