Re: [whatwg/dom] `mutationObserver.disconnect({ flush: true })` (Issue #1283)

@rniwa 
> Adding option to `disconnect` seems like a sensible approach. Changing the behavior of `disconnect` at this point is likely going to hit some web compatibility issues (this API has been shipping for 10+ years) so I'd rather not.

We can't keep adding API surface for every fix. How would sites be _depending_ on the behavior of pending records *not* being taken?

Anyhow, if the compat risk is deemed too high I think a new method might be better, so we can gradually steer people towards using that, rather than being stuck with a method where you need to pass an optional parameter in 99.9% of the time (like `cloneNode(true)`).

@smaug---- 
> The rest is not already broken. disconnect() was designed to stop observing anything, very explicit. No different to removeEventListener. (There might be an event queued in a task, and you won't get that event if removeEventListener is called).

How frequently does that happen though? It sounds like an extremely rare race condition, whereas what I’m talking about here happens way more.

> If we add a dictionary to disconenct() for flush, I wonder if we want also explicit flush() which is like takeRecords() but calls the callback.

That seems like a good idea!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1283#issuecomment-2393692005
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1283/2393692005@github.com>