RESOLVED DUPLICATE of bug 38696 Bug 65663
character appears in contenteditable without onkeydown event being fired 
https://bugs.webkit.org/show_bug.cgi?id=65663
Summary character appears in contenteditable without onkeydown event being fired
Mike Lawther
Reported 2011-08-03 20:54:36 PDT
As reported in http://crbug.com/72588: 1. Go to http://jsfiddle.net/ZSt2d/1/ 2. Focus the bordered <div> and press a key - it will not appear in the <div> as the onkeydown event prevents this (CORRECT) 3. Click the button under the <div>. Now you can press a key and the character will be put in the <div> because the onkeydown event is not fired (BAD). After one key is pressed, any more keys are suppressed again, until you press the button again, which results in the same procedure again. Code from link is: <html> <head></head> <body> <div contenteditable="true" onkeydown="event.preventDefault();" style="border:1px solid black"></div> <input type="button" value="Click me; then you are able to put one character in the div above me..."> </body> </html> No characters should appear in the contenteditable. Also tested (on Mac 10.6): WebKit nightly (r92303): FAIL Chrome 15.0.843.0 canary: FAIL Firefox 5.0.1: PASS Opera 11.50: PASS
Attachments
Add attachment proposed patch, testcase, etc.
Naiem
Comment 1 2011-08-03 22:10:52 PDT
Looks like a regression because i have a little older build and I do not see the issue..will build the latest nightly and see.
Naiem
Comment 2 2011-08-03 22:46:21 PDT
(In reply to comment #1) > Looks like a regression because i have a little older build and I do not see the issue..will build the latest nightly and see. plz ignore this comment i was able to reproduce the issue. will analyse and get back
Alexey Proskuryakov
Comment 3 2011-08-04 10:43:04 PDT
When clicking on the button, the input field loses focus ring, but insertion point keeps blinking. Bug 38546 might be tangentially related to such behavior. Once again, I urge everyone to attach test cases, not link to outside sites. There are lots of bugs that have gone invalid due to remote links dying, and storing many reductions on a single outside site is particularly unfortunate.
Mike Lawther
Comment 4 2011-08-04 15:14:34 PDT
I did put the reduction inline into the report. The jsfiddle link was intended as a convenience. Perhaps I should have reversed the order of their appearance to make this clearer. Or did you mean create an attachment, and put the test case into the attachment? Personally I find that less convenient, but I'm happy to do it that way if that is the accepted way in the WebKit community (eg there are automated tools that can make use of attachments or somesuch).
Naiem
Comment 5 2011-08-10 03:43:38 PDT
In the function clearSelectionIfNeeded which is called whenever focusednode is set, there is a check to see if the node is text or input tag if it is none then it is not cleared--> pasted below comment from code " // Don't clear the selection for contentEditable elements, but do clear it for input and textarea. See bug 38696." Since this is a contentEditable the clear is not called on it and because of which the updateApperance is not called and hence the cursor blinks and focus is not removed from the div. I have added the s->clear irrespective of the tag and it fixes the issue. If some one can comment on why the check for contenteditable is present i will try some other fix.
Alexey Proskuryakov
Comment 6 2011-08-10 09:17:44 PDT
CC'ing Levi, who has a patch for bug 38696. > If some one can comment on why the check for contenteditable is present i will try some other fix. There are some things you can do to find it out: 1. "svn blame" command to see when this code was added. 2. Make a change and run regression tests to see what breaks.
Ryosuke Niwa
Comment 7 2011-08-10 22:30:57 PDT
This is probably a duplicate of the bug 38696.
Mike Lawther
Comment 8 2011-08-11 18:27:52 PDT
Thanks Ryosuke - I hadn't considered that bug when I did a search before filing this bug (since its title mentions events are still received), but comment #4 on bug 38696 does say that the onkeydown event is *not* fired. Marking as dupe. *** This bug has been marked as a duplicate of bug 38696 ***
Note You need to log in before you can comment on or make changes to this bug.