1163120 - Restore tabs lazy

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Suggestion to shave off 100s of ms

When we restore your tabs, we ask the TabManager to create new tabs with a specific NSURL. This immediately creates a WKWebView instance. This is an extremely expensive operation. The more tabs people have open, the worse this gets. We should only fully restore the front tab. And restore the others lazily when they are opened.

Comment 1

[Wesley Johnston (:wesj)]

Attachment: PR https://github.com/mozilla/firefox-ios/pull/492

Comment 2

[Stephan Leroux [:sleroux]]

Hey Wes,

I wonder if this could also fix this issue? https://bugzilla.mozilla.org/show_bug.cgi?id=1163122

Comment 3

[Wesley Johnston (:wesj)]

Not as is, but it might help. The tricky part there is that we actually need to load a "blank" url in the tab in order to have about:home in the back-stack.

Comment 4

[Wesley Johnston (:wesj)]

Updated this to not support zombifying anymore.

Comment 5

[Brian Nicholson (:bnicholson)]

Comment on attachment 8609192 [details] [review]
PR https://github.com/mozilla/firefox-ios/pull/492

Nice, this looks good to me, though you'll have to do a bit more rebasing after #521 (sorry). That PR adds a testWebViewDisposed to make sure the webview gets disposed when the browser is removed, so it'd be good to make sure that still passes with this (especially considering you moved some deregistration into the Browser deinit).

Comment 6

[Brian Nicholson (:bnicholson)]

https://github.com/mozilla/firefox-ios/commit/b5861146d45a1f5b913b56401a35eed00104afaf

Comment 7

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I'm reopening this bug because it broke opening reading list items.

STR:

1) Add item to your reading list
2) Open item from the reading list panel

The app crashes because browser.webView is nil.

Comment 8

[Wesley Johnston (:wesj)]

Filed 1170906 for this. I'll track it there.