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.
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.
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)
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.
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.
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: + → ?
I'll use the latest upgrade and see if it persists. Unless someone wants to look at my iPhone pre-update.
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.