[Webkit-unassigned] [Bug 213025] New: SelectionChange event fires before mutationobserver event when devtools are closed

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 10 07:26:31 PDT 2020


https://bugs.webkit.org/show_bug.cgi?id=213025

            Bug ID: 213025
           Summary: SelectionChange event fires before mutationobserver
                    event when devtools are closed
           Product: WebKit
           Version: Safari 13
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: DOM
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: martin.middel at fontoxml.com

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!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200610/a05c5d56/attachment.htm>


More information about the webkit-unassigned mailing list