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: Macintosh Intel OS X 10.8
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-10 21:08 PDT by David Gatwood
Modified: 2015-06-10 09:39 PDT (History)
3 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.