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

RESOLVED FIXED in Firefox OS master

Status

Firefox OS
Gaia::System
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: kats, Assigned: dwi2)

Tracking

({regression})

unspecified
2.2 S13 (29may)
x86
Mac OS X
regression

Firefox Tracking Flags

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

Details

(Whiteboard: [systemsfe][SHB-enabled])

Attachments

(3 attachments)

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?]
status-b2g-v2.1: --- → unaffected
status-b2g-v2.2: --- → affected
status-b2g-master: --- → affected
Flags: needinfo?(pbylenga)
Keywords: regression
Created attachment 8605912 [details]
logcat_20150514_1034.txt
[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]
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)
Keywords: regressionwindow-wanted
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)
(Assignee)

Comment 7

3 years ago
I am checking it now. Keep NI as reminding.
(Assignee)

Comment 8

3 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

3 years ago
Assignee: nobody → tzhuang
Status: NEW → ASSIGNED
Created attachment 8606898 [details] [review]
[gaia] dwi2:bug1105285 > mozilla-b2g:master
(Assignee)

Comment 10

3 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)
(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

3 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 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

3 years ago
Thanks. Patch is updated with explanation.
Waiting for Gaia-try result:
  https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=b582972f7f1b259e268da1650ce57659fe02add7
(Assignee)

Updated

3 years ago
Keywords: checkin-needed

Updated

3 years ago
Keywords: checkin-needed

Updated

3 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 3 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.
status-b2g-master: affected → verified
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
status-b2g-v2.5: --- → verified
Target Milestone: --- → 2.2 S13 (29may)
status-b2g-v2.5: verified → ---
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.