Closed Bug 1360230 Opened 4 years ago Closed 4 years ago

MutationObserver recursively triggers on non-mutating element.classList function calls


(Core :: DOM: Core & HTML, defect)

Not set



Tracking Status
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 --- fixed


(Reporter:, Assigned: ayg)



(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();
Has STR: --- → yes
Component: General → DOM
Product: Firefox → Core
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.
Per spec we're doing right now, as far as I see. 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. )
Do you know what Safari is doing? Since I believe Safari was supposed to be updated to follow the latest spec.
Flags: needinfo?(
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?(
I think this is a regression from Bug 1359780.
I need to still verify the regression range.
Closed: 4 years ago
Resolution: --- → FIXED
Assignee: nobody → ayg
Target Milestone: --- → mozilla55
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?(
Flags: needinfo?(bugs)
(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?(
Oops, I missed that, sorry.  Okay, then the backout is fine.
Flags: needinfo?(bugs)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.