Don't preload scripts with unknown types
Categories
(Core :: DOM: HTML Parser, task, P3)
Tracking
()
People
(Reporter: hsivonen, Unassigned)
References
Details
(Keywords: good-first-bug, parity-chrome, parity-safari)
Attachments
(1 file)
Comment 1•8 years ago
|
||
Comment 2•4 years ago
|
||
Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.
If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.
Reporter | ||
Comment 3•4 years ago
|
||
Chrome has fixed their corresponding bug: https://bugs.chromium.org/p/chromium/issues/detail?id=626321
If chrome as fixed their corresponding bug does it also gets fixed on mozilla? If not then i would like to work on this bug.
Reporter | ||
Comment 5•4 years ago
|
||
(In reply to yanshrey from comment #4)
If not then i would like to work on this bug.
That would be great. See https://searchfox.org/mozilla-central/rev/1ebc9745be02eebf7a694f5c527a44a045b8c97a/parser/html/nsHtml5TreeBuilderCppSupplement.h#207 for the starting point.
Hi,
Is anyone still working on this bug?
If not want to give it a shot
I was looking into but but you can also go ahead and try it.
Check comment #5
Reporter | ||
Comment 8•1 year ago
|
||
Fixing bug 1848311 would have the side effect of fixing this.
Reporter | ||
Comment 10•1 year ago
|
||
Not only should we not preload unknown type, we should not create speculations when seeing unknown types.
From the bug I marked as duplicate:
We should check for IE event handler scripts and unsupported type
/language
combinations in the HTML parser already (not just in ScriptLoader
) to avoid creating speculations or preloads for scripts that will not execute anyway.
Comment 11•10 months ago
|
||
Based on
https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script
This affects mSpeculativeLoadQueue. I didn't change the behavior of
mCurrentHtmlScriptCannotDocumentWriteOrBlock.
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Comment 12•9 months ago
|
||
I'm currently stuck trying to implement your suggestion to handle ScriptKind::eEvent
like mozilla::dom::IsScriptEventHandler does. There isn't an nsHtml5AttributeName::ATTR_EVENT
that I would need to detect an event
attribute on a <script>
element.
Reporter | ||
Comment 13•9 months ago
|
||
Sorry about the delay. Indeed, ATTR_EVENT
is needed and missing. I'm adding it in bug 1884108.
Reporter | ||
Updated•9 months ago
|
Updated•9 months ago
|
Comment 14•7 months ago
|
||
This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit BugBot documentation.
Description
•