112854 2013-03-20 16:22:35 -0700 contenteditable element does not completely surrender focus 2024-11-16 15:52:52 -0800 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) All Unspecified UNCONFIRMED http://jsfiddle.net/A9QXk/ HasReduction, InRadar P2 Normal --- 38696 0 jmjacobs webkit-unassigned ahmad.saleem792 ap jcraig jmjacobs megan_gardner ntim rniwa sarahmhigley vepomoc webkit-bug-importer wenson_hsieh oldest_to_newest 859843 0 jmjacobs 2013-03-20 16:22:35 -0700 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". 1654484 1 vepomoc 2020-05-20 09:44:18 -0700 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. 1655028 2 rniwa 2020-05-21 12:05:39 -0700 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. 1873288 3 ahmad.saleem792 2022-06-01 06:11:40 -0700 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! 2075220 4 sarahmhigley 2024-11-14 15:43:34 -0800 This seems a little more complex (and more clearly broken) than selection not following focus. Clicking a button or link to blur a contenteditable will change how subsequent key presses are processed in that contenteditable when it regains focus. Clicking a button or link also does not match what happens when you click the background page / non-interactive content, even though both will blur the contenteditable and reset document.activeElement to the body. There are a couple other weird side effects going on here. I made a codepen to demonstrate what I've found, that lists them: https://codepen.io/smhigley/pen/oNKVyMo 2075585 5 jcraig 2024-11-16 15:51:31 -0800 Agreed that there is unexpected behavior here. Sarah’s codepen illustrates it well. Thanks Sarah. The document caret position doesn’t get moved with focus. Even if you’ve tabbed past the content editable region, subsequent arrow key events are still unexpectedly sent back to the content editable. This behavior: 1. Breaks the WebKit/Safari expectation that arrows could be used for scrolling here, and… 2. Pulls focus back unexpectedly. 2075586 6 webkit-bug-importer 2024-11-16 15:52:52 -0800 <rdar://problem/140048563>