onKeyDown event, do not add the character!

VERIFIED FIXED

Status

()

Core
Event Handling
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: cs.luizeduardo@hotmail.com, Assigned: Neil Deakin (away until Feb 4))

Tracking

({regression, testcase})

Trunk
x86
Windows 7
regression, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [softblocker][fx4-fixed-bugday])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

When i use onKeyDown event on firefox 4, the letter typed to not get displayed.
Like this:
<input type="TEXT" onkeydown="alert(this.value)" />
If i click the A letter on blank input field, it will display a blank alert (correct), but do not add the A letter clicked.
I'm usning firefox 4 beta 7!

Reproducible: Always

Steps to Reproduce:
1.create a html file
2.create a input field with keydown event with anything like an alert;
3.click any letter, or number
Actual Results:  
Do not work properly the typed letter

Expected Results:  
Display the typed word before
Seeing this with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101214 Firefox/4.0b8pre ID:20101214030322 too.

Works in Firefox 3.6.x.
Component: General → Event Handling
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → events
Version: unspecified → Trunk
Created attachment 497590 [details]
Reporter's Testcase
Presumably the issue is that we lose focus or something and then the keyup goes to a different place and there is no keypress on the text control?

Neil, what do other UAs do?
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
(Assignee)

Comment 4

7 years ago
Works fine for me on Mac; the character just doesn't appear until after the alert is dismissed, which is the expected behaviour. Safari behaves the same.

Doesn't work on Windows though. Not sure why the difference.
The attached testcase doesn't work for me on mac.  If I dismiss the alert with the mouse, typeaheadfind opens with the char I typed.  If I dismiss it with the keyboard, the original char is just lost....
Neil, can you have a look here?
Assignee: nobody → enndeakin
blocking2.0: ? → final+
Whiteboard: [softblocker]
(Assignee)

Comment 7

7 years ago
This is because the focus is changing between content and chrome during a keypress. We fixed the cases where focus changed from chrome to content during a keypress in bug 551434, but not other cases as Olli believed it was too regression risky.
(Assignee)

Comment 8

7 years ago
Created attachment 506432 [details] [diff] [review]
patch

This would fix it but haven't tested it much.
(Assignee)

Comment 9

7 years ago
Comment on attachment 506432 [details] [diff] [review]
patch

Olli, any thoughts on what issues this might cause?
Attachment #506432 - Flags: review?(Olli.Pettay)

Updated

7 years ago
Attachment #506432 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 10

7 years ago
Created attachment 508751 [details] [diff] [review]
patch with test
Attachment #506432 - Attachment is obsolete: true
(Assignee)

Comment 11

7 years ago
http://hg.mozilla.org/mozilla-central/rev/059044e44314
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
Whiteboard: [softblocker] → [softblocker][fx4-fixed-bugday]
Depends on: 635434
You need to log in before you can comment on or make changes to this bug.