Closed Bug 1062820 Opened 5 years ago Closed 5 years ago

Home screen and status bar behave different after clicking 'home' button among versions

Categories

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

All
Gonk (Firefox OS)
defect
Not set

Tracking

(b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S4 (12sep)
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: crdlc, Assigned: crdlc)

Details

(Keywords: polish, Whiteboard: [systemsfe])

Attachments

(1 file)

STR:

1) Scroll down a bit the vertical home screen
2) Pull down the utility try
3) The status bar is displayed
4) Click on 'home' button

v2.0:

The status bar is hidden and the home screen does nothing (from my point of view the behavior expected as user)

v2.1

The status bar is not hidden but the home screen scrolls to search field

v2.2 (master)

The status bar is hidden and the home screen scrolls to search field

At least I could see it, if I am wrong please close the bug
or maybe the behavior expected is implemented on master (I have seen other OS and it behaves like FFOS 2.2)
Francis, can you take a look here?
Flags: needinfo?(fdjabri)
Whiteboard: [systemsfe]
Over to you, Rob.
Flags: needinfo?(fdjabri) → needinfo?(rmacdonald)
Thanks, Cristian...

This is a gap in the specs due to some last minute changes in 2.1. But now that you've brought it to my attention, the first tap should close the utility tray and the second tap should return the user to the top of the home screen. (As you suspected.)

Flagging Gregor and Michael to assess feasibility at this stage.

- Rob
Flags: needinfo?(rmacdonald)
Flags: needinfo?(mhenretty)
Flags: needinfo?(anygregor)
The correct behavior for 2.2 is specified in comment 4. We will make it a non-blocking polish bug. If we get to it in time, let's request uplift to 2.1.
Flags: needinfo?(mhenretty)
Flags: needinfo?(anygregor)
Keywords: polish
I try to take a hand in this bug today
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Attached file Github pull request
Thanks Michael for your time
Attachment #8486284 - Flags: review?(mhenretty)
Comment on attachment 8486284 [details]
Github pull request

Thank you for taking this Christian!

It is really too bad we have to deal with a race condition between two system modules to handle this properly. I left some comments on github. I also think we really need an integration test for this functionality. Can you please add one?

Thinking about this more, we could have AppWindowManager only call homescreen.ensure() if UtilityTray is not shown. But that couples UtilityTray and AppWindowManager.

It's sad we need help on such a "simple" bug, but I think we need to call in the gatekeeper. Alive, can you take a look at this patch and advise the best approach here?
Attachment #8486284 - Flags: review?(mhenretty)
Attachment #8486284 - Flags: review?(alive)
Attachment #8486284 - Flags: feedback+
Comment on attachment 8486284 [details]
Github pull request

My idea would be implement UtilityTray.preInit() (listen home) and call it in utility_tray.js so we don't need to change statusbar.js

And please note this is an anti-pattern we need to correct in the future depnedency resolving work.
Attachment #8486284 - Flags: review?(alive)
Comment on attachment 8486284 [details]
Github pull request

Addressed comments
Attachment #8486284 - Flags: review?(alive)
Attachment #8486284 - Flags: review?(alive) → review+
Merged in master:

https://github.com/mozilla-b2g/gaia/commit/24fb519181335ff2fcf3a32cf1b775685f9089cf
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Comment on attachment 8486284 [details]
Github pull request

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined: user experience bad although nothing terrible
[Testing completed]: yes, manually and added new integration test
[Risk to taking this patch] (and alternatives if risky): close to null
[String changes made]: no
Attachment #8486284 - Flags: approval-gaia-v2.1?
Attachment #8486284 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
This issue is verified fixed on Flame 2.1 and 2.2.

Result: Status bar is shown on the utility tray. First tap on the home button closes the utility tray, and second tap scrolls up to the top of the screen.

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141031001201
Gaia: f89c7b12c36572262c9ea76058694a139b1a8634
Gecko: 50d48f8a04c7
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141031061804
Gaia: a07994714f0552f89801d6097982308d8b0a1ee1
Gecko: 6bd2071b373f
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.