Bug 213025

Summary:	SelectionChange event fires before mutationobserver event when devtools are closed
Product:	WebKit	Reporter:	Martin Middel <martin.middel>
Component:	DOM	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	ahmad.saleem792, ap, bfulgham, cdumez, darin, megan_gardner, rniwa, webkit-bug-importer, wenson_hsieh
Priority:	P2	Keywords:	InRadar
Version:	Safari 13
Hardware:	Unspecified
OS:	Unspecified

Description Martin Middel 2020-06-10 07:26:31 PDT

Hello there,

When I observe a contenteditable element using a mutation observer, and attach a selectionChange handler, typing a single character in the contenteditable causes the selectionChange handler to be fired BEFORE the mutationObserver callback. This does not align with what all other browsers do (Chromium / Firefox). Funnily enough, when opening the developer tools, the callbacks fire in the expected order.

I have reproduced this on Safari 13, as well as Midori 7.0 and Epiphany browser 3.36.1 (webkit 2.28.1).

Minimal repro: https://codepen.io/DrRataplan/pen/mdVVpoZ

How to repro:

1. Open the repro at https://codepen.io/DrRataplan/pen/mdVVpoZ
2. Place cursor in the "Type here" contenteditable div
3. Observe the log to display "SelectionChange!" for the initial selection change
4. Press 'a' to insert a letter

Expected:
The log should display the following:
> SelectionChange!
> Records!
> SelectionChange!

Actual:
The log displays the following:
> SelectionChange!
> SelectionChange!
> Records!

Now open your dev tools and repeat steps 1 to 4. Observe that the event order is the expected one.

The fact that the dev tools influence the result is very odd to me. Please reach out to me if anyone needs any assistance in reproducing this bug!

Comment 1 Radar WebKit Bug Importer 2020-06-11 18:07:48 PDT

<rdar://problem/64278714>

Comment 2 Martin Middel 2021-03-24 07:12:28 PDT

I just ran into this bug again. It is also present in Safari 14, but some users report different behaviour: regardless of whether the dev tools are open, the events arrive in the wrong order. This makes it even worse because the workaround of opening the dev tools is not working anymore.

I am so far unable to see what is different with those users: they are running the same version of OSX (Big Sur) and their Safari is equal to the build number with users who are reporting the original behaviour.

Is there any update on this?

Comment 3 Martin Middel 2021-03-26 01:36:33 PDT

I seem to have a workaround. Adding a selectionchange notifier VERY early in the startup of the web application seems to mitigate the problem.

We basically have a process that at some point relatively late in the start-up of out web application that sets up a mutation observer. I tried to work around this problem by attempting to flush the mutationObserver's records by calling its takeRecords method during a selection change. This caused the bug on our side to no occur anymore. However, after closer inspection, the event listener was never being called with any outstanding records. I removed all dead code and made this minimal event listener:


window.document.addEventListener('selectionchange', _event => {
	return;
});

This is indeed a function with no real body. This fixes the bug. I am however so far unable to apply this 'workaround' to the codepen case. 
This is being executed on the module level of our code. This makes it run before anything sensible is being executed. I suspect this is because of some timing.


I hope this helps anyone else unlucky enough to run into this bug.

Comment 4 Ahmad Saleem 2022-08-12 11:20:51 PDT

I am able to reproduce this bug in Safari 15.6 using attached below test case in Comment 0:

*** Safari Technical Preview 151 ***

SelectionChange!
SelectionChange!
Records!

*** Firefox Nightly 105 ***

SelectionChange!
Records!
SelectionChange!

*** Chrome Canary 106 ***

SelectionChange!
Records!
SelectionChange!

_________________

Just wanted to update latest test results. Thanks!