1100714 - [Window Mgmt] Status bar changes/stays white in some apps

Status: VERIFIED FIXED

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

Description

[Corinne Innes [:CorinneI]]

Attachment: 2014-11-17-10-34-52.png

Description:
After the user has an FTE setup the status bar will change or stay white when  accessing the Date & Time or Browser app.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141117001201
2) Progress through FTE until at the homescreen
3) Open Settings>Date & Time
4) Tape the "Set Automatically" toggle
  
Actual:
Status bar color will change to white 
  
Expected: 
Status bar stays grey and legible
  
Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141117001201
Gaia: 81160ad79e5b4c21967418dd63f1a1d08d77924e
Gecko: 3572aa3e6766
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Notes: Can occur when user first navigates to a website through the browser app.
  
Repro frequency: 100%
See attached: Screenshot, logcat

Comment 1

[Corinne Innes [:CorinneI]]

Issue DOES occur on Flame 2.2, but does need slightly different repro

Flame 2.2

Device: Flame 2.2 (319mb)(Kitkat Base)(Shallow Flash)
Build ID: 20141117040203
Gaia: ddf5b92f43ec27c93ad4fea4fd1207da8936b8e7
Gecko: 21b745197618
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

STR:
1) Update flame to build: 20141117040203
2) Progress through FTU
3) Open Browser app
4) Search fly or die games
5) Open flyordie.com
6) Open a game
7) While game loads lock and then unlock phone

Actual: 
White status bar appears

Issue does NOT occur on Flame 2.0

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141117000200
Gaia: 086a668942292168f312b3bb53e275fa0886fab1
Gecko: a57b299c5cf2
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual:
Status bar never changes color

Comment 2

[Corinne Innes [:CorinneI]]

Attachment: logcat.txt

Comment 3

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

[Blocking Requested - why for this release]:

User should always be able to see status bar icons. White on white makes all icons in the status bar very difficult to see.

This is related to bug 1055746 which was verified fixed.

Comment 4

[Candice Serran (:cserran)]

Poor user experience, incorrect functionality

Comment 5

[Alberto Pastor [:albertopq]]

I couldn't reproduce neither in 2.1 or 2.2, using today's build (20141120040205). Flagging qawanted to double check.

Comment 6

[Gregor Wagner [:gwagner]]

Does this only happen after the FTU completes?
So this issue doesn't show up after for example rebooting and opening the browser or the Date & Time?

Comment 7

[Marcia Knous [:marcia]]

I was able to reproduce this on Flame using - I see it just loading the site after OTA'ing and using the device for some time, and not just right after FTU.

Gaia   1abe09b4925547699dfdb2d358aed019137c3aa6
SourceStamp 6ce1b906c690
BuildID 20141120040205
Version 36.0a1
v188

and

Gaia   f8d3bf44029e0afc0124600a4bb34dba8fc1ad21
SourceStamp f70a67a7f846
BuildID 20141120001207
Version 34.0
v188

Following the STR in Comment 1 it shows the status bar white - I grabbed a screenshot as well.

Comment 8

[Gregor Wagner [:gwagner]]

I still can't reproduce :(
Can we get a video?

Comment 9

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Bug 1074043 seems to have been the cause for this issue.

B2g-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20140930123724
Gaia: c02b82ed2c52605dc4ab6227d8f21174d012c74c
Gecko: 3062a7c6804d
Gonk: Could not pull gonk.  Did you shallow Flash?
Version: 35.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20140930125323
Gaia: 22b1698a71db620b1dd04867aba55efbfd9f23d7
Gecko: 5e8aaef2a086
Version: 35.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: c02b82ed2c52605dc4ab6227d8f21174d012c74c
Gecko: 5e8aaef2a086

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: 22b1698a71db620b1dd04867aba55efbfd9f23d7
Gecko: 3062a7c6804d

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/c02b82ed2c52605dc4ab6227d8f21174d012c74c...22b1698a71db620b1dd04867aba55efbfd9f23d7

Comment 10

[Joshua Mitchell (Inactive)]

Possibly broken by bug 1074043 - can you take a look Aus?

Comment 11

[Aus Lacroix [:aus]]

Summary of my findings thus far:

on 2.1 --
  * I CANNOT reproduce with the original STRs in the Description.
  * I CAN reproduce with the STRs in Comment #1

on 2.2 --
  * I CANNOT reproduce with the original STRs in the Description.
  * I CAN reproduce with the STRs in Comment #1.

