Summary: | connectedCallback called when disconnected | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Justin Ridgewell <jridgewell> | ||||||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED INVALID | ||||||||||
Severity: | Normal | CC: | cdumez, dbates, esprehn+autocc, ews-watchlist, fred.wang, jridgewell, kangil.han, rbuis, rniwa, rwlbuis, webkit-bug-importer | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | Safari 11 | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Justin Ridgewell
2018-03-12 15:44:04 PDT
Created attachment 340871 [details]
Patch
I think Ryosuke should take a look. I forgot to link the Chrome bug I also filed: https://bugs.chromium.org/p/chromium/issues/detail?id=821195&desc=2 They closed as a won't fix, for this specific case (reparenter and child with disconnectedCallback, let's call this Case A). However, there's a [similar case](https://bugs.webkit.org/show_bug.cgi?id=183586) (reparenter and child _without_ disconnectedCallback) that shouldn't cause the bad behavior (let's call this Case B). Chrome thinks Case A should fire when disconnected, and not fire in Case B. Safari (currently) thinks both Cases should fire. Firefox thinks neither Case should fire. In all, it's very confusing to me why these Cases should be different. And given the browser disagreement, it's probably confusing to everyone else too. Case A: https://output.jsbin.com/qumape/3/quiet Case B: https://output.jsbin.com/qumape/7/quiet Scratch the Firefox, I forgot to enable webcomponents. Firefox thinks Case A should fire, and Case B should not. Comment on attachment 340871 [details] Patch Attachment 340871 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/7755558 New failing tests: imported/w3c/web-platform-tests/custom-elements/reactions/Range.html imported/w3c/web-platform-tests/custom-elements/adopted-callback.html imported/w3c/web-platform-tests/custom-elements/reactions/Element.html imported/w3c/web-platform-tests/custom-elements/reactions/Node.html imported/w3c/web-platform-tests/custom-elements/reactions/ChildNode.html imported/w3c/web-platform-tests/custom-elements/reactions/ParentNode.html Created attachment 340875 [details]
Archive of layout-test-results from ews104 for mac-sierra-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6
Comment on attachment 340871 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=340871&action=review I don't think this change is correct. For that matter, I believe WebKit's current behavior is in accordance with the specification. > Source/WebCore/dom/CustomElementReactionQueue.cpp:80 > - elementInterface.invokeConnectedCallback(element); > + if (element.isConnected()) > + elementInterface.invokeConnectedCallback(element); There is no spec text which mandates a check like this: https://html.spec.whatwg.org/multipage/custom-elements.html#invoke-custom-element-reactions > LayoutTests/fast/custom-elements/connected-callback.html:12 > + while (this.firstChild) { Why while? As far as I've read the spec, WebKit's behavior is correct. Moving a node inside a connectedCallback or any other custom element reaction callback DOES not the already. enqueued custom element reactions. If you feel this behavior is not what you want, please file a spec issue in https://github.com/w3c/webcomponents/issues Please take a look at the Case B issue, too: https://bugs.webkit.org/show_bug.cgi?id=183586 (In reply to Justin Ridgewell from comment #10) > Please take a look at the Case B issue, too: > https://bugs.webkit.org/show_bug.cgi?id=183586 https://webkit.org/b/183586 is a valid bug report. |