Closed
Bug 1360230
Opened 9 years ago
Closed 9 years ago
MutationObserver recursively triggers on non-mutating element.classList function calls
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla55
| Tracking | Status | |
|---|---|---|
| firefox-esr52 | --- | unaffected |
| firefox53 | --- | unaffected |
| firefox54 | --- | unaffected |
| firefox55 | --- | fixed |
People
(Reporter: bugzilla.mozilla.org, Assigned: ayg)
References
Details
(Keywords: regression)
The following code snippet causes Nightly to execute observer callbacks forever, on stable the observer callback is only fired once:
el=document.createElement("div"); mutate = () => {el.classList.toggle("foo", true)};obs = new MutationObserver((x) => {console.log(x); mutate()}); obs.observe(el, {"attributes": true}); mutate();
Updated•9 years ago
|
Comment 1•9 years ago
|
||
TokenList impl has changed recently. Note, setting attribute value to its currently value is supposed to trigger mutation observer.
Chrome and Edge both behave like FF stable and I have spotted this behavior by code in the wild relying on the non-recursive behavior.
Comment 3•9 years ago
|
||
Per spec we're doing right now, as far as I see.
https://dom.spec.whatwg.org/#dom-domtokenlist-toggle always calls
6. Run the update steps.
"A DOMTokenList object’s update steps
are to set an attribute value for the associated element using associated attribute’s local name and the result of running the ordered set serializer for token set. "
And since attribute value is set, MutationRecord is scheduled.
( Looks like some patch has landed recently and searchfox hasn't been updated yet. )
Comment 4•9 years ago
|
||
Do you know what Safari is doing? Since I believe Safari was supposed to be updated to follow the latest spec.
Flags: needinfo?(bugzilla.mozilla.org)
Comment 5•9 years ago
|
||
Aryeh, if the spec isn't web compatible, could you please find some time to back out problematic patches. please.
(In reply to Olli Pettay [:smaug] from comment #4)
> Do you know what Safari is doing? Since I believe Safari was supposed to be
> updated to follow the latest spec.
No, I don't have a safari to test with.
Flags: needinfo?(bugzilla.mozilla.org)
Comment 7•9 years ago
|
||
I think this is a regression from Bug 1359780.
Comment 8•9 years ago
|
||
I need to still verify the regression range.
Updated•9 years ago
|
status-firefox53:
--- → unaffected
status-firefox54:
--- → unaffected
status-firefox55:
--- → affected
status-firefox57:
affected → ---
status-firefox-esr52:
--- → unaffected
Comment 9•9 years ago
|
||
Backed out bug 1359780.
Updated•9 years ago
|
Updated•9 years ago
|
| Assignee | ||
Comment 10•9 years ago
|
||
I don't understand, what was the problem here? This behavior is expected and follows the standard. Did a real-world site break? I don't see anywhere in the bug report that says why we don't want this behavior.
Flags: needinfo?(bugzilla.mozilla.org)
Flags: needinfo?(bugs)
| Reporter | ||
Comment 11•9 years ago
|
||
(In reply to Aryeh Gregor (:ayg) (next working August 2-22) from comment #10)
> Did a real-world site break?
I mentioned that in comment 2.
> This behavior is expected and follows the standard.
Wasn't a spec-change which triggered this change in the first place?
Flags: needinfo?(bugzilla.mozilla.org)
| Assignee | ||
Comment 12•9 years ago
|
||
Oops, I missed that, sorry. Okay, then the backout is fine.
| Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(bugs)
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•