1841730 - Page don't finish loading on https://www.korg.com/jp/support/download/product/1/200/ (due to timer issues specific to post-April-2020 Win10 versions)

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Alice0775 White]

Steps to reproduce:

1. Clear cache everything from Ctrl+shift+Del
2. Open https://www.korg.com/jp/support/download/product/1/200/
   And do not move mouse pointer.
3. Wait for loading progress bar to dismiss.
   --- Bug#1!, the bar stops at 99% and not dismiss. Driver download link lists will not be shown.
4. Move the mouse pointer over the progress bar in a circular motion on the page.
   --- Bug#2!, after Firefox103, the driver download link lists will not be shown.

Actual results:
The progress bar stops at 99% and not dismiss. Driver download link lists will not be shown.
After Firefox103, the driver download link lists will not be shown even if moving mouse pointer.

Expected results:
The driver download link lists should be shown immediately after reaching progress bar 99% like Chrome.

#1 Regression window for the former Bug:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7a928140b9339e4f0592e6bdbcd29499bb5a4056&tochange=6fefaf842b05bea156591d27cbd64095617dbf27

#1 Regressed By Bug 1445570.

#2 Regression window for the latter Bug:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=798a8f4afe8d923e23ff5d05e7651d2b86c21bcd&tochange=cc80efc5b21956dd23d6e58f91d74bdbb392ca5f

#2 Regressed by Bug 1767396.

Comment 1

[Alice0775 White]

Interestingly,
Open 'Web Developer Tools(Ctrl+Shift+I)' > Click 'Performance' tab> Click 'Start recording' button,
Then, the list will be shown immediately.

Comment 2

[Daniel Holbert [:dholbert]]

Thanks for the bug report! Hmm, I can't reproduce.

I tested on Ubuntu 22.04 (locally, with Firefox Nightly 117), and on Windows 10 (in a BrowserStack cloud environment), with Firefox 115.0b1 (latest version that they make available there). Fresh profile, leaving my cursor completely still; the site loads just-fine, with the site's progress bar hitting 100% and then showing a list of 4 drivers for download.

