Fennec frequently reloads the last saved tab when closing an opened link

VERIFIED FIXED in Firefox 51

Status

()

defect
P3
normal
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: cwiiis, Assigned: JanH)

Tracking

unspecified
Firefox 51
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec+, firefox51 verified)

Details

Attachments

(2 attachments)

Something that's annoyed me for *ages* now; more often than not, Firefox gets unloaded in the background (expected, I don't mind too much that Android decides I don't need my browser after long periods of activity). When I then open a link from another app (Facebook, Twitter, Reddit, etc.), it opens in Firefox, as expected. When I hit back, however, the tab closes, and it then starts reloading the last opened tab before returning to the last application. If I switch to Firefox afterwards, I can see that tab is now loaded. I'm guessing this depends on site cache settings, but it's looking like it's re-downloading the last open tab all the time.

This is annoying regardless of data usage (as if it was a particularly complex page, it noticeably slows things down), but worrying from that perspective too. I don't like to think about the amount of wasted CPU/data caused by this.

So, STR:

1- Load Firefox
2- Open any page
3- Press home button
4- Open app launcher and swipe Firefox closed (or close it some other way)
5- Open a link from any other app
6- Wait for Firefox to load
7- Press back

Expected:

Firefox closes that tab and you are immediately returned to the last application. If I launch or switch to Firefox, I would expect the tab from step 2 to then start loading (ideally, it would instantly load from cache).

Actual:

Firefox closes that tab, starts reloading the last opened tab (opened in step 2) and returns you to the last application. If I switch to or launch Firefox, the tab opened in step 2 is already completely loaded.
tracking-fennec: --- → ?
Priority: -- → P3
Hardware: ARM → All
Jan is this something you may have fixed recently?
tracking-fennec: ? → +
Flags: needinfo?(jh+bugzilla)
Nope, I haven't worked on anything related to this.

The problem seems to be that normally, when reaching the end of session history on pressing back, we either close a tab and switch to its parent (if there is one), or else just background Firefox without closing that tab. However in the case of a tab opened from an external app, we do both - close the tab and background Firefox.

I'm not sure whether this would be the best solution, but one idea to solve this would be to move closing the tab to the moment Firefox resumes from background. So basically, if we're in the situation were we want to both close a tab and then immediately go into background, we could instead
- (maybe navigate to about:blank at some point to free some memory)
- mark that tab as "closeOnResume" (and include that flag in the session store file as well)
- go into background

Then when Firefox starts back up, we either
- skip the tab during session restore if we're doing a full restore because Firefox was killed in the meantime
- or if we were still running, just check in onResume() whether the currently selected tab is marked as "closeOnResume" and close it if necessary.

If nobody has a better idea, I might have a look how this would actually turn out if implemented in practice...
Flags: needinfo?(jh+bugzilla)
(In reply to Jan Henning [:JanH] from comment #2)
> I'm not sure whether this would be the best solution, but one idea to solve
> this would be to move closing the tab to the moment Firefox resumes from
> background. So basically, if we're in the situation were we want to both
> close a tab and then immediately go into background, we could instead
> - (maybe navigate to about:blank at some point to free some memory)
> - mark that tab as "closeOnResume" (and include that flag in the session
> store file as well)
> - go into background
> 
> Then when Firefox starts back up, we either
> - skip the tab during session restore if we're doing a full restore because
> Firefox was killed in the meantime
> - or if we were still running, just check in onResume() whether the
> currently selected tab is marked as "closeOnResume" and close it if
> necessary.

Alternatively, perhaps you could have a flag that's set when closing that stops tabs from loading? Your plan sounds fine, but it also sounds like making the UI respond as the user would expect would be kind of fiddly/delicate. I wouldn't want to see a tab closing as I open the browser for sure, that would definitely feel like something's broken.
Good idea. So if the background tab has been zombified, we'd need to somehow notify the session store not to reload the tab that's going to get selected until the next "application-foreground" event.
Chris's idea is indeed simpler than mine and seems to work quite nicely.
Assignee: nobody → jh+bugzilla
Comment on attachment 8790102 [details]
Bug 1300647 - Part 1 - Don't bother reloading a zombified tab if we're about to exit the app.

https://reviewboard.mozilla.org/r/78020/#review76962
Attachment #8790102 - Flags: review?(ahunt) → review+
Comment on attachment 8790103 [details]
Bug 1300647 - Part 2 - Test that the session store correctly handles the "Tab:KeepZombified" notification.

https://reviewboard.mozilla.org/r/78022/#review76964

Looks good to me! Thanks for the tests too!
Attachment #8790103 - Flags: review?(ahunt) → review+
Turns out I've forgotten to rename the internal function name of the new _restoreZombieTab() session store function - it was originally going to get called _reviveZombieTab() :-)

Anyway here we go,

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c54e9844908a
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/45c948de0bea
Part 1 - Don't bother reloading a zombified tab if we're about to exit the app. r=ahunt
https://hg.mozilla.org/integration/autoland/rev/8994c8040fc9
Part 2 - Test that the session store correctly handles the "Tab:KeepZombified" notification. r=ahunt
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/45c948de0bea
https://hg.mozilla.org/mozilla-central/rev/8994c8040fc9
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
Verified as fixed using Sony Xperia Z5(6.0.1) on Nightly 51(2016-09-15)
Status: RESOLVED → VERIFIED
Depends on: 1320987
Depends on: 1338893
You need to log in before you can comment on or make changes to this bug.