Closed
Bug 1300647
Opened 8 years ago
Closed 8 years ago
Fennec frequently reloads the last saved tab when closing an opened link
Categories
(Firefox for Android Graveyard :: General, defect, P3)
Tracking
(fennec+, firefox51 verified)
VERIFIED
FIXED
Firefox 51
People
(Reporter: cwiiis, Assigned: JanH)
References
Details
Attachments
(2 files)
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.
Updated•8 years ago
|
tracking-fennec: --- → ?
Priority: -- → P3
Hardware: ARM → All
Jan is this something you may have fixed recently?
tracking-fennec: ? → +
Flags: needinfo?(jh+bugzilla)
Assignee | ||
Comment 2•8 years ago
|
||
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)
Reporter | ||
Comment 3•8 years ago
|
||
(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.
Assignee | ||
Comment 4•8 years ago
|
||
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.
Assignee | ||
Comment 5•8 years ago
|
||
Chris's idea is indeed simpler than mine and seems to work quite nicely.
Assignee: nobody → jh+bugzilla
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 8•8 years ago
|
||
mozreview-review |
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 9•8 years ago
|
||
mozreview-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+
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Comment 12•8 years ago
|
||
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
Comment 13•8 years ago
|
||
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
Comment 14•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/45c948de0bea
https://hg.mozilla.org/mozilla-central/rev/8994c8040fc9
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox51:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
Comment 15•8 years ago
|
||
Verified as fixed using Sony Xperia Z5(6.0.1) on Nightly 51(2016-09-15)
Status: RESOLVED → VERIFIED
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•