Returning to a Custom Tab doesn't always show the same session/styling

[jonalmeida]

I saw this happen organically by leaving a CT open for a long lived session and then returning later. Can be repro'd with the steps below.

Steps to reproduce

1. Open dev options and change 'Background process limit' to 'No background limit'
2. Open an app with a custom tab.
3. Switch away from the app and come back.
4. Observe.

Expected behavior

• To see the Custom Tab session still there or reloading.

Actual behavior

• You see the last selected session.
  • You can (sometimes) see the selected session not loading even if you press refresh. (sounds similar to other bugs we've seen)
• You do not see the CT theming/styling.

Device information

• Android device: Pixel 2 (Android 9)
• Reference Browser version: 1.0.1908 (Build Import cleaned up version of components sample browser. #1 🦎 67.0a1-20190214044118)

It looks like the engine or view is not being recreated for some reason.

[pocmo]

Weird. When I tested this to debug something else I ended up in the app and the custom tab was just closed (which is okay since we do not restore them).

You see the last selected session.

Does that mean you are in the browser and not in the custom tab anymore? 🤔

[jonalmeida]

Weird. When I tested this to debug something else I ended up in the app and the custom tab was just closed (which is okay since we do not restore them).

I saw this as well and probably failed to explain this properly in the opening issue: We're loading some information from the toolbar from the selectedSession, but if you look at logcat, you see see the CT session loading.

[jonalmeida]

I still see this reasonably often. I leave a custom tab open and do something else more memory-intensive and when I return, I see a blank screen since we don't persist the custom tab session.

[pocmo]

Our CustomTabActivity also has no protection against intents that have no id or re-creation without an intent. I wonder if that could happen here for a long lived background activity.

[jonalmeida]

I think that is the case. This was a CT session that I had left open in the background and later returned to. You can tell it was long lived Custom Tab activity because the bcakground for urlView in the toolbar is removed for a CT:

[pocmo]

The same seems to happen in Fenix and may be the source of some "Display already acquired" bugs if we end up with two browsers showing the selected session.

[jonalmeida]

The same seems to happen in Fenix and may be the source of some "Display already acquired" bugs if we end up with two browsers showing the selected session.

Yup, here's a matching screenshot of the issue there as well for comparison (although it shows the wrong URL r-b does this too):

[pocmo]

Nominating this for AC triage. This is something we should investigate. :)

@jonalmeida Have you ever tried whether "don't keep activities" or disabling "background processes" makes this easily reproducible?

[jonalmeida]

Have you ever tried whether "don't keep activities" or disabling "background processes" makes this easily reproducible?

Yeah, disabling background processes was my original STR, but now we're seeing this in the wild so it might be a more important issue now.

I'll try and look into this next week! :)

[Amejia481]

@jonalmeida This is a similar issue on Fenix mozilla-mobile/fenix#2383 (comment) it may give some hints

[jonalmeida]

Thanks! It looks like the same case there. We need to figure out a restore (or graceful degradation) solution for this now.