Tabs not restored on browser re-launch (not-running state)

VERIFIED FIXED

Status

()

Firefox for iOS
General
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: aaronmt, Assigned: st3fan)

Tracking

({reproducible})

unspecified
ARM
iOS
reproducible
Dependency tree / graph

Firefox Tracking Flags

(fxios+)

Details

(Whiteboard: [parity=safari][parity=chrome] noteworthy)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Currently Safari and Chrome will automatically restore tabs when an application is manually suspended (i.e, swipe the application off the running list).

Currently we do not restore any tabs.
This WFM -- any other details?
Flags: needinfo?(aaron.train)
(Reporter)

Comment 2

3 years ago
Confirm you're testing on device? I open a tab, e.g, http://blogto.com, double-tap home button, swipe the browser off, re-launch the browser, the only tab open is about:home
Flags: needinfo?(aaron.train)
Yeah, device (and simulator) restore works fine for me.
(Reporter)

Comment 4

3 years ago
Tried it on my iPad Air (8.3) which made no difference. My tabs are never restored on browser re-launch, just a single about:home tab. I'm using the Client scheme on latest code.
Assignee: nobody → jhugman
tracking-fennec: ? → +
From TestFlight Firefox for iOS 1.0 (13) What to test: "The app now remembers the tabs you had open" - it doesn't (on IPhone 5S)
(Reporter)

Comment 6

3 years ago
Tested on an iPhone 4s as well and non of my tabs are restored at all ever.
Can reliably reproduce this on the simulator.
(Reporter)

Comment 8

3 years ago
Still doesn't work, latest code
Previous patch is responding to UIStateRestoring lifecycle events.

However, UIStateRestoration (how this is implemented) doesn't support Force Quitting. 

Worse: when the app is Force Quit, the state restoration archive gets deleted.
I swear this was working for me at one point, even when force quitting. I wonder what changed?
(Reporter)

Updated

3 years ago
Status: NEW → ASSIGNED
Keywords: reproducible
(Reporter)

Comment 11

3 years ago
Is there any update here?
(Assignee)

Comment 12

3 years ago
I set a breakpoint on our tab preservation/restoration code and I can confirm that the state code is called when you double-tap the home button and then close the application.

In other words: swiping the app away from that screen does not 'force kill' the app. It simply asks the app to stop and as part of that the state preservation handlers are invoked.

(AFAIK there is no Force Kill on iOS)

To me that means that this bug can be closed as WONTFIX. No code changed are required.
Flags: needinfo?(jhugman)
Flags: needinfo?(aaron.train)
(Assignee)

Updated

3 years ago
tracking-fennec: + → ---
(Reporter)

Comment 13

3 years ago
I do not agree at all as WONTFIX. Both Safari and Chrome restore tabs.
Flags: needinfo?(aaron.train)
Maybe Stefan meant WORKSFORME? It's definitely a bug that needs to be addressed, but sounds like it might be working as expected now according to comment 12.
(Assignee)

Comment 15

3 years ago
My findings are premature. I don't know why encodeRestorableStateWithCoder is being called when the app is killed manually. I don't think it should be because the UIKit Guide says this:

"The system automatically DELETES AN APP'S PRESERVED STATE when the user FORCE QUITS the app. Deleting the preserved state information when the app is killed is a safety precaution. (As a safety precaution, the system also deletes preserved state if the app crashes twice during launch.) If you want to test your app’s ability to restore its state, you should not use the multitasking bar to kill the app during debugging. Instead, use Xcode to kill the app or kill the app programmatically by installing a temporary command or gesture to call exit on demand."

So, we can either close this as 'works as intended' or we can keep this open to do whatever Safari did to work around the system default.

I like the system default btw. Because it is an escape hatch. And we don't have anything better at this point.

So my suggestion is to leave this as it is now until we have implemented bug 1166372 -  We need to recognize when we crashed and then allow the user to not reopen tabs.
tracking-fennec: --- → +
tracking-fxios: --- → +
Assignee: jhugman → nobody
Status: ASSIGNED → NEW
tracking-fxios: + → ---
Flags: needinfo?(jhugman)
Summary: Tabs not restored on browser re-launch (not-running state) → Implement UI for about:session-restore
(Reporter)

Comment 16

3 years ago
That's not what this bug is about. I don't think we can ship if my tabs are never restored. Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1127061 is a meta bug that is tracking version 1.0
tracking-fennec: + → ?
Summary: Implement UI for about:session-restore → Tabs not restored on browser re-launch (not-running state)

Updated

2 years ago
tracking-fxios: --- → ?
Assignee: nobody → sarentz
Status: NEW → ASSIGNED
tracking-fennec: ? → ---
tracking-fxios: ? → +
(Assignee)

Updated

2 years ago
Assignee: sarentz → nobody
Status: ASSIGNED → NEW
(Assignee)

Updated

2 years ago
Assignee: nobody → sarentz
(Assignee)

Updated

2 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 17

2 years ago
Created attachment 8627295 [details] [review]
PR: https://github.com/mozilla/firefox-ios/pull/651

This patch reverts the `UIStateRestoring` code. Instead we now do the same storing/restoring of tabs but on our own terms.

This means that we are on parity with Chrome and Safari so that tabs are also restored when we crash or when the user kills the app from the app switcher.

Special request for QA to test this carefully.
Attachment #8627295 - Flags: review?(wjohnston)
Attachment #8627295 - Flags: review?(sleroux)
Attachment #8627295 - Flags: feedback?(aaron.train)
Comment on attachment 8627295 [details] [review]
PR: https://github.com/mozilla/firefox-ios/pull/651

Patch looks good! I wonder if we need to know when the application crashed previously if it would be worth the effort to add Breakpad/PLCrashReporter.framework so we get in-process crash reporting. This would also help with the issue we're seeing with test flight reports not coming in.
Attachment #8627295 - Flags: review?(sleroux) → review+
Blocks: 1166372
(Assignee)

Updated

2 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
(Reporter)

Comment 19

2 years ago
\o/
Status: RESOLVED → VERIFIED
(Reporter)

Updated

2 years ago
Attachment #8627295 - Flags: feedback?(aaron.train) → feedback+
(Assignee)

Updated

2 years ago
Whiteboard: [parity=safari][parity=chrome] → [parity=safari][parity=chrome] noteworthy
(Reporter)

Updated

2 years ago
Depends on: 1179877
Attachment #8627295 - Flags: review?(wjohnston)
You need to log in before you can comment on or make changes to this bug.