812252 - Home button should not be blocked, except FTU

Status: RESOLVED FIXED

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

Description

[Josh Carpenter [:jcarpenter]]

Inline activites should never block the Home button. The entire point of the Home button is that it's an almost-universally reliable "back" button. We may eventually decide to make exceptions to this rule for dialogues (ala iOS), but certainly not for activities.

Blocking. This is broken usability and a mis-application of the spec. Activity-based flows have some severe usability problems in current builds, and this is one of the reasons. The impact stretches from Camera to Email to PDF Viewer.

Per the comments in bug #802494:

>> Inline activity should not block home button press.
> If this is a must-fix behavior in System, > please file a bug, set it blocked by this one, and make sure both are blocking+.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Gaia Triage : This may be a duplicate; gaia triage consensus is though that this is a usability issue, P2.  + for now until a dup is found.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I can't seem to find the dup.  Closest I came was bug 796780

Comment 3

[(inactive after 6/18) Alive Kuo [:alive]]

I notice that fullscreen element also blocks the home button.
The only thing that blocks home button now is FTU, is this correct?

Comment 4

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Alive Kuo [:alive] from comment #3)
> I notice that fullscreen element also blocks the home button.
> The only thing that blocks home button now is FTU, is this correct?

FTU seems a legitime case.

Comment 5

[Josh Carpenter [:jcarpenter]]

(In reply to Alive Kuo [:alive] from comment #3)
> I notice that fullscreen element also blocks the home button.
> The only thing that blocks home button now is FTU, is this correct?

That's correct: FTE should block the Home button because it's a special case. 

At one point we discussed having prompts block Home (ala iOS), but decided not to take that approach for v1.

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: PR6552

https://github.com/mozilla-b2g/gaia/pull/6552

Make home button not blocked by anything, except FTU.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

Renaming the bug title per #5

Comment 8

[Josh Carpenter [:jcarpenter]]

And lock screen, of course, but that seems pretty obvious.

Comment 9

[Alex Keybl [:akeybl]]

Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 683970 [details]
PR6552

r=me. We have discuss the desired behavior offline. Thanks!

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

https://github.com/mozilla-b2g/gaia/pull/6552

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

Seems something broken after merging, reverting and reopen.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

After reverting, the problem still happens after ftu running.
I bet something is wrong in ftu. I am going to merge my patch again.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Alive Kuo [:alive] from comment #13)
> After reverting, the problem still happens after ftu running.
> I bet something is wrong in ftu. I am going to merge my patch again.

I am sorry, I think mistaken this with another bug. Have you merge this patch again? If not please do so (it is still considered r+'d)

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

https://github.com/mozilla-b2g/gaia/commit/adfca85f08b55dde18b97d5ac185e13181555c64