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

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

[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.

Poor user experience, incorrect functionality

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

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?

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.

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

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

Possibly broken by bug 1074043 - can you take a look 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.

Aus is debugging

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)

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

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.

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 on attachment 8531368 [details] Pull Request - PopupWindow should use rearWindow for appChrome information LGTM!

Comment on attachment 8531368 [details] 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.

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.

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

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

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

Commit (v2.1): https://github.com/mozilla-b2g/gaia/commit/0e9aea35291b961a927ab90183b3326253416b19 Fixed on 2.1 as well.

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