Fenix: White-to-black-to-white flashing when opening Fenix

[mcomella]

Timebox this to an E3 - do not spend more than that

Steps to reproduce

• Open Fenix from OOM (or swiped close)

Expected behavior

One consistent opening animation

Actual behavior

Two opening animations that don't segue together: Fenix fades alpha fades and translate a white square to the top of the screen, then fades from black to the content displayed on the screen. This is jarring and feels unpolished.

Device information

• Android device: Pixel 2
• Fenix version: 1.0.1908

_edit: here's a recording of the animation: https://drive.google.com/file/d/1k0-3V_8EiK_etpJnzk7lT4ZFCjPwPSoD/view?usp=sharing_

[AmyYLee]

@mcomella Can you post a recording of the animation?

[mheubusch]

UX is currently blocked awaiting findings from Perceived Performance testing.

[mcomella]

@mcomella Can you post a recording of the animation?

I updated the first comment with a link to a recording of the animation. A reminder that it only happens the first time Fenix launches from OOM (i.e. after a swipe closed).

[bifleming]

@mheubusch @vesta0 is this still blocked?

[vesta0]

@AmyYLee will provide design for a splash screen.

[AmyYLee]

@mcomella Can we have it fade from white to the content instead of black so you don't see that flash?
Also @shorlander wants to avoid having a splash screen if we don't need one.

[mcomella]

@mcomella Can we have it fade from white to the content instead of black so you don't see that flash?
Also @shorlander wants to avoid having a splash screen if we don't need one.

Yep, that's what I was expecting.

[AmyYLee]

While this is under investigation of if we need a splash screen or not, if the conclusion is that we do they are below:

Fenix Preview: https://mozilla.invisionapp.com/share/DSRX4Y14VN8
Fenix: https://mozilla.invisionapp.com/share/BFRX4Y72WNC

[sblatz]

So is the decision that we are moving forward with this splash screen?

@vesta0, @mheubusch

[vesta0]

@AmyYLee I just read your note above and it's not clear what the result of your investigation was. Are we using splash screens? I vote yes.

[AmyYLee]

@mcomella Can we have it fade from white to the content instead of black so you don't see that flash?
Also @shorlander wants to avoid having a splash screen if we don't need one.

Can someone confirm if this was fixed? (fade from white to the content). @st3fan Is there an update on performance testing to see what our load time is?

[vesta0]

@AmyYLee I sent you a link of our cold page load.

Looks like this is not ready for engineering. @AmyYLee I will leave this to you to follow up on.

[mcomella]

@mcomella Can we have it fade from white to the content instead of black so you don't see that flash?
Also @shorlander wants to avoid having a splash screen if we don't need one.

Can someone confirm if this was fixed? (fade from white to the content).

It's not fixed.

[AmyYLee]

@mcomella Can we have it fade from white to the content instead of black so you don't see that flash?
Also @shorlander wants to avoid having a splash screen if we don't need one.

Can someone confirm if this was fixed? (fade from white to the content).

It's not fixed.

Please let me know when this is fixed and I'll review it. Thanks

[sblatz]

@AmyYLee I think we need feedback on this comment before engineering can take this over.

[AmyYLee]

@AmyYLee I just read your note above and it's not clear what the result of your investigation was. Are we using splash screens? I vote yes.

@shorlander wants to avoid using splash screens so can we fix this without the splash screen? @sblatz @vesta0

[AmyYLee]

@AmyYLee I sent you a link of our cold page load.

Looks like this is not ready for engineering. @AmyYLee I will leave this to you to follow up on.

Where is this link?

[lime124]

@vesta0 @AmyYLee @sblatz - I'm getting turned around :)

It looks like vesta sent Amy a link to review but Amy can't find the link. Can you paste it here?

Sawyer - are we able to fix the issue without a splash screen?

Thanks!

[sblatz]

@lime124

I am not aware of a way to do this without a splash screen. Of note:

1. Firefox uses a splash screen
2. Chrome does not

Demo of current implementation

[vesta0]

@lime124 the link I sent to Amy on slack was to answer a question she had about page load and it's this one: https://health.graphics/android

[mcomella]

wrt demo of current implementation https://github.com/mozilla-mobile/fenix/issues/599#issuecomment-513008061, I don't think the fade from white-to-black-to-layout will be as noticeable in dark mode. Sawyer, come find me if you want me to demonstrate!

