Created attachment 94490 [details] demo When contenteditable is set true in an event handler of click event, the first key down does not fire keypress event in the editable root.
Mn... it seems like the problem isn't really that WebKit not firing keypress event but rather that WebKit renderers caret in the editable region even though it doesn't have a focus. On Firefox 3.6 and Internet Explorer 9, focus is never set on the editable element and the caret is never drawn. Only when the user clicks for the second time, they start rendering caret.
Created attachment 94504 [details] work in progress This work-in-progress patch will make WebKit not to render a caret inside an editable region if it's not focused. But I'm not sure if this is what a user would expect because the editable element is focused when a user modifies selection by pressing arrow keys or other means. This is glitch caused by https://bugs.webkit.org/show_bug.cgi?id=38696. Any opinions / suggestions as to what to do here?
I do not have a suggestion, but I have an edge case to consider. When conteneditable is set on body (or presumably when designMode is on), the body does not get a focus highlight, but is of course editable.
(In reply to comment #2) > Created an attachment (id=94504) [details] > work in progress > > This work-in-progress patch will make WebKit not to render a caret inside an editable region if it's not focused. But I'm not sure if this is what a user would expect because the editable element is focused when a user modifies selection by pressing arrow keys or other means. This is glitch caused by https://bugs.webkit.org/show_bug.cgi?id=38696. > > Any opinions / suggestions as to what to do here? According to the demo, we can input the first character even if we don't render the caret. Is that right? If so, it's strange for me, even if your wip change itself makes sense.
> According to the demo, we can input the first character even if we don't render the caret. > Is that right? If so, it's strange for me, even if your wip change itself makes sense. I noticed that is another bug which is filed as Bug 38696.
(In reply to comment #4) > (In reply to comment #2) > > Any opinions / suggestions as to what to do here? > According to the demo, we can input the first character even if we don't render the caret. > Is that right? If so, it's strange for me, even if your wip change itself makes sense. I agree. It's definitely a strange behavior. Maybe this bug needs to be blocked by the bug 38696.
> > According to the demo, we can input the first character even if we don't render the caret. > > Is that right? If so, it's strange for me, even if your wip change itself makes sense. > > I agree. It's definitely a strange behavior. Maybe this bug needs to be blocked by the bug 38696. It seems we observed two issues and we do have two patches now. :) It will be good to test the build with both patches.
(In reply to comment #7) > It seems we observed two issues and we do have two patches now. :) It will be good to test the build with both patches. I'm slightly confused. Does the patch from 38696 fix this on its own?
(In reply to comment #8) > (In reply to comment #7) > > It seems we observed two issues and we do have two patches now. :) It will be good to test the build with both patches. > > I'm slightly confused. Does the patch from 38696 fix this on its own? You are the author of 38696 patch and you must have the build. Can you quickly test the link above and tell us the result? :)
(In reply to comment #9) > You are the author of 38696 patch and you must have the build. Can you quickly test the link above and tell us the result? :) Now I understand the problem, and agree that this should be dependent upon 38696, but these patches are complimentary. With the fix in 38696, you are unable to enter a character into the newly-editable field with just one click, but the caret is still rendered.
(In reply to comment #8) > (In reply to comment #7) > > It seems we observed two issues and we do have two patches now. :) It will be good to test the build with both patches. > > I'm slightly confused. Does the patch from 38696 fix this on its own? No. It's just that your patch would make WebKit's behavior more reasonable. This patch stops WebKit's rendering of caret in a contenteditable element with a selection when the element doesn't have a focus. However, due to the bug 38696, a user can still type text in the element (because focus is automatically moved to the element) and the element will be focused.
http://crbug.com/81783.
*** Bug 62388 has been marked as a duplicate of this bug. ***