Tab switching sometimes loads about:home instead of the target tab (build 25)

RESOLVED WORKSFORME

Status

()

Firefox for iOS
Home screen
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: Christopher Arnold, Unassigned)

Tracking

unspecified
Other
iOS

Firefox Tracking Flags

(fxios1.1+)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Created attachment 8637299 [details]
FullyLoadedTabURLs.PNG

I noticed open tabs will sometimes lose the URLs associated with them when I try to reload.

Steps to reproduce:
-Build up a series of 6 open tabs that have a specific URL associated with them.
-Click into the tabs view to see all 6 different sites loaded as thumbnails.
-Click one of the tabs in your history.  
-User would expect the URL of the screenshot of the previously loaded URL to reload.
-Instead the new tab loads with a bunch of tiles, but often not the specific URL you wanted shown as one of the tiles.
(Reporter)

Comment 1

3 years ago
Created attachment 8637300 [details]
Step2-OldURLsLostAsTabLoadAttempted.PNG

-Click one of the tabs in your history.  
-User would expect the URL of the screenshot of the previously loaded URL to reload.
-Instead the new tab loads with a bunch of tiles, but often not the specific URL you wanted shown as one of the tiles.

Picture here depicts how new:tab overwrites the URL previously in the history for the tile clicked.

Updated

3 years ago
tracking-fxios: --- → ?
OK, this bug got confusing because of terminology. Here's how I'd rephrase:

* Open multiple tabs.
* Switch tabs to one (presumably one that's been zombified).
* Observe that the home screen loads instead of the zombified tab, and is thumbnailed into the tab drawer.
tracking-fxios: ? → +
Summary: History URLs in loaded tabs is sometimes lost in build 25 → Tab switching sometimes loads about:home instead of the target tab (build 25)
(Reporter)

Comment 3

3 years ago
Thanks Richard.  That's a great write-up.

This is intermittent.  It seems to happen only to tabs that have been put in the background for 12 or more hours.  I haven't seen it happen to tabs spawned inside one session.
Possibly related to session restore issues; will investigate.
Flags: needinfo?(bnicholson)
Assignee: nobody → bnicholson
Status: NEW → ASSIGNED
I can't reproduce. Aaron, can you try?
Assignee: bnicholson → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(bnicholson) → needinfo?(aaron.train)
Neither here. I tried simulating with a memory warning but on tap of the tab in the drawer I got the expected tab and not about:home (if I understand this bug correctly). This probably still happens but needs testing around the zombified state.
Flags: needinfo?(aaron.train)
Renom'ing. Hopefully someone has working STR; can't block v1 otherwise.

It's also worth noting that, for whatever reason, web view zombification (which is done by the OS) only happens when not attached to the debugger (i.e., running from Xcode).
tracking-fxios: + → ?
(Reporter)

Comment 8

3 years ago
I'll use the latest upgrade and see if it persists.  Unless someone wants to look at my iPhone pre-update.
tracking-fxios: ? → 1.1+
(Reporter)

Comment 9

3 years ago
Build 32 I no longer see this bug anymore.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.