Bug 93760 – Selection change caused by click event on button should be *after* the onclick fires

• Component: HTML Editing
• Status: NEW

[David Gatwood]

Created attachment 157856 [details]
Demonstrates odd behavior of buttons inside contentEditable regions

I would normally expect a button's onclick handler to fire prior to any in-browser modification of the current DOM selection.  For some odd reason, in WebKit, the reverse occurs—the selection changes first—leading to spectacular misbehavior if you're crazy enough to place a button inside a contentEditable region.  :-)

Test case attached.  The expected behavior is that when you click inside the text above, then click the button, the click event should fire first, causing the content to be inserted at the selection point.  Instead, the insertion point moves first, so that the insertion point is inside the text of the button.  Thus, the content gets inserted inside the button.

[Alexey Proskuryakov]

See also: bug 93674. Perhaps we match IE here, as well?

[Ryosuke Niwa]

IE doesn't change the selection until click event either.

[Ahmad Saleem]

I am able to reproduce this bug using attached test case in Safari 15.6 on macOS 12.5 where placing caret on the text and then pressing button trigger dialog with "fail" rather than adding text. It is same with Chrome Canary 106 and only Firefox Nightly 104 is where it add text and does not show any "fail" dialog. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/97641753>

[Ryosuke Niwa]

Blink and WebKit still fail the attached test case.