948208 - Intermittent and unexpected display of white (flash) appears on device when launching some apps w/o body { background-color }

Status: RESOLVED FIXED

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

Description

[Montoya Clemmons (MClemmons)]

When user taps Clock app for the first time after device reset or changes the language on device and selecting the Clock app thereafter causes a brief (1 second) flash of light to appear before the app opens to the main screen. 

Repro Steps:
1) Updated Buri to COM BuildID: 20131209053402
2) Tap Settings App
3) Tap Language
4) Change language from Espanol to English 
5) Tap Clock App

Actual:
Brief flash of light appears on black backdrop before Clock App opens

Expected:
Clock App opens without brief flash of light

Environmental Variables:
Device: Buri v1.3 COM RIL
BuildID: 20131209053402
Gaia: 1d45d1dc3201059d5c8f2efdeb92c04576d8e161
Gecko: 9f12a9fab080
Version: 28.0a1
RIL Version: 01.02.00.019.102

Notes:

Repro frequency: (60% - 12 out of 20)
See attached: video clip - URL on youtube (http://youtu.be/W6V2GzueDTE)
Other notes: Able to reproduce intermittently when tapping Calendar App and Usage App without going through STR from above

Comment 1

[Montoya Clemmons (MClemmons)]

I was unable to reproduce the issue reported in Comment 0 for Buri 1.2 with the below Environmental Variables after 20 attempts. Attempted the STR from Comment 0 as well as the Other notes section from Comment 0. 

Environmental Variables:
Device: Buri v1.2 COM RIL
BuildID: 20131120004000
Gaia: 5ec2963fff60492c840707df8d8090f9908a5251
Gecko: 2d454e0de2ed
Version: 26.0
RIL Version: 01.02.00.019.102

Comment 2

[Jason Smith [:jsmith]]

That's an old 1.2 build. Can you test this on the most recent 1.2 build?

Comment 3

[Roland Kunkel [:RolandK]]

(In reply to Jason Smith [:jsmith] from comment #2)
> That's an old 1.2 build. Can you test this on the most recent 1.2 build?

I was unable to reproduce this issue in the latest Buri 1.2 build. Opening the Clock app after switching languages did not produce a white flash. I was also unable to produce the white flash by cycling through the Calendar App and Usage App while testing.

1.2
Environmental Variables:
Device: Buri v1.2 COM RIL
BuildID: 20131216004002
Gaia: fcf1c2fe020c29da4755621cbffdc1a333a43be9
Gecko: 129ad3c335a5
Version: 26.0
RIL Version: 01.02.00.019.102
Firmware Version: V1.2_US_20131115

Comment 4

[Jason Smith [:jsmith]]

Looks like a window manager regression.

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

It doesn't looks like a window manager regression to me. The flash of white looks like to be drawn by Gecko. Gaia only replaces the cold launch icon splash when it receives firstpaint event and from what I saw (reproduced locally on a Buri) the white flash briefly covers the cold launch splash and gone. This indicates that Gaia did not remove the splash prematurely.

BenWa, is it possible something cause this regression?

Alive, could you validate my statement here? Not sure if the timing have changed since last time I look at the v1.3 codebase.

Comment 6

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

In 1.2~1.3 it's not firstpaint but loadend event to remove the splash background.
I wonder this is an issue that clock loads complete but the whole UI part is still async loading by require. Not sure though.

Comment 7

[Roland Kunkel [:RolandK]]

(In reply to Jason Smith [:jsmith] from comment #4)

Regression window

- Last Working -

12/1 working
Environmental Variables:
Device: Buri v1.3 COM RIL
BuildID: 20131201040201
Gaia: f23aebebcd28c4d19347def77c4836c8baebc2ce
Gecko: 84a5a5800bd3
Version: 28.0a1
RIL Version: 01.02.00.019.102
Firmware Version: V1.2_US_20131115

- First Broken -

12/2 broken
Environmental Variables:
Device: Buri v1.3 COM RIL
BuildID: 20131202092621
Gaia: 8527840366eec3252d04e0dad64e7a40dbe3dc56
Gecko: 2581b84e0ca1
Version: 28.0a1
RIL Version: 01.02.00.019.102
Firmware Version: V1.2_US_20131115

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> In 1.2~1.3 it's not firstpaint but loadend event to remove the splash
> background.
> I wonder this is an issue that clock loads complete but the whole UI part is
> still async loading by require. Not sure though.

Mike, is the regression range confirm this speculation?

I thought this could be graphics bug, however the fact this only happen to Clock make me very suspicious.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #9)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> > In 1.2~1.3 it's not firstpaint but loadend event to remove the splash
> > background.
> > I wonder this is an issue that clock loads complete but the whole UI part is
> > still async loading by require. Not sure though.
> 
> Mike, is the regression range confirm this speculation?
> 
> I thought this could be graphics bug, however the fact this only happen to
> Clock make me very suspicious.

Note - this actually can happen with other apps. As comment 0 cites, this is also seen with the Calendar app & Usage app.

Comment 11

[Mike Pennisi [:jugglinmike]]

I don't think this is related to Clock's use of AMD because the `index.html`
loads the stylesheet defining the application background color directly inside
the document `<head>` element [1][2].

[1] https://github.com/mozilla-b2g/gaia/blob/ab9a57738ceb871b5335bb99cd720148686f842f/apps/clock/index.html#L12
[2] https://github.com/mozilla-b2g/gaia/blob/ab9a57738ceb871b5335bb99cd720148686f842f/apps/clock/style/views.css#L3

Additionally, there was no change to the application in the provided regression
window:

    $ git log f23aebebcd28c4d19347def77c4836c8baebc2ce..8527840366eec3252d04e0dad64e7a40dbe3dc56 apps/clock/
    $

Due to this and the apparent reproducability in the Calendar and Usage apps, I
suspect this to be a regression in shared code.

In case it helps, I'll include some additional Gaia commit histories in that
window:

`shared/`:

    $ git log f23aebebcd28c4d19347def77c4836c8baebc2ce..8527840366eec3252d04e0dad64e7a40dbe3dc56 shared
    commit 94a9dd6339888a5dfd329ddf559265b62c8470fa
    Author: Joan Leon <[e-mail]>
    Date:   Thu Nov 28 16:59:19 2013 +0100
    
        [BB] Fix to pass W3C Validator
        
        Fix font-size on shared/style_unstable/lists.css on [data-type="list"]
        aside.icon
    $

`apps/system/`:

    $ git log f23aebebcd28c4d19347def77c4836c8baebc2ce..8527840366eec3252d04e0dad64e7a40dbe3dc56 apps/system/
    commit 5e99c9981e18cb4d51a5b2419d23b3ed00f9655c
    Author: Jan Jongboom <[e-mail]>
    Date:   Mon Dec 2 18:27:23 2013 +0100
    
        Revert "Merge pull request #14262 from comoyo/935904"
        
        This reverts commit 5684cd760e1644138cbe4733277b3ae442a9bda3, reversing
        changes made to 84e58eb4d0a22a10dabfce9d6c28f60b5e50339e.
    
    commit 54d135750afb88fd1f739637c1b121aecb620301
    Author: Vivien Nicolas <[e-mail]>
    Date:   Mon Dec 2 16:49:21 2013 +0100
    
        Bug 944686 - Orientation is wrong when receiving a call while using a landscape mode app. r=alive
    
    commit 9bc437ee2ef092ad32176db12122dedec331e524
    Author: Jan Jongboom <[e-mail]>
    Date:   Mon Dec 2 14:44:43 2013 +0100
    
        Bug 935904 - Un-intermittent test in keyboard_manager
    
    commit 1fcba5ec3b951895ceec6f06e6da1e6ec0dd3bd7
    Merge: f64d282 fc3ef53
    Author: GaryChen(pychen) <[e-mail]>
    Date:   Sun Dec 1 19:11:10 2013 -0800
    
        Merge pull request #14227 from mpizza/Bug_941567_patch_2
        
        Bug 941567 - [Keyboard][V1.2] The keyboard name of notification bar is incorrect. r=timdream.
    
    commit fc3ef53f0bbaf297e9177ece1d4390fd8788233b
    Author: mpizza <[e-mail]>
    Date:   Fri Nov 29 17:23:31 2013 +0800
    
        Bug 941567 - [Keyboard][V1.2] The keyboard name of notification bar is incorrect
             -- since keyboard show timing is depends on 'mozbrowserresize' event,
                so call 'showIMESwitcher' in the end of 'resizeKeyboard'
                to make sure refresh latest information at each time while keyboard layout is chnaged.
             -- ignore mozbrowserresize event while keyboard Frame is hidding.
    $


And to :jsmith's thought about a possible window manager regression in comment
4, there was no change to that specific JavaScript source file in the window
(although I'm not fully aware of its intricacies, so there may be other places
to look for change):

    $ git log f23aebebcd28c4d19347def77c4836c8baebc2ce..8527840366eec3252d04e0dad64e7a40dbe3dc56 apps/system/js/window_manager.js
    $

Comment 12

[Tony Chung [:tchung]]

severe usage regression.  1.3+.

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

Related to bug 914847, although 1 second vs. 50ms doesn't quite match...

Comment 15

[Sri Kasetti]

Product team triaged this, will leave it a blocker..

Comment 16

[Benoit Girard (:BenWa)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #5)
> BenWa, is it possible something cause this regression?

Sorry for the late response. This could of been bug 917416 but it has since be backed out. Does this still occur?

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Asking QA to reproduce.

Comment 18

[Sarah Parsons]

I can reproduce this issue on the latest Buri 1.3 Build ID: 20140121004137

Gaia   47049555282a9a01fb60d1e1421b57e2810c96f5
SourceStamp 6f7dfe36ab6c
BuildID 20140121004137
Version 28.0a2

However, it only reproduces once when the device is freshly factory reset.

Comment 19

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Sarah Parsons from comment #18)
> 
> However, it only reproduces once when the device is freshly factory reset.

Let's re-triage.

Comment 20

[Jason Smith [:jsmith]]

Sarah - I'm unsure if you are reproducing the same bug here. Can you clarify if the original STR without using factory reset allows you to still reproduce the bug here?

Comment 21

[Sarah Parsons]

When following the steps in comment 0, I can reproduce the issue intermittently and not to the severity of what the video shows. However, when resetting the device, and only selecting the clock app, I can reproduce the "lightning flash" issue that is shown in the video but only once per reset. 

I do not believe changing the language is required to reproduce this issue. 

Alternative STR:

1. Flash to current 1.3 Build.
2. Reset Device. Settings - More Info- Reset Device
3. Go through FTE.
4. Open Clock App.

Comment 22

[Jason Smith [:jsmith]]

That implies we're still seeing the same bug, so moving to back to blocking for the same reasons it was originally blocking for.

Comment 23

[Andreas Gal :gal]

This is a 1.3 blocker and nobody is assigned. This smells like gfx to me so assigning Milan until we find someone else to own it. This is blocking one of our OEMs.

Comment 24

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Andreas Gal :gal from comment #23)
> This is a 1.3 blocker and nobody is assigned. This smells like gfx to me so
> assigning Milan until we find someone else to own it. This is blocking one
> of our OEMs.

Sure.  We were discussing whether it was 1.3+ or not, and during that time it stayed unassigned.  BenWa, can you reproduce this on hamachi/buri?

Comment 25

[Milan Sreckovic [:milan] (needinfo for best results)]

I do see it on unagi.

Comment 26

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Milan Sreckovic [:milan] from comment #25)
> I do see it on unagi.

Though not every time.  BenWa guessed racing, and that's probably right, as when I waited 5-10 seconds after FTE before getting into the clock app, I couldn't reproduce the problem.

Comment 27

[Benoit Girard (:BenWa)]

I'm going to call it now and say this isn't a graphics bug.

This looks like it has to do with loading the app takes awhile. If we don't load it fast enough then paint suppression will timeout and we will paint whatever we have now. In this case we need to parse the CSS style sheet and get to parsing the DOM before we know the background is black. Before that we default to a white body background. The clock app is loading many resources before that happens so I'm not surprised that without any populated caches we don't do that within 250ms before the paint suppression timer times out.

Comment 28

[Benoit Girard (:BenWa)]

Attachment: patch

Here's the patch. I verified it for the hamachi and it works. Can we resign to someone on the Clock app to very on their end and submit the pull request?

Comment 29

[Jason Smith [:jsmith]]

(In reply to Benoit Girard (:BenWa) from comment #28)
> Created attachment 8364625 [details] [diff] [review]
> patch
> 
> Here's the patch. I verified it for the hamachi and it works. Can we resign
> to someone on the Clock app to very on their end and submit the pull request?

Note - the bug here to my understanding happens across apps, not just the Clock app. The dupe for example happens in the calendar app. If there was a fix needed here on the Gaia side, then I'd imagine we would need to fix this in the app transitions of the system app.

Alive - What do you think?

Comment 30

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I tend to think the simplest solution here is to set background-color to body on all apps. That would reliability work against any timing issue on Gaia window management and Gecko.

(BenWa gets the credit here)

Comment 31

[Benoit Girard (:BenWa)]

(In reply to Jason Smith [:jsmith] from comment #29)
> Note - the bug here to my understanding happens across apps, not just the
> Clock app. The dupe for example happens in the calendar app. If there was a
> fix needed here on the Gaia side, then I'd imagine we would need to fix this
> in the app transitions of the system app.

We load pages progressively. Right now the platform gives a 250ms delay to load the important bits of the app. Optimizing app loads, even if your loading from the disk instead of the network, is important and should follow best practices for websites. My fix gets the background color to load faster.

You can investigate tweaking the app switch color as well to mitigate the perception of the problem.

The third option is to revisit the paint suppression behavior. I wouldn't do this lightly but it's not my area of expertise.

Comment 32

[Mozilla Shepherd (This account is used for automation and doesn't receive bugmail)]

Attachment: mozilla-b2g:master PR#15716

Comment 33

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8365864 [details] [review]
mozilla-b2g:master PR#15716

Re-cap on what is discussed with Alive:

* background/splash is not being removed all way until mozbrowserloadend -- this did not change since the feature was first introduced in bug 866174, subsequent move of the logic did not change that either.
* the fact it only reproduced on one device make it very suspicious that this is a loading/painting/timing issue on the platform side, but since BenWa has not identified any and have find a fix, I am happy to take it.
* the fix is probably doesn't count as a workaround since setting a background-color on body at the very beginning of the very first style sheet is exactly what people do to prevent FOUC, and Gaia should do that too.

I hope the above conclusion justified the patch given.

Comment 34

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

Comment on attachment 8365864 [details] [review]
mozilla-b2g:master PR#15716

r+ iff black background doesn't bring another kind of 'flash' to apps other than clock app.
If so please use white background.

Comment 35

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #34)
> Comment on attachment 8365864 [details] [review]
> mozilla-b2g:master PR#15716
> 
> r+ iff black background doesn't bring another kind of 'flash' to apps other
> than clock app.
> If so please use white background.

That shouldn't be a problem since the black background always follow icon splashes.

Comment 36

[Tim Guan-tin Chien [:timdream] (please needinfo)]

master: https://github.com/mozilla-b2g/gaia/commit/55f12867cde081a78611cb3e884c4b4f5f2600f0

Comment 37

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 55f12867cde081a78611cb3e884c4b4f5f2600f0 to:
v1.3: 207bc631c38d5dbb4e2a93cd4b9487a0324e8209