Avoid creating script and CSS loaders for documents loaded as data
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
People
(Reporter: hsivonen, Assigned: hsivonen)
References
(Blocks 4 open bugs, Regressed 1 open bug)
Details
Crash Data
Attachments
(1 file)
It seems that loadedAsData=true docs never become loadedAsData=false. Therefore, it seems feasible to pursue not creating script and CSS loaders for them in order to speed up creation from DOMParser.
Assignee | ||
Comment 1•2 months ago
|
||
Assignee | ||
Comment 2•2 months ago
|
||
It turns out that print preview wants a document that counts as loaded as data but can be styled and rendered.
Assignee | ||
Comment 3•2 months ago
|
||
Emilio, is print preview a special case where the browser has special powers and can be addressed as a special case, or is it possible to start styling and displaying a loaded-as-data document using Web-exposed APIs?
Assignee | ||
Comment 4•2 months ago
|
||
Comment 5•2 months ago
|
||
Static clones for both print preview and printing need styling, yeah. I think SVG-as-image also counts as loaded-as-data? But with those special cases out of the way I think you're good to go.
Assignee | ||
Comment 6•1 month ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
Static clones for both print preview and printing need styling, yeah. I think SVG-as-image also counts as loaded-as-data? But with those special cases out of the way I think you're good to go.
Thanks. Some SVG cases that one might expect to be loaded-as-data already aren't. Let's see what happens with allowing styling from clone but not otherwise:
https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=151846
Assignee | ||
Comment 7•1 month ago
|
||
Assignee | ||
Comment 8•1 month ago
|
||
Assignee | ||
Comment 9•1 month ago
|
||
Assignee | ||
Comment 10•1 month ago
|
||
Assignee | ||
Comment 11•1 month ago
|
||
Updated•1 month ago
|
Assignee | ||
Comment 12•1 month ago
|
||
Updated•1 month ago
|
Comment 13•21 days ago
|
||
Comment 14•21 days ago
|
||
Comment 15•21 days ago
|
||
Backed out for causing multiple wpt failures.
- Backout link
- Push with failures
- Failure Log @table-fixed-minmax.html
- Failure Log @caretPositionFromPoint.html
- Failure Log @elementFromPoint-001.html
Comment 16•21 days ago
|
||
Comment 18•20 days ago
|
||
bugherder |
Comment 19•20 days ago
|
||
Comment 20•20 days ago
|
||
Backed out from central https://hg.mozilla.org/mozilla-central/rev/75a595a9d65d529c86a28bc528c86caf24891d85
Assignee | ||
Comment 21•20 days ago
|
||
Let's use bug 1991800 for investigation.
![]() |
||
Comment 22•20 days ago
|
||
There are 6 crash reports from 2 installs of the latest Nightly with [@ mozilla::dom::ScriptLoader::AddParserBlockingScriptExecutionBlocker ]
as signature, e.g. bp-4db92bb6-dfaa-4613-9323-fe6960251001. If these were a result of bug 1991800, there should be more reports.
Assignee | ||
Comment 23•19 days ago
|
||
(In reply to Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout) from comment #22)
There are 6 crash reports from 2 installs of the latest Nightly with
[@ mozilla::dom::ScriptLoader::AddParserBlockingScriptExecutionBlocker ]
as signature, e.g. bp-4db92bb6-dfaa-4613-9323-fe6960251001. If these were a result of bug 1991800, there should be more reports.
Thanks! This is a null check oversight.
Updated•13 days ago
|
Assignee | ||
Comment 24•12 days ago
|
||
Assignee | ||
Comment 25•12 days ago
|
||
layout/base/tests/chrome/printpreview_pps9.html fails with the current patch even though other print preview cases pass. Emilio, do you see some obvious reason that could make that one fail when the others don't fail?
Assignee | ||
Comment 26•12 days ago
|
||
(The current state of the patch accomplishes the goal on Speedometer3 of not creating the CSS loader for loaded-as-data docs during the Speedometer3 run.)
Comment 27•11 days ago
|
||
Not sure but it seems the patch is pretty orange, so that might have to do with it.
Comment 28•11 days ago
|
||
Maybe that's not using quirks mode and the others do? But just guessing really.
Assignee | ||
Comment 29•11 days ago
|
||
(In reply to Emilio Cobos Álvarez [:emilio] from comment #27)
Not sure but it seems the patch is pretty orange, so that might have to do with it.
Whoa. The patch went really bad in my latest tweak that was supposed to be an easy fix.
Assignee | ||
Comment 30•8 days ago
|
||
Assignee | ||
Comment 31•8 days ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #30)
https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=158062
This run is considerably less orange. With this code, layout/base/tests/chrome/printpreview_pps9.html
still fails for me locally. Furthermore, even if I try to cause more eager creation of the CSS loader from DocumentOrShadowRoot::CloneAdoptedSheetsFrom
, layout/base/tests/chrome/printpreview_pps9.html
still fails locally here.
Assignee | ||
Comment 32•8 days ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #31)
(In reply to Henri Sivonen (:hsivonen) from comment #30)
https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=158062
This run is considerably less orange. With this code,
layout/base/tests/chrome/printpreview_pps9.html
still fails for me locally. Furthermore, even if I try to cause more eager creation of the CSS loader fromDocumentOrShadowRoot::CloneAdoptedSheetsFrom
,layout/base/tests/chrome/printpreview_pps9.html
still fails locally here.
The null-returning Document::GetExistingCSSLoader
look in Pernosco like they are not the cause.
Assignee | ||
Comment 33•8 days ago
|
||
Still fails for me locally even if I cause CSS loader creation in Document::CloneDocHelper
right after creating the cloned doc and before the compat mode is set.
Assignee | ||
Comment 34•8 days ago
|
||
It seems that the test now passes on try. OTOH, a test that fails on try passes locally. Probably both are unreliable somehow.
Updated•7 days ago
|
Comment 35•10 hours ago
|
||
Description
•