No load event is fired at <style> after changing its content
Reported by
w.vons...@eyeo.com,
Dec 15 2016
|
|||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 Steps to reproduce the problem: 1. Visit 4390_load_chrome.html 2. Open the console 3. Click on "add style (no load)" What is the expected behavior? Console should print "load" a second time (a load event should occur) What went wrong? Console doesn't print "load" a second time (no load event does occur) Did this work before? No Does this work in other browsers? N/A Chrome version: 55.0.2883.75 Channel: n/a OS Version: Flash Version: Shockwave Flash 23.0 r0 This also doesn't work on (at least) 41.0.2272.101 (Win7 64-bit) and 54.0.2840.59 (Win7 64-bit). This also occurs on chrome 41.0.2272.101 (64-bit) and 54.0.2840.59 (64-bit). A load event is fired if you change the src attribute of an link tag, I believe it should also be fired after changing the content of a style tag (the changes do get applied). Firefox fires a load event for this.
,
Dec 16 2016
,
Dec 20 2016
,
Dec 26 2016
,
Dec 29 2016
Able to reproduce the issue on Win 10,Ubuntu 14.04 and Mac 10.12.2 using 55.0.2883.87/95 and canary 57.0.2966.0. This is a non-regression issue since 35.0.1849.0. Note: FireFox 50.0.2 is working fine.
,
Jan 2 2017
Reassigning to "Blink>DOM>Events" which covers 'load' as specified by https://dom.spec.whatwg.org/#events.
,
Mar 15 2017
Remove Blink>DOM>Events
,
Aug 28 2017
,
Aug 29 2017
,
Oct 31 2017
I'm putting this back in the triage queue for loader, since the load event isn't really a CSS thing. Sorry, not sure what happened with the components here.
,
Nov 17 2017
The load event is fired when a resource and its dependent resources have finished loading. https://www.w3.org/TR/DOM-Level-3-Events/#event-type-load So, this is intended behavior. Changing an element's text content should not fire a load event. I'm not sure why Firefox does that.
,
Nov 17 2017
#11 - That specification is actually pretty old and outdated. The HTML specification does say something about this and looks (to me) like Firefox is actually right - https://html.spec.whatwg.org/multipage/semantics.html#the-style-element Under the "Update a style block" section - https://html.spec.whatwg.org/multipage/semantics.html#update-a-style-block - there are some instructions - > Once the attempts to obtain the style sheet's critical subresources, if any, are complete, or, if the style sheet has no critical subresources, once the style sheet has been parsed and processed, the user agent must, if the loads were successful or there were none, queue a task to fire an event named load at the style element Since changing the textContent of <style> means reparsing a stylesheet, it should fire a load event, as far as I understand. What do you think?
,
Nov 20 2017
Ah you are right, changing the text content of <style> should fire a load event at the <style> element. I misread this bug as about the load event at Document. Thanks for pointing it out. Since this is about text content change, loader is not involved. Routing to Blink>HTML for further triage.
,
Nov 27 2017
So this is how changing the stylesheet content would kick the CSS parser and result in dispatching a load event - moving back the owner to style team.
,
Nov 27 2017
,
Dec 6 2017
,
Dec 6
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 12
,
Jan 18
(5 days ago)
,
Jan 18
(5 days ago)
The load event is only fired once on a style element: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/html_style_element.cc?sq=package:chromium&dr=CSs&l=129-130 |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by ajha@chromium.org
, Dec 16 2016