Fenix: FNX-14326 ⁃ [Bug] Visible delay to visual completeness after foregrounding

[hwinnemoe]

Steps to reproduce

1. Open a website in Fenix Nightly, e.g. https://www.mozilla.org/en-GB/
2. Open a website in Fennec, e.g. https://www.mozilla.org/en-GB/
3. Switch between the two browsers

Expected behavior

Both browsers should take the same minimal amount of time to visual completeness.

Actual behavior

Fenix is significantly slower on the used device.

Device information

• Android device: Sony Xperia Z2, Android 6.0.1
• Fenix version: Nightly 200730 06:21 (Build #22120630)
  AC: 53.0.20200729190533, bb7dbe3ec
  GV: 80.0a1-20200727095125
  AS: 61.0.10

[hwinnemoe]

According to BZ-1655580 Comment 4, a capture might be taken every time the app is foregrounded. The length of the delay here reminds me of the delay experienced in #8795, which was resolved by avoiding a capture of the app.

[mcomella]

@hwinnemoe We notice there's a white flash before loading the page in fenix that doesn't exist on fennec. Do you see the white flash with the following STR?

• Open fenix
• load a page
• Press the home button
• Press the recent apps button
• Select fenix
• (look for white flash on start)

---

Triage: we're unable to reproduce normally (on high-end devices; csadilek could with Don't Keep Activities). We suspect the white flash might occur in fenix when the app is removed from memory and restarted. Note: we might be able to get the timings for this from telemetry.

Action items (tracked by https://github.com/mozilla-mobile/perf-frontend-issues/issues/153; I'll report back here):

• Try to reproduce on low-end hardware
• Investigate impact of screenshot issue: https://github.com/mozilla-mobile/fenix/issues/13145#issuecomment-666731227
• Check memory footprint of fenix vs. fennec

[hwinnemoe]

@hwinnemoe We notice there's a white flash before loading the page in fenix that doesn't exist on fennec. Do you see the white flash with the following STR? [...]

Yes, I see the white flash using these STR. That is what I'm referring to with the "visible delay" in the title. Also, the page is already loaded in both browsers in the original STR.

In addition: I can already interact with Fenix while the flash is visible, you can see that the navbar is moving while the flash is still visible:

Furthermore, I testet against GeckoView Example 81.0a1, Build ID 20200727203201: there is no white flash visible in GV example, but the video element does appear in a delayed manner:

Thus I think there are two issues here:

• The white flash that is only visible in Fenix
• The video element that appears with a delay on both GV and Fenix, but not on Fennec.

[mcomella]

I can reproduce the white flash on my Galaxy S5 with a local nightly build but not on my Pixel 2 – it's not related to out-of-memory because, as mentioned above, the toolbar doesn't need to be reloaded. I also confirmed it does not happen in Chrome or Firefox for Android.

According to BZ-1655580 Comment 4, a capture might be taken every time the app is foregrounded. The length of the delay here reminds me of the delay experienced in #8795, which was resolved by avoiding a capture of the app.

Amazing debugging, @hwinnemoe – I think this it the cause. I commented out the requestScreenshot line on startup and can no longer reproduce: https://searchfox.org/mozilla-mobile/rev/7b416af0b01b5f7076359f2a76cfc7880ad49390/android-components/components/browser/thumbnails/src/main/java/mozilla/components/browser/thumbnails/BrowserThumbnails.kt#49 Caveat: there is still a small flash from white to the previously loaded page that doesn't happen on Chrome or fennec but it's much better than it was before. I think the assignee of this bug should make a judgement call whether or not to pursue that remaining white flash further or whether to file a follow-up bug.

I'm going to put this in the inter-team issues list.

[hwinnemoe]

This has been partially resolved by BZ-1647797, since now GeckoView has been enhanced with an "API to listen for when contentful paint status has been reset" and the corresponding AC commit https://github.com/mozilla-mobile/android-components/commit/432c846cb9cbed2f3f7711082c997bec2907c875. I do not see this specific visual delay anymore. It still introduces stutter when the tab is playing an animation but that may be resolved by BZ-1661106. The GV part is also unresponsive for the time of the capturing process.

[jonalmeida]

@hwinnemoe since you mentioned we no longer see the specific bug tracked here any more with the GV fixes, shall we close this issue?

The stuttering also has a bug tracking this, so we should be safe to close it.

[hwinnemoe]

Are you referring to the stuttering being tracked by BZ-1661106? That only tracks the stuttering introduced by the capture. In the profiles there is also stuttering that is introduced by the UI thread, see this comment https://bugzilla.mozilla.org/show_bug.cgi?id=1661106#c10. I would vote for tracking these UI thread introduced GV stuttering issues in new GH issues and closing this issue as resolved. Should I open individual issues for every cause of the stuttering? I can reproduce stuttering while scrolling by interacting with any element on the toolbar.

[jonalmeida]

Should I open individual issues for every cause of the stuttering? I can reproduce stuttering while scrolling by interacting with any element on the toolbar.

Yes, please. 🙂

I'll close this out then.