(In reply to Alice0775 White from comment #1)

Open 'Web Developer Tools(Ctrl+Shift+I)' > Click 'Performance' tab> Click 'Start recording' button,
Then, the list will be shown immediately.

That's too bad; a performance profile would be really helpful in seeing what's going on here.

Would you mind seeing if you can reproduce (and capture/share a profile of the bug, ideally with Nightly profile settings which includes screenshots) if you start profiling before loading the page? (Either in devtools as you described, or by using the toolbar button that shows up after you click through at https://profiler.firefox.com/ )

(The toolbar-button might be more successful. I know some bugs disappear if you open devtools at all, as a side effect of satisfying various devtools queries about the document's state.)

Comment 3

[Daniel Holbert [:dholbert]]

I also tested Firefox 104 in Windows 10, via BrowserStack (for a version closer to the regression ranges noted in comment 0). Still unable to repro, [un]fortunately.

Performance Impact: --- → ?

(I'm not sure this is really a performance bug; it doesn't sound like we're doing anything slowly or consuming resources. When the bug reproduces, it sounds like the reported symptoms are just Firefox failing entirely at one or another distinct steps in the load process for this page, correct?)

Comment 4

[Alice0775 White]

Attachment: about:support

(In reply to Daniel Holbert [:dholbert] (away until Jul 24, for PTO & CSSWG meeting) from comment #2)

Would you mind seeing if you can reproduce (and capture/share a profile of the bug, ideally with Nightly profile settings which includes screenshots) if you start profiling before loading the page? (Either in devtools as you described, or by using the toolbar button that shows up after you click through at https://profiler.firefox.com/ )

(The toolbar-button might be more successful. I know some bugs disappear if you open devtools at all, as a side effect of satisfying various devtools queries about the document's state.)

When 'No Timer Resolution Change' is un-checked(by default) in Profiler settings:
I cannot reproduce this issue.
Profiler log: https://share.firefox.dev/3rfAD3w

When 'No Timer Resolution Change' is checked in Profiler settings:
I can reproduce this issue.
Profiler log: https://share.firefox.dev/3O0BSfX

Comment 5

[Justin Link]

FWIW, for me the issue does reproduce 100% as described in the ticket (at least the first issue - I'm not sure that I actually understand the second) - when I visit the above-cited page the progress counter goes to 99% and stays there. And the issue does goes away immediately (that is to say, the list of available drivers appears even after having been stuck at the 99% screen for whatever period of time) when I turn on the profile.

That the behavior changes and is "fixed" when the profiler starts likely means that the behavior is, in some way, tied to the Windows timer frequency (set by timeBeginPeriod). (The profiler enables high resolution timers in Windows when it starts up.) According to Windows Timer Resolution: The Great Rule Change, prior to around the April 2020 version of Windows 10, high frequency timer settings tended to "leak" across processes which is to say that processes would frequently get high resolution timers even if they didn't request them. Starting with the above-cited Windows version, processes were more insulated from the resolutions specified by other processes (good for power consumption, not so good for performance).

@dholbert: What version of Windows 10 were you running in your test? If it was prior to the April 2020 version I would suggest trying a newer version if possible.

One other oddity that I have noticed is that, if I open the page in another tab but don't switch over to that tab and let it sit in the background for a while and then switch over to that tab, it will be at the drivers list when I finally do switch over. It's like it just doesn't want me to watch it. :)

Gerald's change was cited as being a part of the start of the problem here. Gerald is not here any more but I am the current caretaker of TimerThread and am pretty familiar with Gerald's change as well. If you need any help/support related to TimerThread please reach out to me and I'd be glad to help.

Comment 6

[Justin Link]

Oh and I agree with Daniel that this doesn't seem like a "performance" bug.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Justin Link from comment #5)

@dholbert: What version of Windows 10 were you running in your test? If it was prior to the April 2020 version I would suggest trying a newer version if possible.

BrowserStack doesn't let you poke around the OS at all, but about:support tells me OS: Windows_NT 10.0 17134. That seems to correspond to a version older than 2020 based on the row for 17134 on https://en.wikipedia.org/wiki/Windows_10_version_history . So I think I was indeed trying an old version of Win10, perhaps too old to repro this bug.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:alaskanemily, could you have a look please?

For more information, please visit BugBot documentation.

Comment 9

[David Shin[:dshin]]

Reproducible on Win 10 22H2 19045.3208.
The page uses a library called PACE, and this particular issue is filed on their GitHub issues page. Curiously, it mentions adjusting a feature called "event lag" to work around this issue.

Comment 10

[Daniel Holbert [:dholbert]]

I suspect this doesn't really belong in the Layout component; the missing content here isn't missing because Firefox is styling or laying it out wrong; rather, it's missing because the site is actively hiding it (it's inside of a <div class="downloadInside"> element which has display:none by default). The site intends to eventually run some JS that adds display:block to that element to un-hide it, but when this bug happens, that JS apparently never executes (or is delayed for ages) for some reason. That seems to be related to the Win10-specific timer issues discussed above.

So, anyway: I suspect Core::XPCOM is a better spot for this to live, to be closer to the timer & scheduling code that are probably involved here. I think this may require someone poking in the JS debugger to figure out what event(s)/callback(s) are getting scheduled in a way that the site doesn't expect, and to what extent that's something we can fix.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

The page is relying on timer precision being < 3ms, but that really isn't guaranteed (and we don't want to do that for power usage etc).

So I think the library just has an unreasonable default and should be fixed.

Comment 12

[Justin Link]

@emilio: Can you clarify what you mean by "the page is relying on timer precision being < 3ms"? Is there some logic that you have seen that is responsible for that?

As a quick test, I tried pulling that page up in Chrome, on my laptop, with it disconnected from AC power (which might cause Chrome to reduce its Windows timer frequency) and it still loaded correctly, and quickly, there. (Unfortunately I don't know of a way to directly verify what timer frequency a given application is using at a any particular time, but I believe that Chrome reduces Windows timer frequency when on battery power - see https://bugs.chromium.org/p/chromium/issues/detail?id=927165, https://chromium.googlesource.com/chromium/src.git/+/695bc35e044ed930093577667b9d2112ca45c41e, https://chromium.googlesource.com/chromium/src.git/+/4cf4c917c3da3df34fb17f404eb9fb2e40763445.)

Comment 13

[Emilio Cobos Álvarez [:emilio]]

We chatted about this in the last XPCOM triage meeting. The relevant code is here: https://github.com/CodeByZach/pace/blob/2350e563a7c899deb2b93903bee7164921018b2b/pace.js#L756-L785

Which basically amounts to setInterval(cb, 50), and checking that cb gets scheduled at 50ms +/- 3ms of the last time. So there are multiple things that could factor into this, one of them is performance.now() being jittery and the other one being timer scheduling. If we schedule the interval at 45ms or 55ms of the target, the page will "never finish loading".

Comment 14

[Justin Link]

Great, thanks for the explanation!

Comment 15

[Donal Meehan [:dmeehan]]

:denschub could this be triaged? Is it possible to ship an intervention based on Comment 9

Comment 16

[Dennis Schubert [:denschub]]

I'll redirect the ni? from comment 15 to Tom, he's focusing on interventions for the next couple of releases.

Comment 17

[Calin Tanase]

Verified this issue and could not reproduce it on Firefox 125, only on version 122 and 123. Alice could you check in a new profile on the latest Firefox Nightly and give us an update, please?

Environment:
Operating system: Windows 10
Browsers: Firefox Nightly 125.0a1 (2024-02-19) / Firefox Release 122 / Firefox Beta 123

Comment 18

[Alice0775 White]

Yes, this is fixed on Nightly125.0a1 Windows10.
However, I can still reproduce this on 124.0b1 candidate, 123.0 and 122.01 Windows10.

Comment 19

[Alice0775 White]

Fixed range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d93c1e224fa334cb0e1a4faf860be329181c1d60&tochange=955d8904ddef311f2bfcb090dc82218c9a650d49

So, this is fixed in nightly build only.

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

Should we consider enabling high-precision timers on beta/release too?

Comment 21

[Justin Link]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #20)

Should we consider enabling high-precision timers on beta/release too?

https://bugzilla.mozilla.org/show_bug.cgi?id=1872786 is the bug about enabling this change outside of Nightly and I've been negligent about sharing my latest thoughts there. I've just added a comment there with my thoughts and plans.

Comment 22

[Thomas Wisniewski [:twisniewski]]

Pardon my delay here. I can't reproduce the error, but they're still using PACE, and based on some debugging based on the github discussion from comment 9, it looks like a simple site patch should work which just does this (anytime before the pace.min.js script runs):

window.paceOptions = {
	eventLag: false,
};

We might as well try that for now (at least until we've enabled the high-res timers by default on release).

Comment 23

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1841730 - add a JS intervention for www.korg.com to un-break download pages on Windows; r=ksenia

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/36c35d26bc9b
add a JS intervention for www.korg.com to un-break download pages on Windows; r=ksenia,webcompat-reviewers

Comment 25

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/36c35d26bc9b

Comment 27

[Daniel Holbert [:dholbert]]

Given comment 18, comment 19, and comment 21, I think can classify this as webcompat:platform-bug with a dependency on bug 1872786 as the platform-bug that would fix this on release. (Though the issue is currently mitigated by a sitepatch, per comment 24.)