[lime124]

adding to triage - idk how or what is needed to get this to a resolution. can it be discussed as a group and next steps/actions outlined? thanks!

[sblatz]

Demo of Light Mode

[bifleming]

@boek do we need a spike to investigate something for this story?

[boek]

@bifleming it has a needs:investigation label, so the output of this task in the sprint is the spike :) We could create a new issue if that is better

[bifleming]

In discussion with Jeff, we feel that the investigation and work can likely be done in the same sprint (neither appears to be a big task, and the size of effort not likely to change significantly due to investigation results).

[liuche]

@boek can you add more clarity to this bug, and what needs to be done?

No spike, but what is the proposed fix?

[colintheshots]

In my initial investigation, it was very possible to include a window background before any app activity starts up that serves as a splash screen. However, one has to take care to specify the background correctly to avoid stretching. If an actual splash screen activity is used instead of a window background, it defeats the purpose altogether and creates more problems.

If no splash screen is used and we decide to have a transparent background, my testing found if no UX action visibly occurs on pressing the launcher icon then the user naturally presses it multiple times and wonders why nothing happened right away. It makes it even more apparent how slow our app cold startup is and feels badly broken. I don't think we can ship this with a fully transparent background and expect good reviews.

[liuche]

This is a long-lived bug, so we should decide what to do soon, and finish this within this sprint (or close this).

@colintheshots will organize a meeting w/ Amy, Shorlander, and Jeff to determine what the requirements are, whether we want to close it, what the constraints are, etc.

[colintheshots]

Here's what I came up with. It's possible to let the Android OS determine what color screen to start with based upon the day or night theme. However, it's not possible to anticipate the color the user chose as a theme inside of Fenix in time to use the right color. That means if the phone's OS is in night mode, we can have our app default to dark mode, but we're certainly not guaranteed to show the right colors.

We can have a launcher screen that looks like the Home screen, but it's not easy to line up UI elements on the launcher screen with the actual home fragment, as the view positions layout differently on different phones and OS versions. I can make the elements the same exact size, but their position may shift slightly on the screen when the real views load in.

In summary, adding a fake home screen using the right light/dark colors doesn't seem possible. Using the right view positions is also very hard as there's no time for layout and measure steps. We must correctly guess the position instead.

[mcomella]

Taking a step back, what is the root cause of the double animation problem? i.e. if we were to go for the natural solution of having one animation directly to the homescreen, what's stopping us from getting there?

[colintheshots]

After a lengthy investigation, I determined that the Android OS does not give us an effective means to present an initial loading window background that matches the user's non-default theme. Here's the doc I wrote up: https://docs.google.com/document/d/1OlnK4BgD8CwhFEbmr_20u0XLAbpUPsxcDPuO2jLTjFk/edit?usp=sharing

Based upon that doc, Stephen, Amy, Jeff, and I met and we decided that the best initial UI to have here is actually the status quo. I'm closing this ticket as fixed.

[mcomella]

Thanks for the thorough write-up, Colin. I think we might be interpreting the core problem differently. From your analysis, it looks like you're concerned about the case that a user's phone theme is different from their Fenix theme and, since we can't predict the overridden preference, we have to display the device theme before we display the overridden theme:

The Android OS offers no means to determine the user’s intended theme before initially launching an app. As a result, we often see a flash of white or black from the underlying theme before the app switches to the intended Day/Night theme choice.

In practice, for a user with a light phone theme but dark Fenix theme, they'd see white -> black homescreen.

However, the reason I filed this bug is because I'm seeing a flash of black even though both of my themes are light. In practice, this looks like: white -> black -> white homescreen.

I think the issue I raised is a solvable problem – most of the apps on my phone don't have this problem – so I'm going to reopen. If I'm misunderstanding or this doesn't make sense, let me know and we can discuss on Zoom.

[mcomella]

I was speaking to @ brendandahl and he mentioned Gecko draws black on some platforms when it starts up (Android may or may not be one of them). One possible reason this issue is happening is:

• We display the default Android Activity entry animation (fade to white)
• Gecko is first to draw and draws black
• Our asynchronous fragment transaction to show the homescreen completes and draws over Gecko

Maybe we can quickly verify this by switching in the system WebView implementation, which might not have the same drawing behavior.

[colintheshots]

