1044056 - Status bar does not get opaque when changing wallpaper from the homescreen

Status: RESOLVED FIXED

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

Description

[Johan Lorenzo [:jlorenzo]]

We've already talked about it during the work week, but I have not managed to find the bug. If it has been filed, dupe my bug and I'm sorry for the noise. 

Build Information
Device: Flame
Gaia      29266e18c35f4e72e35f1bba0e34f2fb6b995cc3
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/178fe2efc41d
BuildID   20140724000201
Version   32.0
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
B1TC00011220

Steps to Reproduce
1. Go to the top of the Homescreen
2. Long press an empty space
3. Change wallpaper
4. Choose "wallpaper"

Actual Results
Status bar is still transparent.

Reproduction Frequency: 100%

[Blocking Requested - why for this release]: Like bug 1033926 comment 8, we want to get rid of the transparent status bar in the whole 2.0 version.

Comment 1

[Jason Smith [:jsmith]]

Flagging qawanted to screenshot of the bug.

Comment 2

[Johan Lorenzo [:jlorenzo]]

Attachment: Transparent status bar while choosing wallpaper - screenshot

Comment 3

[Kevin Grandon :kgrandon]

Alive/Vivien - before someone works on a patch for this do you have a preference on how to solve this for 2.0? In 2.1 we can use the theme-color functionality for this and I think everything would work, but in 2.0 we have this awful IAC communication from the homescreen to the system app.

Is uplifting theme-color and some statusbar tweaks to 2.0 possible?

Comment 4

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

For uplifting it's a question to Vivien, but I will say no to stay safe.

If this is a blocker, for v2.0 we could do: make statusbar listen to activityopened/activityclosing event to change its background.

Comment 5

[Kevin Grandon :kgrandon]

Yeah, I guess it's a bit painful because right now the homescreen resets the state after a setVisible() call, which I don't think we get after an activity close? Because we base the state off of scroll position, the homescreen is the one that needs to set the current state after coming back from an activity.

Comment 6

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

(In reply to Kevin Grandon :kgrandon from comment #5)
> Yeah, I guess it's a bit painful because right now the homescreen resets the
> state after a setVisible() call, which I don't think we get after an
> activity close? Because we base the state off of scroll position, the
> homescreen is the one that needs to set the current state after coming back
> from an activity.

We could "save the state" corresponding to the scrolling state of homescreen app in homescreenWindow or somewhere using the event from IAC from homescreen app. Statusbar could check the state of active app window and the activity window state in the appWindow to change its color.

Comment 7

[Kevin Grandon :kgrandon]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> (In reply to Kevin Grandon :kgrandon from comment #5)
> We could "save the state" corresponding to the scrolling state of homescreen
> app in homescreenWindow or somewhere using the event from IAC from
> homescreen app. Statusbar could check the state of active app window and the
> activity window state in the appWindow to change its color.

Yeah, that seems better than a crazy IAC hack or similar. Let's do that for 2.0 if we need to.

Comment 8

[Kevin Grandon :kgrandon]

Attachment: Pull request to v2.0

Something like this might work.

Comment 9

[Kevin Grandon :kgrandon]

Comment on attachment 8463800 [details] [review]
Pull request to v2.0

Alive - this would only be needed for v2.0. What do you think?

Comment 11

[Stephany Wilkes]

Though it very much pains me to say this as a UX person in triage (where we are discussing this), I don't think this is a blocker at this stage in the game. </3  <- That is my broken heart.

Comment 12

[Kevin Grandon :kgrandon]

Hmm, is there any way to request approval for this patch to go into 2.0 then? If we don't deem it a blocker, then there is no way to fix it at all? =/

Comment 13

[Stephany Wilkes]

Ni? to Jason to speak to the process question in comment #12.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Kevin Grandon :kgrandon from comment #12)
> Hmm, is there any way to request approval for this patch to go into 2.0
> then? If we don't deem it a blocker, then there is no way to fix it at all?
> =/

To my understanding, we're past the FC deadline, so we're no longer taking approvals for 2.0. We can certainly get this fixed for 2.1 though.

Comment 15

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

Comment on attachment 8463800 [details] [review]
Pull request to v2.0

Smart one. Not sure what happens if we have multiple inline activities.

Comment 16

[Kevin Grandon :kgrandon]

If this does not block, then we don't need to fix it as it's already fixed for 2.1. Marking as fixed (2.0 affected).

Comment 17

[Paladin]

This issue has been verified successfully on Flame 2.1

See attachment: Verify_image.png
Reproducing rate: 0/5
Flame 2.1 versions:
Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194
Build-ID        20141203001205
Version         34.0

Comment 18

[Paladin]

Attachment: Verify_image.png