Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jonalmeida opened this issue Feb 19, 2019 · 12 comments
Closed
Labels
🐞 bug Something isn't working

Comments

@jonalmeida
Copy link
Collaborator

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

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

@jonalmeida jonalmeida added the 🐞 bug Something isn't working label Feb 19, 2019
@pocmo
Copy link
Contributor

pocmo commented Feb 19, 2019

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Contributor

pocmo commented Jul 4, 2019

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
Copy link
Collaborator Author

jonalmeida commented Jul 10, 2019

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:

Screenshot_20190711-182534

@pocmo
Copy link
Contributor

pocmo commented Jul 11, 2019

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
Copy link
Collaborator Author

jonalmeida commented Jul 11, 2019

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):
Screenshot_20190710-111902

@pocmo
Copy link
Contributor

pocmo commented Jul 12, 2019

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
Copy link
Collaborator Author

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
Copy link
Contributor

Amejia481 commented Jul 12, 2019

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

@jonalmeida
Copy link
Collaborator Author

jonalmeida commented Jul 12, 2019

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

@Rakib11i
Copy link

Nice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants