Address the breakage on various Google developer-docs sites that occurs when `dom.enable_web_task_scheduling` is enabled
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
()
Details
We've received and confirmed several reports of several prominent Google documentation sites that are broken if you've got about:config pref dom.enable_web_task_scheduling enabled. Presumably they started using that API recently (if it's available) in a way that happens to break.
For the very-short term, I'm proposing that we turn off the about:config pref (that's bug 1938242), and I'm filing this bug on fixing the breakage so that we can reenable the pref.
What we know so far in the associated bugs is:
- the
<body>element has the attributependingduring pageload. - there's some JS that the site intends to run, to swap out
pendingfor an attribute namedready - ...and that attribute switcheroo is important to various bits of functionality (e.g. which CSS rules will apply)
- ...and for some reason, in Firefox-with-this-pref-enabled, that
<body>attribute tweak never happens -- so the page is forever in a state of having<body ... pending>which leaves the overall page in an unusable state (because Google intentionally nerfs various things when the page is being loaded, via thispendingattribute).
See bug 1937232 for more details.
Here are some sites that are known to be affected:
From bug 1937232:
https://developer.android.com/
https://cloud.google.com/bigquery/docs/reference/standard-sql/conversion_functions
From bug 1938062:
https://developer.android.com/courses/pathways/android-basics-compose-unit-2-pathway-1
See those bugs for STR; there'll now just be one additional precondition which is "set about:config pref dom.enable_web_task_scheduling to true.
In the off chance that those^ sites change such that they no longer reproduce the issue before we can investigate, we can probably still use the wayback machine to view the pages in their currently-broken state. E.g. this snapshot reproduces the bug for me:
https://web.archive.org/web/20241218025621/https://developer.android.com/
|
Reporter | |
Updated•8 months ago
|
|
|
Reporter | |
Comment 1•8 months ago
|
||
transferring ni=sefeng from bug 1937232.
|
||
Comment 2•8 months ago
|
||
FYI Google is aware of the issue and have a fix, at least for developer.chrome.com. I created a detailed bug report before at https://issuetracker.google.com/issues/384531056
The root cause is that Firefox's Scheduler API does not implement the yield method. This is tracked in bug 1920115.
... and they responded with:
Thanks for spotting this and the great bug report. The fix was just submitted but it might be a few weeks before it's released due to the holidays.
|
|
Reporter | |
Comment 3•8 months ago
|
||
Thanks! Good to know that a root cause has already been identified.
Given that Google's workaround is potentially a few weeks out, it seems like the short-term disabling (landed earlier today in bug 1938242) is still good, to keep nightly usable in the meantime.
When sefeng returns from PTO, maybe we can just morph this bug into a reenable-the-pref bug, assuming Google's fix is out and we're not seeing breakage in the wild at that point. (Or maybe it'll be wise to wait until we have yield in bug 1920115 before reenabling, if it's conceivable that other sites might stumble over the same API-hole and break similarly to how Google's documentation is breaking.)
|
||
Comment 4•4 months ago
•
|
||
Given google fixed the site, I don't think this bug is relevant anymore. So I am closing this.
scheduler.yield is now implemented, and I'll enable that again in Nightly in bug 1958943
Description
•