Joey Arhar

> If the default behavior will not be changed, then I would request that a feature (attribute?) be added to allow the dialog to receive initial focus, as there is...

I'll defer to domenic on this one. I don't have much context/insight on this, and the only reason I will say no is if the change breaks existing tests/websites.

I just enabled the change on stable chrome today, I'd like to wait a few more days before being certain that it's not breaking anything. I haven't heard anything yet...

> I have a `` where I call .preventDefault() on the mousedown event to prevent bluring (focusout, actually) an active (contenteditable) editor. Now when the button is disabled, the mousedown...

An issue was raised about the dblclick event on disabled form controls was opened here: https://bugs.chromium.org/p/chromium/issues/detail?id=1497354 With the new behavior I implemented in chrome, dblclick events are now fired on...

Yes, implementations run steps after as well. Things chromium does before removal: - Hides popovers - Fires sync mutation events - Cleans up Range instances Things chromium does after removal:...

When the removal steps call hidePopover, the fireEvents flag is set to false which prevents any script from being run.

> Except for popover we handle all of those in DOM directly. Should we really make that an extension point? Is there some other way to design popover? We could...

I suppose that if we added a parameter to the hide popover algorithm which tells it that the element is disconnected and we should hide it anyway, and also add...

> An alternative idea: when https://html.spec.whatwg.org/#hide-popover-algorithm is invoked, instead of invoking https://html.spec.whatwg.org/#check-popover-validity from there, check only if https://html.spec.whatwg.org/#popover-visibility-state is "hidden" and if so return early. If we don't call check...