Closed
Bug 1105285
Opened 10 years ago
Closed 9 years ago
Homescreen still responds to hardware home button when software home button is enabled
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
Tracking
(blocking-b2g:2.5+, b2g-v2.1 unaffected, b2g-v2.2 affected, b2g-master verified)
Tracking | Status | |
---|---|---|
b2g-v2.1 | --- | unaffected |
b2g-v2.2 | --- | affected |
b2g-master | --- | verified |
People
(Reporter: kats, Assigned: dwi2)
References
Details
(Keywords: regression, Whiteboard: [systemsfe][SHB-enabled])
Attachments
(3 files)
On the Flame, if you enable the SHB from the developer settings it seems like all of Gaia ignores the hardware home button except for the homescreen. On the homescreen tapping the HHB will still take you to the top of the homescreen with an instant jump effect. Tapping the SHB takes you to the top with a smooth scroll effect. I'm not sure if this is actually a bug but it seems inconsistent that everything else ignores the HHB except this one thing.
Comment 1•9 years ago
|
||
This issue occurs in both 2.2 and 3.0. It seems that when SHB is enabled, HHB should be disabled. HHB also retains some odd functionality in other places as well. For example, on Youtube.com when watching videos, hitting the HHB (with SHB enabled) will cause the video to restart from the beginning. Device: Flame 3.0 (KK - Nightly - Full Flash - 319mem) Build ID: 20150514010203 Gaia: 338f66e6a96491d2f5854b188c6b141ceb690d97 Gecko: 1fab94ad196c Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 41.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 Device: Flame 2.2 (KK - Nidghtly - Full Flash - 319mem) Build ID: 20150513002507 Gaia: e048df68f6f4853b5826a8816e143d95258149de Gecko: 0e6b4aab2b94 Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1:
--- → unaffected
status-b2g-v2.2:
--- → affected
status-b2g-master:
--- → affected
Flags: needinfo?(pbylenga)
Keywords: regression
Comment 2•9 years ago
|
||
Comment 3•9 years ago
|
||
[Blocking Requested - why for this release]: Regression of a supported feature.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regressionwindow-wanted
Whiteboard: [systemsfe][SHB-enabled]
Updated•9 years ago
|
QA Contact: bzumwalt
Comment 4•9 years ago
|
||
Mozilla-Inbound Regression Window: Last working Mozilla-Inbound build: Device: Flame 2.2 Build ID: 20141013192558 Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f Gecko: e0c4c804b279 Version: 36.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 First broken Mozilla-Inbound build: Device: Flame 2.2 Build ID: 20141014001056 Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f Gecko: 94d1b30bde00 Version: 36.0a1 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Working Gaia with Broken Gecko issue DOES reproduce: Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f Gecko: 94d1b30bde00 Working Gecko with Broken Gaia issue does NOT reproduce: Gaia: 4f86c631e0465c0e56ccebeb1324fd28be9ea32f Gecko: e0c4c804b279 Mozilla-Inbound Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e0c4c804b279&tochange=94d1b30bde00 Issue appears to occur due to changes made in bug 989198
Comment 5•9 years ago
|
||
Seems that the changes for bug 989198 caused this issue. Gina can you take a look please?
Blocks: 989198
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(ginayeh.ya)
Comment 6•9 years ago
|
||
Sorry! I don't have a device at hand. Tzu-lin, could you take a look at this one first?
Flags: needinfo?(ginayeh.ya) → needinfo?(tzhuang)
Assignee | ||
Comment 7•9 years ago
|
||
I am checking it now. Keep NI as reminding.
Assignee | ||
Comment 8•9 years ago
|
||
This is a gaia bug. We should stop default behavior (by calling evt.preventDefault()) of hardware 'Home' key we software home button is enabled. https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/hardware_buttons.js#L223
Component: Gaia::Homescreen → Gaia::System
Flags: needinfo?(tzhuang)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → tzhuang
Status: NEW → ASSIGNED
Comment 9•9 years ago
|
||
Assignee | ||
Comment 10•9 years ago
|
||
Comment on attachment 8606898 [details] [review] [gaia] dwi2:bug1105285 > mozilla-b2g:master Hi Alive, Hardware key events now propagate through iframe. So, when software home button is enabled, we should prevent default behavior of hardware home button too. Please help to review the patch, thanks
Attachment #8606898 -
Flags: review?(alive)
Comment 11•9 years ago
|
||
(In reply to Tzu-Lin Huang [:dwi2][:tzhuang] from comment #10) > Comment on attachment 8606898 [details] [review] > [gaia] dwi2:bug1105285 > mozilla-b2g:master > > Hi Alive, > > Hardware key events now propagate through iframe. So, when software home > button is enabled, we should prevent default behavior of hardware home > button too. > > Please help to review the patch, thanks Could you please explain more why preventing default fixes the bug? I don't see why from the code. Unless homescreen app is listening to mozbrowserkey* events.
Flags: needinfo?(tzhuang)
Assignee | ||
Comment 12•9 years ago
|
||
According to the design[0] of mozbrowserkey* events, if embedder frames did not call preventDefault() on mozbrowserbefore* event, Gecko will dispatch keydown/keyup event to its' embedded frames. In the case of this bug, given that software home button is enabled, when we receive mozbrowserbeforekeydown/mozbrowserbeforekeyup event of home button in system app, Gecko will dispatch keydown/keyup events to embedded frame (i.e. Homescreen app or web pages in browser app) unless we call preventDefault(). Even though these app or web pages do not listen to 'Home' key events, there are still 'default' action. The default action usually is to scroll to top of the page, which is the symptom described in #c0 and #c1. Since we already ignore all the key/mozbrowserkey* events of home button when software home key enabled[1], we should also prevent its default behavior, which is to propagate keydown/keyup events to embedded frame. [0]: https://wiki.mozilla.org/WebAPI/BrowserAPI/KeyboardEvent#Dispatch_KeyboardEvent_across_BrowserElements [1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/hardware_buttons.js#L223
Flags: needinfo?(tzhuang)
Comment 13•9 years ago
|
||
Comment on attachment 8606898 [details] [review] [gaia] dwi2:bug1105285 > mozilla-b2g:master Great, thanks. It'd be nice if you put the explanation in the code of hardware button manager.
Attachment #8606898 -
Flags: review?(alive) → review+
Assignee | ||
Comment 14•9 years ago
|
||
Thanks. Patch is updated with explanation. Waiting for Gaia-try result: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=b582972f7f1b259e268da1650ce57659fe02add7
Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Updated•9 years ago
|
Keywords: checkin-needed
Comment 15•9 years ago
|
||
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/600fd8249960b8256af9de67d9171025bb9a3ff3
Updated•9 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 16•9 years ago
|
||
Per Comment 15,this bug has been landed and fixed on master. This bug has been verified as pass on latest Nightly build of Flame v3.0 by the STR in Comment 0. Actual results: Enabling SHB from developer settings,on the homescreen tapping the HHB will not take you to the top of the homescreen anymore. See attachment: verified_v3.0.mp4 Reproduce rate: 0/5 Device: Flame v3.0 build(Pass) Build ID 20150520160208 Gaia Revision b290c77ccb7ab0af599b3d8287b71b9970d8dcb0 Gaia Date 2015-05-20 10:19:05 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/8d8df22fe72d Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150520.192608 Firmware Date Wed May 20 19:26:18 EDT 2015 Bootloader L1TC000118D0 --------------------------------------------- Leaving "verifyme" for v2.2 uplift & verification.
Comment 17•9 years ago
|
||
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Updated•9 years ago
|
status-b2g-v2.5:
--- → verified
Target Milestone: --- → 2.2 S13 (29may)
Updated•9 years ago
|
status-b2g-v2.5:
verified → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•