Fenix: FNX-14070 ⁃ Back-Forward Cache in Fenix Android

[PulkitGupta707]

Hi, I want to know if BF cache is enabled in fenix builds on android?
It will be available in Chrome V86
https://www.xda-developers.com/back-forward-google-chrome-faster-bfcache/

[buttercookie42]

Interestingly enough, it indeed doesn't work (tested with Nightly 200727 06:00 build #22090607). Fennec works fine, as does a current geckoview_example app.

Tested with https://www.buttercookie.de/temp/button.html – open it, click the button, navigate to a different page and then go back. If the page with the button was loaded from the bfcache, the button should still read ‘42’, if it wasn't, the button will have reverted to showing ‘Click me!’.

[kbrosnan]

Broken on Reference Browser and Focus. Likely something for A-C to handle.

[PulkitGupta707]

Broken on Reference Browser and Focus. Likely something for A-C to handle.

By reference browser you meant firefox Nightly for android?

[kbrosnan]

No. https://play.google.com/apps/testing/org.mozilla.reference.browser

[PulkitGupta707]

Interestingly enough, it indeed doesn't work (tested with Nightly 200727 06:00 build #22090607). Fennec works fine, as does a current geckoview_example app.

Tested with https://www.buttercookie.de/temp/button.html – open it, click the button, navigate to a different page and then go back. If the page with the button was loaded from the bfcache, the button should still read ‘42’, if it wasn't, the button will have reverted to showing ‘Click me!’.

I tried this method i can say BF cache isn't working (if this method is true) in latest android beta build.

[Dunexus]

Github repo : https://github.com/mozilla-mobile/reference-browser

[buttercookie42]

Likely something for A-C to handle.

Just guessing, but I wonder whether this might be as simple as some A-C component injecting an unload / beforeunload handler everywhere, thereby breaking the bfcache?

[buttercookie42]

https://github.com/mozilla-mobile/android-components/search?l=JavaScript&q=unload

[pocmo]

From chat:

mstange: Sebastian Kaspari: buttercookie42's comment sounds like it might be right on the money
mstange: you could remove those unload listeners experimentally, just to confirm

[mcomella]

Perf triage: we added to the top 10 inter-team bug list. In particular, we want to know:

• Is this expected to be in fenix or on mobile?
• What would the benefit be of having this on mobile?
• If it's not too much work, can we add it? If it's a lot of work, let's re-triage with the extra information

[PulkitGupta707]

Perf triage: we added to the top 10 inter-team bug list. In particular, we want to know:

* Is this expected to be in fenix or on mobile?

* What would the benefit be of having this on mobile?

* If it's not too much work, can we add it? If it's a lot of work, let's re-triage with the extra information

1. Firefox Android

2. A back/forward cache (bfcache) caches whole pages, including the JavaScript heap, when navigating away from a page. This is done so that the full state of the page can be restored when the user navigates back.It will work when navigating back as well as when navigating forward to a previously accessed page.
   For more information you can see this https://www.xda-developers.com/back-forward-google-chrome-faster-bfcache/

3. Deciding which/how many pages should remain in memory will be tricky i guess. It took almost an year for chrome to implement it

[PulkitGupta707]

@mcomella Please go through this article thoroughly: https://techdows.com/2020/07/chrome-android-back-forward-cache.html

It says that the bfcache was meant/intended for Android (on Chrome) first and also plans to bring it to desktop and I think it also mentions that Chromium team plans to work with Safari and Firefox to bring and standardize this feature or something like that. There also seems to be some attached reference docs as well.

Just go through the article thoroughly.

From https://www.xda-developers.com/back-forward-google-chrome-faster-bfcache/

Mozilla Firefox and Apple Safari have subtly different implementations of this caching technology, Google notes. Chrome, however, is opting not to use WebKit’s implementation of bfcache due to incompatibility with Chrome’s multi-process architecture.

[mstange]

To track down the reason, I captured "PageCache" MOZ_LOGs in this profile: https://share.firefox.dev/2XxYmtW
It says "blocked on suspended Window" and "blocked due to unload handlers".
I don't know what "suspended Window" means (here's the code), but at least it's clear that the unload handlers are hurting.

---

Here's how I captured that logging in a profile: First, I made a text file called org.mozilla.fenix-geckoview-config.yaml with the following content:

env:
  MOZ_LOG: profilermarkers,PageCache:5

Then I pushed it to my phone with adb push org.mozilla.fenix-geckoview-config.yaml /data/local/tmp/.
I also ran adb shell am set-debug-app --persistent org.mozilla.fenix so that the file is respected.
Then I killed the Fenix app, started it again, went to a website and started profiling with the Gecko profiler via about:debugging. Then I navigated between a few sites.

[mstange]

The "suspended Window" might be because the navigation is initiated while the URL bar is focused, which hides (and "suspends"?) the tab. When I navigate away from a page by navigating back with the Android back button, the "suspended Window" message is not printed. It's possible that Gecko is making a bad decision here, and that a bug should be filed to allow a page to be put into the BFCache even if it is suspended.

[snorp]

The "suspended Window" might be because the navigation is initiated while the URL bar is focused, which hides (and "suspends"?) the tab. When I navigate away from a page by navigating back with the Android back button, the "suspended Window" message is not printed. It's possible that Gecko is making a bad decision here, and that a bug should be filed to allow a page to be put into the BFCache even if it is suspended.

Yeah, we freeze (suspend) windows when they are set inactive via GeckoSession.setActive(false). The GeckoView class calls this automatically when it is not on the screen, which lines up with what you observed above. I think I agree that we should allow suspended documents to enter the bfcache. The reason we don't is probably because suspension was previously only used while a document was in the cache, so this was probably just some sort of sanity check.

[csadilek]

We've confirmed that removing unload handlers fixes this problem. They are currently used to disconnect native ports we open from content scripts to the app in out built-in extensions. Let's look for an alternative here.

[csadilek]

OK, turns out we can just remove those unload handlers as the ports will be disconnected automatically. We will remove them in: https://github.com/mozilla-mobile/android-components/issues/8046

[csadilek]

GV bug for the suspended window issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1657698

[mcomella]

@csadilek What's the next action item here? Is GV expected to address this issue? This issue and the upstream BZ issue are still open but the issue was moved to "Done" in a-c planning so I'm a little confused. :)

[csadilek]

@mcomella the A-C work (removing unload handlers) is done and available in current Fenix Nightly. This fixes the problem partially i.e. when using a link to navigate away, then hitting back, the cache works now.

But to fix this completely we also need https://bugzilla.mozilla.org/show_bug.cgi?id=1657698.