Investigate deferring JavaScript in browser.xul until after MozBeforeInitialXULLayout fires

RESOLVED WONTFIX

Status

()

enhancement
P3
normal
RESOLVED WONTFIX
5 months ago
2 months ago

People

(Reporter: bgrins, Unassigned)

Tracking

(Blocks 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 months ago
In order to support Fluent inside the prototype cache, we've discussed blocking scripts from running while the DOM is still being built so that we have a safe time to snapshot the DOM (after Fluent has processed it which is before MozBeforeInitialXULLayout).

I guess we could either:

(1) be careful in the frontend code:
- make sure Custom Elements use delayConnectedCallback
- hold off on doing subscript loading (i.e. stuff in scripts in global-scripts.inc) until after MozBeforeInitialXULLayout
(2) Block all scripts (script tags, CE reactions, etc) from running in the document until that event fires.

I'd prefer (2) if there's a mechanism in place for that - it seems like a more robust way to solve this.

I'd also like if whatever we do could be accomplished by HTML documents in the future as well, since we are planning to ship browser.xul as browser.xhtml.

Comment 1

5 months ago
Changing the component to Core/XUL if this is an incorrect component, please set it to a better one, than reverting it to General. Thank you!
Component: General → XUL
Product: Firefox → Core
This is just fine in General.
Component: XUL → General
Priority: -- → P3
Product: Core → Firefox
No longer blocks: top-level-html
Depends on: 1533881
Blocks: 1533881
No longer depends on: 1533881
(Reporter)

Comment 3

2 months ago

With the Fluent mini cache (Bug 1517880) and the new support for creating XHTML documents with the XUL prototype cache (Bug 1527977) I don't think we need this anymore.

Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.