Closed Bug 1723066 Opened 4 years ago Closed 4 years ago

Some pages' dynamic content doesn't load with dom.script_loader.full_parse = true

Categories

(Core :: Performance: General, defect, P3)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr78 --- disabled
firefox-esr91 --- disabled
firefox90 --- disabled
firefox91 --- disabled
firefox92 --- affected

People

(Reporter: cpeterson, Unassigned)

References

Details

Attachments

(1 file)

Attached image YouTube_screenshot.png

Steps to reproduce (intermittently)

  1. Set dom.script_loader.full_parse pref = true in Nightly 92.
  2. Load some tabs with YouTube videos, Bugzilla bugs, and Phabricator reviews.
  3. Restart Firefox (with session restore enabled).

Expected results

The pages should load the initial content and later dynamic content.

Actual result

The pages sometimes load the initial content, but don't load some dynamic content:

  • YouTube pages sometimes only the gray and white wire frame, but no video screenshots or comments. See the attached screenshot.
  • Bugzilla pages sometimes show the bug layout, but don't expand the People/References/Details sections.
  • Phabricator reviews sometimes show the review layout, but don't expand the file diffs. The file diff sections just say "Loading...".

Reloading the page with Ctrl+R usually fixes the problem and the page will fully load.

I see the following errors in the console for the half-loaded Phabricator pages:

Uncaught Error: CompileOptions mismatch between input and Stencil <unknown>:1
Uncaught Error: CompileOptions mismatch between input and Stencil <unknown>:1
Uncaught TypeError: can't access property "scry", JX.DOM is undefined
    __rawEventQueue https://d3kxowhw4s8amj.cloudfront.net/res/defaultX/phabricator/98e6504a/rsrc/externals/javelin/core/init.js:13
    <anonymous> https://d3kxowhw4s8amj.cloudfront.net/res/defaultX/phabricator/98e6504a/rsrc/externals/javelin/core/init.js:28
Flags: needinfo?(dpalmeiro)

Today I saw some of these page load problems (and Uncaught Error: CompileOptions mismatch between input and Stencil console errors aka JSMSG_STENCIL_OPTIONS_MISMATCH) with YouTube and Bugzilla even though my dom.script_loader.full_parse pref = false.

Since these page load problems seem to happen mostly during session restore (and are usually "fixed" by reloading the page), perhaps the JSMSG_STENCIL_OPTIONS_MISMATCH errors are reported from the XDR code below?

https://searchfox.org/mozilla-central/rev/2aa97aea1085cf1363582725407c514833ad47e4/js/src/frontend/StencilXdr.cpp#646-647

Does this bug look more like a Stencil bug than a dom.script_loader.full_parse bug? Or could dom.script_loader.full_parse be poisoning the XDR bytecode cache so I see this bug even after I set dom.script_loader.full_parse = false and restart Nightly?

Yeah I am seeing the same problems and they go away when I clear the cache. Looking into it now.

Flags: needinfo?(dpalmeiro)
Component: DOM: Core & HTML → Performance
Priority: -- → P3

Talked with :arai about this, I will look into modifying the script transcoding build id for cached bytecode so that we do not have a mismatch between cached bytecode that was compiled without full parsing and decoding with the full parsing option enabled.

Modifying the build id based on the full parsing pref resolves the issue of mismatch when flipping the pref and restarting the browser, but a separate issue remains. That is, we need to match the fullParse option between the initial compile and the decode, but we want to avoid doing this on the main thread. However, there is no way to know during the decode process if the initial compile was on the main thread or not. Therefore, the only ways to do this seems to be either we enable the fullParse option for all scripts when the pref is on, or read the option from the bytecode before setting it during decode. Instead, however, :arai has agreed to remove the assert for now so that we should always use the options used during the initial compile.

Flags: needinfo?(arai.unmht)
Depends on: 1726499

removed the consistency check for CompileOptions in decode case, in bug 1726499.

Flags: needinfo?(arai.unmht)

Thanks :arai, this should be fixed now. I've been using full_parse=true since the fix landed and haven't run into any noticeable problems.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: