Bug 65663

Summary:	character appears in contenteditable without onkeydown event being fired
Product:	WebKit	Reporter:	Mike Lawther <mikelawther>
Component:	UI Events	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED DUPLICATE
Severity:	Normal	CC:	ap, darin, leviw, naiem.shaik, ojan, ojan, rniwa
Priority:	P2
Version:	528+ (Nightly build)
Hardware:	Unspecified
OS:	Unspecified

Description Mike Lawther 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

Comment 1 Naiem 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.

Comment 2 Naiem 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

Comment 3 Alexey Proskuryakov 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.

Comment 4 Mike Lawther 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).

Comment 5 Naiem 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.

Comment 6 Alexey Proskuryakov 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.

Comment 7 Ryosuke Niwa 2011-08-10 22:30:57 PDT

This is probably a duplicate of the bug 38696.

Comment 8 Mike Lawther 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 ***