1938242 - Turn off the task-scheduling API pref (which was nightly-only)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, task, P1)

Description

[Daniel Holbert [:dholbert]]

bug 1734997 added experimental support for the "Prioritized Task Scheduling API":
https://wicg.github.io/scheduling-apis/

and that feature has been behind a Nightly-only pref ever since it landed:
https://searchfox.org/mozilla-central/rev/70fb2d2a702db4cb455d282be77ecfe9bdcea589/modules/libpref/init/StaticPrefList.yaml#2565-2569

# Whether the scheduler interface will be exposed
- name: dom.enable_web_task_scheduling
  type: RelaxedAtomicBool
  value: @IS_NIGHTLY_BUILD@
  mirror: always

It appears that recently, some of Google's high-priority documentation sites have started to use that API (if it's available) as part of their page-load pipeline, in a way that breaks the user experience with our current implementation. (Some task gets dropped on the floor and the page never finishes the dynamic loading work that it intends to do.) We've gotten at least 3 independent reports of this breakage (bug 1937232, bug 1938062, and a report on slack) within a few days, which indicates that people are feeling the pain.

For now, let's disable the pref, to unbreak the experience on Nightly, until we can get to a better understanding of what's broken (in our code and/or Google's usage) and we've got a way to reenable it without breaking these sites.

Comment 1

[Daniel Holbert [:dholbert]]

[+cc sefeng whose PTO I don't want to disturb; hence, taking this short-term measure in the hopes that sefeng can investigate the breakage in more depth when he's back]

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: Bug 1938242: Turn off dom.enable_web_task_scheduling (which was previously enabled in nightly), pending an investigation of recent associated real-world breakage. r?jrmuizel,smaug

See https://bugzilla.mozilla.org/show_bug.cgi?id=1937232 for the breakage
that this patch is aiming to mitigate.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/73738a2d5421
Turn off dom.enable_web_task_scheduling (which was previously enabled in nightly), pending an investigation of recent associated real-world breakage. r=smaug

Comment 4

[Serban Stanca [:SerbanS]]

Backed out for causing mochitests failures in test_worker_interfaces.html.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | dom/workers/test/test_worker_interfaces.html | false: Scheduler should be defined on self

Comment 5

[Jeff Muizelaar [:jrmuizel]]

We'll probably need the opposite of https://hg.mozilla.org/mozilla-central/rev/0713b093b0a6f42fd5a18675b1c2da5547e64d89 for this to pass

Comment 6

[Daniel Holbert [:dholbert]]

Sorry about that - I had high hopes that the pref-flip would Just Work per https://phabricator.services.mozilla.com/D232564#8050222 but I suppose I should've waited on try results. I'll address that and re-request review from smaug to respect the "IMPORTANT: Do not change this list without review from a DOM peer!" code-comments in the section that Jeff found.

Comment 7

[Daniel Holbert [:dholbert]]

Updated Try run (just running mochitests):
https://treeherder.mozilla.org/jobs?repo=try&revision=1d0293be34eda4b4dbd39dbcdbb951308f2d75ae

The patch now has s/nightly: true/disabled: true/ in the three JS files that had nightly-specific stuff in them, within the commit that Jeff linked in comment 5. That makes the associated tests pass (and seems to be the appropriate way to encode things based on the documentation at the top of those files).

Comment 8

[Sebastian Zartner [:sebo]]

This change should be documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#prioritized_task_scheduling_api.

Sebastian

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a11b0a691ff5
Turn off dom.enable_web_task_scheduling (which was previously enabled in nightly), pending an investigation of recent associated real-world breakage. r=smaug

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Sebastian Zartner [:sebo] from comment #8)

This change should be documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#prioritized_task_scheduling_api.

Thanks, good point. Hamish, perhaps you'd be up for doing that when you've got a chance? (e.g. we could add "This feature was then disabled in Firefox Nightly 135 as a temporary measure to avoid breakage in-the-wild", or something along those lines.)

Also, while we're editing it - I think there may be a mistake in that existing MDN text right now. That MDN page currently says:

This is enabled on Firefox Nightly (only) from Firefox 101.
No preference is provided to allow it to be enabled in other releases.

Assuming "about:config" counts as a preference, then I think the "No preference is provided..." text isn't correct and wasn't correct when this API landed. This functionality was simply behind the about:config flat dom.enable_web_task_scheduling. I just tested Firefox 101 release with that about:config flag enabled, to double-check, and I'm seeing Firefox pass WPTs like these ones (viewed directly in my browser), which confirms that the about:config pref functions correctly to enable the feature even in release builds:
http://wpt.live/scheduler/post-task-delay.any.html
http://wpt.live/scheduler/post-task-then-detach.html
And the compat chart here does (correctly) mention the about:config pref as a way to opt-in to the feature: https://developer.mozilla.org/en-US/docs/Web/API/Prioritized_Task_Scheduling_API#api.scheduler
So: if/when we update that text on the Experimental_features#prioritized_task_scheduling_api page, maybe we can replace that mention of "No preference" with the about:config preference name?

Comment 11

[Rob Wu [:robwu]]

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

... 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.

Comment 12

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/a11b0a691ff5

Comment 13

[Hamish Willee]

@Daniel/Sebastian

1. Yes, a preference is what is in About:config or modules/libpref/init/StaticPrefList.yaml
2. I can't explain the note even though I wrote it
   • dom.enable_web_task_scheduling was obviously enabled in nightly in https://bugzilla.mozilla.org/show_bug.cgi?id=1734997 and I have even updated the BCD with the preference - but NOT enabled in nightly.

Anyway, the upshot is that I don't need to update the compat data - it was wrong but this issue makes it right.

Experimental features data and Relnote for 135 updated https://github.com/mdn/content/pull/37289

Note, that if this is reverted in FF135 this will need to be undone - we won't see that change unless you add back dev-doc-needed

Comment 14

[Daniel Holbert [:dholbert]]

Thank you!