Closed Bug 1937232 Opened 4 months ago Closed 4 months ago

Various Google developer-docs sites (developer.android.com, cloud.google.com/bigquery/docs/) are not not usable in Nightly (missing search, locale, and sign-in, and fixed header/sidebar scroll offscreen) unless you turn off dom.enable_web_task_scheduling

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 135
Platform:
All
macOS
Type:
defect

Tracking

(firefox-esr128 disabled, firefox133 disabled, firefox134 disabled, firefox135 disabled, firefox136 disabled)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr128 --- disabled
firefox133 --- disabled
firefox134 --- disabled
firefox135 --- disabled
firefox136 --- disabled

People

(Reporter: jonalmeida, Unassigned)

References

(Regression,
URL
)

Details

(Keywords: regression, webcompat:platform-bug, webcompat:site-report)

User Story

platform:windows,mac,linux,android
impact:workflow-broken
configuration:general
affects:all
branch:release
diagnosis-team:dom

Attachments

(1 file)

chrome 133 vs firefox 133.png
348.10 KB, image/png
Details

developer.android.com does not render the search bar, locale, and Google Sign-in page.

Tested with fresh profiles and with/without ETP enabled.

Tested this against:
WORKING - Chrome Canary 133
NOT WORKING - Firefox Nightly 135.0a1 (2024-12-13)
WORKING - Firefox Release 133.0.3

Severity: -- → S2
User Story: (updated)
Keywords: webcompat:needs-diagnosis, webcompat:site-report
Priority: -- → P2
User Story: (updated)
Keywords: regression, regressionwindow-wanted
Priority: P2 → P1

133 isn't affected but the regression window is in 2022? Is this a Nightly-only problem?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #3)

133 isn't affected but the regression window is in 2022? Is this a Nightly-only problem?

Yes.

The hidden stuff here (e.g. the search box) is explicitly hidden by the site, via this CSS rule:

body[pending] devsite-search {
  visibility:hidden!important;
}

Looking at the DOM in a broken load in Firefox Nightly, I do see that body has the attribute pending:

<body class="android-home tenant--android viewport--desktop"
  template="landing"
  theme="android-theme"
  type="product"
  appearance=""
  layout="full"
  pending=""
  style="--devsite-panel-height: 0px;">

In Chrome and Firefox Release, the body has attribute ready instead. So: the issue here is that the site is expecting some JS to run to swap out pending for ready, and that's never happening in Nightly.

In Firefox Release, the page swaps out ready for pending here:
https://www.gstatic.com/devrel-devsite/prod/v5ab6fd0ad9c02b131b4d387b5751ac2c3616478c6dd65b5e931f0805efa1009c/android/js/devsite_app_module.js

    Yo = async function (a) {
      if (!document.body.hasAttribute('ready')) {
        a.g &&
        await on(a.g);
        a = new CustomEvent('devsite-page-loaded');
        document.body.dispatchEvent(a);
        document.body.setAttribute('ready', '');
        document.body.removeAttribute('pending');

Here's the backtrace where that happens, in case it ends up being useful:

Yo (https://www.gstatic.com/devrel-devsite/prod/v5ab6fd0ad9c02b131b4d387b5751ac2c3616478c6dd65b5e931f0805efa1009c/android/js/devsite_app_module.js:formatted#9572)
ap (https://www.gstatic.com/devrel-devsite/prod/v5ab6fd0ad9c02b131b4d387b5751ac2c3616478c6dd65b5e931f0805efa1009c/android/js/devsite_app_module.js:formatted#9458)
<anonymous> (https://www.gstatic.com/devrel-devsite/prod/v5ab6fd0ad9c02b131b4d387b5751ac2c3616478c6dd65b5e931f0805efa1009c/android/js/devsite_app_module.js:formatted#10496)
<anonymous> (https://www.gstatic.com/devrel-devsite/prod/v5ab6fd0ad9c02b131b4d387b5751ac2c3616478c6dd65b5e931f0805efa1009c/android/js/app_loader.js#63)
<anonymous> (https://www.gstatic.com/devrel-devsite/prod/v5ab6fd0ad9c02b131b4d387b5751ac2c3616478c6dd65b5e931f0805efa1009c/android/js/app_loader.js#63)
<anonymous> (https://www.gstatic.com/devrel-devsite/prod/v5ab6fd0ad9c02b131b4d387b5751ac2c3616478c6dd65b5e931f0805efa1009c/android/js/app_loader.js#63)

Looking at the regression range, I confirmed that this is a regression from bug 1734997.

which added dom.enable_web_task_scheduling as a Nightly-only pref (and it's still Nightly-only).

I confirmed locally that toggling this pref causes/fixes the bug here. (If the pref is false, the bug goes away; if it's true, the bug happens.)

User Story: (updated)
Regressed by: 1734997

Set release status flags based on info from the regressing bug 1734997

:sefeng, since you are the author of the regressor, bug 1734997, could you take a look?

For more information, please visit BugBot documentation.

status-firefox-esr128: --- → affected
Flags: needinfo?(sefeng)

[Just adding one more way in which this bug manifests as causing breakage:]

The ready vs pending distinction also matters for whether or not headers/sidebars that are supposed-to-be-fixed are actually fixed or not, e.g. the left and top bars on this page https://cloud.google.com/bigquery/docs/reference/standard-sql/conversion_functions (as well as the top header on https://developer.android.com/ ). e.g. the intended-to-be-fixed-position header doesn't actually get position:fixed until the body gets the 'ready' attribute which then makes this snippet of CSS start applying:

body[ready] devsite-header[fixed] {
    contain: layout;
    pointer-events: none;
    position: fixed;
    top: 0;
    width: 100%;
}
Summary: developer.android.com - site is not usable (missing search, locale, and sign-in) → Various Google developer-docs sites (developer.android.com, cloud.google.com/bigquery/docs/) are not not usable in Nightly (missing search, locale, and sign-in, and fixed header/sidebar scroll offscreen) unless you turn off dom.enable_web_task_scheduling

(In reply to Daniel Holbert [:dholbert] from comment #7)

Looking at the regression range, I confirmed that this is a regression from bug 1734997.

which added dom.enable_web_task_scheduling as a Nightly-only pref (and it's still Nightly-only).

Given that the pref is Nightly-only, we can consider all non-nightly releases to have status disabled here.

status-firefox133: unaffected → disabled
status-firefox134: ? → disabled
status-firefox-esr128: affected → disabled
Duplicate of this bug: 1938062

As a short-term mitigation, I've posted a patch to turn off the about:config pref in bug 1938242, and I'll file a followup bug on actually investigating the breakage so that we can reenable the pref.

Depends on: 1938242
Keywords: regressionwindow-wanted, webcompat:needs-diagnosis → webcompat:platform-bug
See Also: → 1938246

I filed bug 1938246 to investigate and fix the underlying breakage here. But we can close this bug (i.e. users will no longer be experiencing a webcompat issue) once the pref-flip in bug 1938242 lands.

Flags: needinfo?(sefeng)

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.

I can confirm as the reporter that the bug is fixed and since there is bug 1938246, we can close this as fixed as per comment 13.

Thanks all for the investigation and fixes!

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED

Set release status flags based on info from the regressing bug 1734997

status-firefox136: --- → affected
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: