Tabs screen appears smoothly (with animation?)
There's a flash of black (or white, depending on Light/Dark mode) and the tabs screen suddenly appears
This also happens when creating a new tab from an open tab (i.e. load page, click 3-dot, select "New tab")
GV doesn't think this is a Gecko problem, but rather a problem in Fenix not destroying the SurfaceView in time. So the next steps here are to verify that we're handling the SurfaceView correctly.
I'm not convinced the black flash when navigating away is graphics' fault. We set everything inactive in GeckoView.Display.onSurfaceDestroyed(), which I presume happens when the SurfaceView is destroyed by navigating away from the browser fragment. No rendering can occur after this point. I'm not sure what we could do, when we don't have a surface to render in to. Isn't the problem that there is a delay between the SurfaceView being destroyed and the TabsFragment being created and shown? So the android UI displays black during this time.
Edit by @sblatz
I noticed this on a Moto G today. Screencast attached.
Still reproducing on 5/23 build. Pixel and Galaxy Note 8.
The only way for us to handle this is to "screenshot" the GV and animate with that.
We should consider handling the bugs surrounding this all at one time since there's a few mentioning it.
Demo of the behavior:

I will link to the other related issues since it will be the same underlying fix 😄
Basically the same issue as https://github.com/mozilla-mobile/fenix/issues/4708 but lets make sure that animation looks good too (navigate from browser -> home).
Verified as fixed with a Pixel 3(Android 9), Htc Desire 820 (Android 6.0.1), Huawei P20 lite (Android 9), on the latest Nightly 10/10.
We have to remove the fix that replaced the view with the engineView thumbnail for now because of https://github.com/mozilla-mobile/fenix/issues/5951#issuecomment-541672261 ->
WR doesn't implement the thumbnail callback so this would hang and never navigate from the buttons.
I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=1588581 for the GV team to look into since this is reproducible on RB, Fenix, and samples-browser
The GV bug has been added to GV's November sprint.
https://bugzilla.mozilla.org/show_bug.cgi?id=1588581#a1431651_430528
Moved to the Graphics team
There have been improvements on the Graphics side, but now this is bounced back to Fenix/AC.
Isn't the problem that there is a delay between the SurfaceView being destroyed and the TabsFragment being created and shown? So the android UI displays black during this time.
Also can't be reproed by Jamie. I'm going to add a qa-needed label here.
QA, could you check to see if this is still happening in Fenix, the behavior that is in the Acceptance Criteria in comment 0? And check for black OR white flashes (even though the comment only says black)>
I left an intermediate fix in that hides the GV and instead just shows the "background" which made the transition a bit less jarring. In light mode, it will be white, dark mode will be black
Hi, as per @liuche 's comment I've just checked this matter on the latest Nightly Build #20070606 from 01/07 using the following devices:
• Google Pixel 3a (Android 9)
• Huawei Mate 20 Lite (Android 8.1.0)
• Samsung Galaxy S7 (Android 7)
The problem is still there, on the other hand, @ekager 's intermediate fix seems to be working. ☺️
Dark theme videos (Dropdown)
► Moving from browser -> Fenix Home

► Moving from browser -> Library

► Moving from browser -> Settings

Light theme videos (Dropdown)
► Moving from browser -> Fenix Home

► Moving from browser -> Library

► Moving from browser -> Settings

I'll remove the QA needed label until further notice.
GV doesn't think this is a Gecko problem, but rather a problem in Fenix not destroying the SurfaceView in time. So the next steps here are to verify that we're handling the SurfaceView correctly.
I'm not convinced the black flash when navigating away is graphics' fault. We set everything inactive in GeckoView.Display.onSurfaceDestroyed(), which I presume happens when the SurfaceView is destroyed by navigating away from the browser fragment. No rendering can occur after this point. I'm not sure what we could do, when we don't have a surface to render in to. Isn't the problem that there is a delay between the SurfaceView being destroyed and the TabsFragment being created and shown? So the android UI displays black during this time.
@vesta0 should we move this into the polish sprint? I think this popped back into the sprint because it was reopened but wasn't explicitly added and has just been a holdover, but I don't think it's as important as some of the other work that's going on. Can we swap this out for #255 ?
For what it's worth, this sounds like a known issue with SurfaceViews. It seems like using a TextureView may fix this, but that's something the GV team would have to decide if it's worth changing as I'm assuming that would require a lot of work. Though, it sounds like in https://bugzilla.mozilla.org/show_bug.cgi?id=1594860 GV may be moving away from a SurfaceView which would also probably fix this.
but better still would be if the SurfaceView wasn't destroyed until the next fragment is ready?
Jamie's comment from the Bugzilla sounds like an interesting option. I'm going to timebox investigating whether or not we can hold onto the fragment until the transition happens. Again, this doesn't seem ideal and is a temporary solution as it's a bit hacky to hold that around.
Some notes:
onDestroy as an exception gets thrown: did not call through to super.onDestroy()My only other thought here is to take a screenshot (not with the gecko function). I'm going to try that now.
I've spent a bit more time on this. It looks like GV does not allow a bitmap to be drawn from its view (which is probably why they have their own captureThumbnail)
I really don't think we have any other choice here than the interim solution that @ekager provided.
I would bounce this back to GV. I think either a switch from SurfaceView -> another view OR implementing captureThumbnail for users without WebRender will fix this, but we really need one of those as our hands are tied with the Navigation library.
Sounds like the captureThumbnail API has been updated so I can fix this!
Looks like there is still a GV bug. If a user presses "home" while the tab is still loading (engineView is completely white) captureThumbnail will never get launched. This only happens if the user has webRender enabled. So this is still waiting on https://bugzilla.mozilla.org/show_bug.cgi?id=1588581

Hi, verified as fixed on the latest Nightly Build #20560606 from 02/25 using the following devices:
• Google Pixel 3a XL (Android 10)
• Google Pixel 3a (Android 9)
• Huawei Mate 20 Lite (Android 8.1.0)
• Samsung Galaxy S7 (Android 7)
• OnePlus A3 (Android 6.0.1)
• LG Nexus 4 (Android 5.1.1)
Dark theme time lapsed videos (Dropdown)
► Moving from browser -> Fenix Home

► Moving from browser -> Library

► Moving from browser -> Settings

Light theme time lapsed videos (Dropdown)
► Moving from browser -> Fenix Home

► Moving from browser -> Library

► Moving from browser -> Settings
