Closed
Bug 761067
Opened 12 years ago
Closed 12 years ago
Key events is being mistakenly sent twice with nested <iframe mozbrowser>
Categories
(Firefox OS Graveyard :: General, defect)
Firefox OS Graveyard
General
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: timdream, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
363 bytes,
application/x-gzip
|
Details |
With bug 757486 landed and bug 755648 pending, we now rely on <iframe mozbrowser> to forward keys to the parent frame. However, keys from nested <iframe mozbrowser> is being forward to the System app more than once. For the current Gaia, this includes, at least, A) Browser App browser content STR: 1) In Gaia, go to browser app and navigator to any web address 2) Interact with the web content by panning the view, have the view iframe gaining focus 3) Try to adjust the volume Expected: * Volume indication should appear and go up/down one level Actual: * It goes up/down by two level because the key events is being sent twice.
Comment 1•12 years ago
|
||
Can you write a smaller testcase? At least help to identify the origin of the bug? On top of my head, I don't see what could produce that except if, for some reasons, an event was sent to the system app by a specific path and another was sent trough the mozbrowser hierarchy...
Comment 2•12 years ago
|
||
It's not totally clear from comment 0, but but it sounds like this happens specifically when you have system app <iframe mozbrowser> <iframe mozbrowser>
Comment 3•12 years ago
|
||
With the attached test case, everything is working fine. Please, check locally.
Reporter | ||
Comment 4•12 years ago
|
||
https://gist.github.com/2817145 I can reproduce the behavior with your test case, and mine. I've specifically stopped shell.js from generating key events so the events must have come from mozbrowser
Comment 5•12 years ago
|
||
I don't understand. You are calling addEventListener twice, one for each phase so it is expected that you get the event being handled twice, one for each phase. Or do you mean you get two handling for each phases? I can't reproduce that locally.
Reporter | ||
Comment 6•12 years ago
|
||
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #5) > I don't understand. You are calling addEventListener twice, one for each > phase so it is expected that you get the event being handled twice, one for > each phase. Or do you mean you get two handling for each phases? I can't > reproduce that locally. Yes, I am getting two handling for each phases, unfortunately. :( I am building SGS2 out of mozilla-b2g/b2g repo and Gecko from mozilla-central BTW.
Comment 7•12 years ago
|
||
In my work on https://bugzilla.mozilla.org/show_bug.cgi?id=762362 I'm seeing something similar. In b2g/chrome/content/shell.js, I'm getting two keydown keypress keydown keypress keyup keyup for the sleep, volume up and volume down hardware buttons. For the soft Home button, I only get keydown keypress keyup. I see this on a GB otoro with whatever is in today's in mozilla-b2g gecko repo.
Comment 8•12 years ago
|
||
Adding dhylands, who thinks there might be a low-level hardware button debouncing issue.
Reporter | ||
Comment 9•12 years ago
|
||
Doesn't happen anymore as we have changed the way hardware keys are handled.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Comment 10•10 years ago
|
||
Just noticed that we still have a comment regarding this bug in the code: http://hg.mozilla.org/mozilla-central/file/87730d939be7/b2g/chrome/content/shell.js#l476 Comment 9 seems to suggest that we don't need the debouncing keys anymore, shall I file a follow-up to remove that code?
You need to log in
before you can comment on or make changes to this bug.
Description
•