NEW 61310
keypress doesn't fire for the first key down event when contenteditable is set by an event handler 
https://bugs.webkit.org/show_bug.cgi?id=61310
Summary keypress doesn't fire for the first key down event when contenteditable is se...
Ryosuke Niwa
Reported 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.
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
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1 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.
Ryosuke Niwa
Comment 2 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?
Alexey Proskuryakov
Comment 3 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.
Hajime Morrita
Comment 4 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.
Hajime Morrita
Comment 5 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.
Ryosuke Niwa
Comment 6 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.
Chang Shu
Comment 7 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.
Levi Weintraub
Comment 8 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?
Chang Shu
Comment 9 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? :)
Levi Weintraub
Comment 10 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.
Ryosuke Niwa
Comment 11 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.
Ryosuke Niwa
Comment 12 2011-05-24 11:00:22 PDT
http://crbug.com/81783.
Alexey Proskuryakov
Comment 13 2011-06-10 21:29:55 PDT
*** Bug 62388 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.