Closed Bug 1033926 Opened 10 years ago Closed 10 years ago

[Vertical Homescreen] Statusbar does not get opaque after exiting an app using the keyboard and re-entering it

Categories

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

defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S5 (4july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: ich, Assigned: crdlc)

References

Details

(Whiteboard: [systemsfe])

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140611075517

Steps to reproduce:

1. Put an app, which uses the keyboard, into the first row of the vertical homescreen.
2. Open the app, use an input so that the keyboard is shown.
3. Push the home button.
4. Open the app again.


Actual results:

The statusbar is transparent.


Expected results:

The statusbar should be opaque.
Thank you for filing this bug. It appears that the build you use is a bit old (from the 11th of June). Bug 1032122 should have fixed this issue. Can you try again with a build from this month?

Thanks!
Summary: Statusbar does not get opaque → [Vertical Homescreen] Statusbar does not get opaque
Ooops, I think I have filed the bug with my desktop machine. :)

My current build is 20140703185320.  Built this afternoon.  The issue persists.
Attached video Non opaque statusbar - Video (obsolete) —
You're right. It's also in the latest build. Good catch!
We tried to avoid the non-opaque status bar for 2.0. Would this case be a blocker from a UX perspective? See video in comment 3 for details.
Blocks: 1015336
Status: UNCONFIRMED → NEW
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?]
Ever confirmed: true
Flags: needinfo?(firefoxos-ux-bugzilla)
Whiteboard: [systemsfe]
Renaming the title to be more explicit about the edge case.
Summary: [Vertical Homescreen] Statusbar does not get opaque → [Vertical Homescreen] Statusbar does not get opaque after exiting an app using the keyboard and re-entering it
The video here is missing a part of the phone that needed to be seen to identify the bug, since the current video does not accurately identify the bug as written.
Keywords: qawanted
Comment on attachment 8450509 [details]
Non opaque statusbar - Video

I don't how this video has been cropped. But here is the same hosted on Google Drive: http://mzl.la/1mp9WR7
Attachment #8450509 - Attachment is obsolete: true
Keywords: qawanted
This is a blocker since UX has indicated already that any instance of a transparent status bar appearing when it shouldn't be is a blocker for 2.0 visual refresh. This isn't a vertical homescreen bug though, so I'm removing the flags for that.
No longer blocks: 1015336
blocking-b2g: 2.0? → 2.0+
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking?]
Component: Gaia::Homescreen → Gaia::System
Flags: needinfo?(firefoxos-ux-bugzilla)
Just CCing myself here. I will try to investigate this when I get some time - it could actually be a homescreen bug still, so I'm not *fully* ruling that out.

What could be happening is that some async message is not happening quick enough, and we end up with a delayed state.
(In reply to Kevin Grandon :kgrandon from comment #9)
> Just CCing myself here. I will try to investigate this when I get some time
> - it could actually be a homescreen bug still, so I'm not *fully* ruling
> that out.
> 
> What could be happening is that some async message is not happening quick
> enough, and we end up with a delayed state.

Okay, I'll tag as a VH bug for now.
Blocks: 1015336
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
If you follow these steps you can see how the 'homescreenclosing' [1] is not dispatched so this rule [2] is not applied

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/homescreen_launcher.js#L225
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/style/statusbar/statusbar.css#L36

Alive, do you know where could be the issue? Thanks a lot
Flags: needinfo?(alive)
Commented on IRC so clearing needinfo
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Flags: needinfo?(alive)
Attached file Github pull request
Thanks for your time
Attachment #8450853 - Flags: review?(alive)
Comment on attachment 8450853 [details]
Github pull request

r=me thank u
Attachment #8450853 - Flags: review?(alive) → review+
Merged in master:

https://github.com/crdlc/gaia/commit/8dab4044b82dc3a165a2551cc521f6b47aed1958
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S5 (4july)
Attached video verify_video.MP4
This issue has been verified successfully on Flame v2.1 & v2.0
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.1 versions:
Gaia-Rev        5655269098c7e82254e56933f1af05b4abe2a2f3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/86608c9389b5
Build-ID        20141204001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141204.034958
FW-Date         Thu Dec  4 03:50:09 EST 2014
Bootloader      L1TC00011880

Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ff1100ba2ab8
Build-ID        20141204000228
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141204.040425
FW-Date         Thu Dec  4 04:04:36 EST 2014
Bootloader      L1TC00011880
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: