Closed
Bug 441582
Opened 16 years ago
Closed 14 years ago
key presses do not show up in content all of the time.
Categories
(Firefox for Android Graveyard :: General, defect, P1)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
fennec1.0b1
People
(Reporter: dougt, Assigned: enndeakin)
References
()
Details
I do not see all keypress events being sent to content. Sometimes it is a focus issue (focus remains in the urlbar), other times the events are simply lost. The URL listed above simply alerts whatever the keycode of the keypress is. I would expect consistent behavior between firefox and fennec. That is to say, I want to see an alert() each and every time I press a key. This blocks
Updated•16 years ago
|
Flags: blocking-fennec1.0+
Priority: -- → P1
Target Milestone: --- → Fennec A1
Comment 1•16 years ago
|
||
we're getting screwed here because i don't think the browser is getting the proper blur/activation events.
Target Milestone: Fennec A1 → Fennec A2
Comment 2•16 years ago
|
||
We're getting activation events and blur should be fixed by bug 454235. Doug, do you see this with those patches applied?
Comment 4•16 years ago
|
||
dougt: tip -> change in the testcase you can replace function keypress(event) { alert(event.which); } by function keypress(event) { var key = (event.which) ? event.which : event.keycode; alert(key); } in theory, testcase should not required that change to work better, once 'which' catches either charCode or keyCode (the one that is not '0') in a given time, what is not happening in this testcase. For example: pressing 'ArrowUp' returns '0'. ps: the widget-completion in the botton of the screen is not the problem root here. Maybe Neil's patch in bug 455891 fixes that. Gotta give it a try.
Assignee | ||
Comment 5•16 years ago
|
||
When does this occur? Are there some steps which can get the browser into a state where keyboard events do not get sent?
Comment 6•16 years ago
|
||
> When does this occur? Are there some steps which can get the browser into a
> state where keyboard events do not get sent?
n810, go to testcase in fennec, press any key ...
Assignee | ||
Comment 7•16 years ago
|
||
Looks like the right frame is focused. The key events are being received but on the wrong widget -- the toplevel window instead of the browser frame. The odd thing is that I can see the right widget being focused once the page loads, but the key event still goes to the wrong one.
Assignee | ||
Comment 8•16 years ago
|
||
Looks like the switching of the urlbar icon <deck> from throbber mode to icon mode causes the view to be hidden. That's right but for some reason it unfocuses the browser frame as well.
Comment 9•16 years ago
|
||
enn's patch from bug 455891 fixes that. ps: after applying patch from that bug, alert pops up for all keypress, however, the testcase have problems w/ arrow keys: put focus on content, and press KeyUp, the dialog shows up at first time, but pressing that again does not make the dialog to show up. It happens because after the first ArrowUp, snav move focus away from content and events do not get fired off of content anylong until it gets focus back. it is a problem in the testcase (see also comment #4), easily solved by adding event.preventDefault(); and event.stopPropagation(); in the testcase.
Depends on: 455891
Assignee | ||
Comment 10•16 years ago
|
||
(In reply to comment #9) > enn's patch from bug 455891 fixes that. It doesn't fix it for me though.
Comment 11•16 years ago
|
||
> > enn's patch from bug 455891 fixes that. > > It doesn't fix it for me though. As I explained in comment #9, it does not working completely for me if arrow key are pressed (Problem described above), but do works for other keys. Btw, I checked that on the desktop/linux, once arm build it broken. How does that behavior for you , enn ?
OS: Mac OS X → All
Updated•16 years ago
|
Assignee: nobody → enndeakin
Target Milestone: Fennec A2 → Fennec A3
Comment 14•14 years ago
|
||
Resolving as WFM based on current Fennec trunk. We should probably open new bugs for any specific remaining issues.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•