Bug 112854

Summary:	contenteditable element does not completely surrender focus
Product:	WebKit	Reporter:	Jared Jacobs <jmjacobs>
Component:	HTML Editing	Assignee:	Nobody <webkit-unassigned>
Status:	UNCONFIRMED ---
Severity:	Normal	CC:	ahmad.saleem792, ap, jmjacobs, megan_gardner, ntim, rniwa, vepomoc, wenson_hsieh
Priority:	P2	Keywords:	HasReduction
Version:	528+ (Nightly build)
Hardware:	All
OS:	Unspecified
URL:	http://jsfiddle.net/A9QXk/
Bug Depends on:	38696
Bug Blocks:

Description Jared Jacobs 2013-03-20 16:22:35 PDT

To reproduce the problem:
1. Type in a contenteditable element.
2. Click outside the contenteditable element on a focusable control that does not support text entry (e.g. a button).
3. Type an "x".

The blinking caret is still in the editable element after step 2, even though focus had left it. The blinking caret should have been gone.

After step 3, an "x" was added to the editable box and it had reclaimed focus. Neither of those things should have happened.

I have witnessed the bug on the webkit nightly at SVN r146339. The bug has affected Safari and Chrome for years.

Here is a workaround, dated July 2011:
https://gist.github.com/1081133
It's the top web search result for "webkit contenteditable workaround".

Comment 1 Comandeer 2020-05-20 09:44:18 PDT

I can confirm that the issue is still present. We've encountered it recently in CKEditor 4: https://github.com/ckeditor/ckeditor4/pull/3898#pullrequestreview-388090174.

Comment 2 Ryosuke Niwa 2020-05-21 12:05:39 PDT

Ah, this is because selection & focus behavior in WebKit matches macOS convention unlike other browsers. In WebKit, focus moves to where selection is whereas in other browsers, selection moves to where focus is. This is more or less expected behavior from that.

Comment 3 Ahmad Saleem 2022-06-01 06:11:40 PDT

I am able to reproduce this bug in Safari 15.5 and other browsers (Chrome Canary 104 and Firefox Nightly 103) behave same and different from Safari 15.5 and matches expected results. Thanks!