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)

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
Status: ASSIGNED → RESOLVED
Closed: 9 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: