Bug 61310 - keypress doesn't fire for the first key down event when contenteditable is set by an event handler
Summary: keypress doesn't fire for the first key down event when contenteditable is se...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P1 Normal
Assignee: Nobody
URL:
Keywords: NeedsRadar
: 62388 (view as bug list)
Depends on: 38696
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-23 14:34 PDT by Ryosuke Niwa
Modified: 2011-06-10 21:29 PDT (History)
7 users (show)

See Also:


Attachments
demo (159 bytes, text/html)
2011-05-23 14:34 PDT, Ryosuke Niwa
no flags Details
work in progress (3.23 KB, patch)
2011-05-23 15:32 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-05-23 14:34:37 PDT
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.
Comment 1 Ryosuke Niwa 2011-05-23 14:54:34 PDT
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.
Comment 2 Ryosuke Niwa 2011-05-23 15:32:57 PDT
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?
Comment 3 Alexey Proskuryakov 2011-05-23 15:38:33 PDT
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.
Comment 4 Hajime Morrita 2011-05-23 20:27:02 PDT
(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.
Comment 5 Hajime Morrita 2011-05-23 20:28:03 PDT
> 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.
Comment 6 Ryosuke Niwa 2011-05-23 20:33:14 PDT
(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.
Comment 7 Chang Shu 2011-05-24 06:27:05 PDT
> > 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.
Comment 8 Levi Weintraub 2011-05-24 10:17:05 PDT
(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?
Comment 9 Chang Shu 2011-05-24 10:34:33 PDT
(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? :)
Comment 10 Levi Weintraub 2011-05-24 10:56:00 PDT
(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.
Comment 11 Ryosuke Niwa 2011-05-24 10:58:28 PDT
(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.
Comment 12 Ryosuke Niwa 2011-05-24 11:00:22 PDT
http://crbug.com/81783.
Comment 13 Alexey Proskuryakov 2011-06-10 21:29:55 PDT
*** Bug 62388 has been marked as a duplicate of this bug. ***