Bug 93760 - Selection change caused by click event on button should be *after* the onclick fires
Summary: Selection change caused by click event on button should be *after* the onclic...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.8
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2012-08-10 21:08 PDT by David Gatwood
Modified: 2022-07-26 22:50 PDT (History)
6 users (show)

See Also:


Attachments
Demonstrates odd behavior of buttons inside contentEditable regions (613 bytes, text/html)
2012-08-10 21:08 PDT, David Gatwood
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Gatwood 2012-08-10 21:08:08 PDT
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.
Comment 1 Alexey Proskuryakov 2012-08-13 09:56:57 PDT
See also: bug 93674. Perhaps we match IE here, as well?
Comment 2 Ryosuke Niwa 2012-08-13 14:53:45 PDT
IE doesn't change the selection until click event either.
Comment 3 Ahmad Saleem 2022-07-26 15:05:25 PDT
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!
Comment 4 Radar WebKit Bug Importer 2022-07-26 19:40:16 PDT
<rdar://problem/97641753>
Comment 5 Ryosuke Niwa 2022-07-26 22:50:13 PDT
Blink and WebKit still fail the attached test case.