Closed Bug 1105285 Opened 11 years ago Closed 10 years ago

Homescreen still responds to hardware home button when software home button is enabled

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-v2.1 unaffected, b2g-v2.2 affected, b2g-master verified)

RESOLVED FIXED
2.2 S13 (29may)
blocking-b2g 2.5+
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.
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?]
Flags: needinfo?(pbylenga)
Keywords: regression
[Blocking Requested - why for this release]: Regression of a supported feature.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [systemsfe][SHB-enabled]
QA Contact: bzumwalt
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
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)
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)
I am checking it now. Keep NI as reminding.
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: nobody → tzhuang
Status: NEW → ASSIGNED
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)
(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)
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 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+
Thanks. Patch is updated with explanation. Waiting for Gaia-try result: https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=b582972f7f1b259e268da1650ce57659fe02add7
Keywords: checkin-needed
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
blocking-b2g: 3.0? → 3.0+
Keywords: verifyme
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.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Target Milestone: --- → 2.2 S13 (29may)
The master has verified, so clear 'verifyme' keywords.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: