Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 307733 - AsyncKeyEventUtil misses events in FF
Summary: AsyncKeyEventUtil misses events in FF
Status: RESOLVED FIXED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: 1.3   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 1.3 M7   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-31 09:41 EDT by Tim Buschtoens CLA
Modified: 2010-04-12 10:51 EDT (History)
1 user (show)

See Also:

Attachments
patch showing bug (4.02 KB, text/plain)
2010-03-31 09:41 EDT, Tim Buschtoens CLA 		no flags Details
fix (2.57 KB, patch)
2010-04-12 06:53 EDT, Tim Buschtoens CLA 		ruediger.herrmann: iplog+
Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Buschtoens CLA 2010-03-31 09:41:04 EDT 
Created attachment 163528 [details]
patch showing bug

To reproduce:
- Apply patch
- Open controls-demo in FF
- TextTab => Check "KeyListener (reject all)
- click into textfield
- press some keys: nothing happens (OK)
- hold a key pressed: some characters appear, but shouldn't

As far as i can tell only Firefox is having this problem, so it's probably a browser-bug.
Comment 1 Tim Buschtoens CLA 2010-03-31 10:38:16 EDT 
Might also have something to do with the way KeyEventHandler normalizes key events in "_onkeyupdown" for FF in Windows.
Comment 2 Tim Buschtoens CLA 2010-04-09 05:17:48 EDT 
The problem appears to be in  AsyncKeyEventUtil. Whenever a keyEvent is fired, the "intercept" function stores its properties, so the event can be re-fired after the request to the server is finished. Usually the data is stored in "_pendingEventInfo", and re-fired if "allowEvent" is called by the server.

However, if a keyEvent is fired while a request is already running, it is stored in the "_bufferedEvents" array instead, and re-fired by "_onRequestReceived" (inderectly) in any case, wether allowEvent was called or not.

What should actually happen, is that yet another request is sent for this buffered event.
Comment 3 Tim Buschtoens CLA 2010-04-12 06:53:57 EDT 
Created attachment 164551 [details]
fix
Comment 4 Rüdiger Herrmann CLA 2010-04-12 10:50:46 EDT 
Applied patch to CVS HEAD