Comment 12

[Gregor Wagner [:gwagner]]

Aus is debugging

Comment 13

[Aus Lacroix [:aus]]

We appear to be picking the correct window via Service.currentApp. This is the appWindow passed to setAppearance when we unlock the lockscreen.

After calling getTopMostWindow on the appWindow, we end up with the incorrect window. It appears we are using the frame element. 

This in turn will use the wrong appChrome object to determine if we should use light theming for the icons.

I/GeckoConsole( 3140): Content JS LOG: Unlocking to -- https://www.google.com/search?q=fly%20or%20die%20games 
I/GeckoConsole( 3140):     at sb_handleEvent (app://system.gaiamobile.org/js/statusbar.js:354:8)
I/GeckoConsole( 3140): Content JS LOG: Using bottom window?  
I/GeckoConsole( 3140):     at StatusBar.setAppearance (app://system.gaiamobile.org/js/statusbar.js:641:4)
I/GeckoConsole( 3140): Content JS LOG: setAppearance is picking ({containerElement:{}, url:"http://m.flyordie.com/games/fxos/memory.html", name:(void 0), iframe:{setVisible:function method() {
I/GeckoConsole( 3140):     [native code]

[snipped useless information]

I/GeckoConsole( 3140): }, setActive:function metho
I/GeckoConsole( 3140): Content JS LOG: theme window has appChrome? [object Object] 
I/GeckoConsole( 3140):     at StatusBar.setAppearance (app://system.gaiamobile.org/js/statusbar.js:645:4)
I/GeckoConsole( 3140): Content JS LOG: appChrome uses light theming? false 
I/GeckoConsole( 3140):     at StatusBar.setAppearance (app://system.gaiamobile.org/js/statusbar.js:646:0)

Comment 14

[Michael Henretty [:mikehenrty][:mhenretty]]

Hey Aus, any update on the progress here? Can I help investigate something?

Comment 15

[Aus Lacroix [:aus]]

I actually know what's going on with this. Figuring out the best way to fix it. Should have something ready and done by the end of this week.

Comment 16

[Aus Lacroix [:aus]]

Attachment: Pull Request - PopupWindow should use rearWindow for appChrome information

Asking for feedback to ensure I'm on the right track with this patch. If I am, I will remove the debugging code inserted and add a test to cover this particular case.

Comment 17

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

Comment on attachment 8531368 [details] [review]
Pull Request - PopupWindow should use rearWindow for appChrome information

LGTM!

Comment 18

[Aus Lacroix [:aus]]

Comment on attachment 8531368 [details] [review]
Pull Request - PopupWindow should use rearWindow for appChrome information

Now with a test to cover this particular scenario. I'll have to wait for gaia-try to reopen though so I can make sure the tests are all green.

Comment 19

[Aus Lacroix [:aus]]

Unfortunately I am still waiting on gaia-try to get back up because of an issue on m-c that's preventing our b2g-linux-desktop build from showing up. Hopefully this will be resolved soon and I'll have confirmation that all the tests still run.

Comment 20

[Aus Lacroix [:aus]]

Test run looks good. Intermittent test failures are responsible for the lack of green. I'm retriggering them to get a green pass.

Comment 21

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

Comment on attachment 8531368 [details] [review]
Pull Request - PopupWindow should use rearWindow for appChrome information

r=me

Comment 22

[Aus Lacroix [:aus]]

Commit (master): https://github.com/mozilla-b2g/gaia/commit/81580722b6f7e576a11e7973c0899cd55bd2f24c

Fixed!

Comment 23

[Aus Lacroix [:aus]]

Commit (v2.1): https://github.com/mozilla-b2g/gaia/commit/0e9aea35291b961a927ab90183b3326253416b19

Fixed on 2.1 as well.

Comment 24

[SandKing]

This issue has been verified successfully on Flame2.1&2.2
Verify video:"verify_1100714.mp4".

Flame2.1 build:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141205.035305
FW-Date         Fri Dec  5 03:53:16 EST 2014
Bootloader      L1TC00011880

Flame2.2 bulid:
Gaia-Rev        0e429d970c160e580e19e61ad8ff5612de159f00
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/035a951fc24a
Build-ID        20141207040205
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141207.085047
FW-Date         Sun Dec  7 08:51:07 EST 2014
Bootloader      L1TC00011880

Comment 25

[SandKing]

Attachment: Verified video: verify_1100714.MP4