Maybe we can quickly verify this by switching in the system WebView implementation, which might not have the same drawing behavior.

Testing this requires reproducing the original problem in the first place. The above videos and steps to reproduce were all about the home screen. Gecko is not visible anywhere in the layout on the home screen nor in the activity. This means I definitely need new steps to reproduce the bug before I can make any progress. This bug is also ultra-old, so I'd verify that the problem hasn't been fixed by theme changes.

[mcomella]

I have reproduced it on the latest Nightly 190912 and the STR is the same:

• Swipe close Fenix
• Open Fenix

Expected

Smooth transition as Fenix is opened

Actual

The launcher fades to white, fades to black, and fades into the homescreen. If you open the original video in QuickTime and use the right arrow to move frame by frame, you'll notice right at you get to the 0:02 duration of the video, there's black on the screen: before that there's white on the screen and after is the white homescreen.

The effect is subtle – I had to show it multiple times to some people in the office before they noticed it and one never did – but I think these types of subtle unpolished bits get noticed in other, hard-to-measure ways ("it doesn't feel snappy" or "it doesn't feel fun") so I think it's worth addressing.

My device has the light theme enabled, as does Fenix.

[mcomella]

Using the emulator (so there might be differences), I added breakpoints to bisect: the issue appears to happen after the end of HomeFragment.onCreateView/onViewCreated but before the start of HomeFragment.onStart. I'm surprised by that because I didn't think the Fragment start-up would yield the UI thread (to allow the animation) until onResume completes.

[mcomella]

I added listeners for some of HomeActivity's lifecycle and some of its fragment's lifecycles:

2019-09-13 11:06:51.264 7100-7100/org.mozilla.fenix.debug E/lol: onActivityCreated: org.mozilla.fenix.HomeActivity@1cd91ce
2019-09-13 11:06:51.825 7100-7100/org.mozilla.fenix.debug E/lol: FragmentCreated: NavHostFragment{4f77af4 (9506943c-b6fa-4b7e-a31f-d7bc5bd4879f) id=0x7f09012e}
2019-09-13 11:06:51.936 7100-7100/org.mozilla.fenix.debug E/lol: onActivityStarted: org.mozilla.fenix.HomeActivity@1cd91ce
2019-09-13 11:06:51.950 7100-7100/org.mozilla.fenix.debug E/lol: FragmentCreated: HomeFragment{92a0f2e (b0be36a1-4bb6-409b-9440-d1593d0abcfc) id=0x7f09012e}
2019-09-13 11:06:52.191 7100-7100/org.mozilla.fenix.debug E/lol: FragmentStarted: NavHostFragment{4f77af4 (9506943c-b6fa-4b7e-a31f-d7bc5bd4879f) id=0x7f09012e}
2019-09-13 11:06:52.196 7100-7100/org.mozilla.fenix.debug E/lol: onActivityResumed: org.mozilla.fenix.HomeActivity@1cd91ce
2019-09-13 11:06:56.062 7100-7100/org.mozilla.fenix.debug E/lol: FragmentResumed: NavHostFragment{4f77af4 (9506943c-b6fa-4b7e-a31f-d7bc5bd4879f) id=0x7f09012e}

--- BLACK FLASH HAPPENS HERE ---

2019-09-13 11:06:56.707 7100-7100/org.mozilla.fenix.debug E/lol: FragmentStarted: HomeFragment{92a0f2e (b0be36a1-4bb6-409b-9440-d1593d0abcfc) id=0x7f09012e}
2019-09-13 11:06:59.270 7100-7100/org.mozilla.fenix.debug E/lol: FragmentResumed: HomeFragment{92a0f2e (b0be36a1-4bb6-409b-9440-d1593d0abcfc) id=0x7f09012e}

I discovered the location by using breakpoints. The results make me think perhaps MainActivity or NavHostFragment is adding an animation that gets to run when they yield the main thread after onResume.

[mcomella]

I don't have time to continue debugging this.

[mcomella]

Using light device + light Fenix & STR https://github.com/mozilla-mobile/fenix/issues/599#issuecomment-531313267, I don't see this in the current Nightly: if the other device configurations work out (esp. dark + dark), I think it's safe to close this.

Note a user filed an issue about a black screen being perceptively weird in https://github.com/mozilla-mobile/fenix/issues/6572.

[mcomella]

I don't see this anymore so I'm going to close.