Closed Bug 441582 Opened 11 years ago Closed 9 years ago

key presses do not show up in content all of the time.

Categories

(Firefox for Android Graveyard :: General, defect, P1)

x86
All
defect

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
Flags: blocking-fennec1.0+
Priority: -- → P1
Target Milestone: --- → Fennec A1
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
We're getting activation events and blur should be fixed by bug 454235. Doug, do you see this with those patches applied?
probably dup of bug 435446 (or vice-versa).

stuart ?
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.
When does this occur? Are there some steps which can get the browser into a state where keyboard events do not get sent?
> 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 ...
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.
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.
Blocks: 457289
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
(In reply to comment #9)
> enn's patch from bug 455891 fixes that.

It doesn't fix it for me though.
> > 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
Assignee: nobody → enndeakin
Target Milestone: Fennec A2 → Fennec A3
I also see the alerts when using the testcase. jmaher, can you verify?
Is this still a problem?
Resolving as WFM based on current Fennec trunk.  We should probably open new bugs for any specific remaining issues.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.