1283627 - Slow startup + top sites loading

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Chenxia Liu [:liuche]]

I've noticed recently that startup can be very slow, and it can take a few seconds to load Top Sites. I can't think of anything recent that might have caused this - I'll add an STR when I find something more concrete.

Filing this because it seems important even if we don't have specific steps, and I'd appreciate if anyone else can repro/has seen this.

Comment 1

[Chenxia Liu [:liuche]]

[Tracking Requested - why for this release]: This seems like a regression, startup should not be as slow.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

I can repro this, but I think we need to get a frontend person to investigate.

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

Wow, that's a rabbit hole.

I finally found out that it's also related to "always restore" (bug 1219343). With that we receive the LOCATION_CHANGE event pretty late (~3 seconds) and that's the first time we call updateHomePagerForTab() which will set the pager visible for the first time.

> W/SKDBG   (  717): v BrowserApp.onCreate() 1468337147427 <main>
> W/SKDBG   (  717): v BrowserApp.onResume() 1468337147691 <main>
> W/SKDBG   (  717): ?         * onTabChanged(TITLE) 1468337147837 <main>
> W/SKDBG   (  717): ?         * onTabChanged(RESTORED) 1468337148022 <main>
> W/SKDBG   (  717): ?         * onTabChanged(START) 1468337150500 <main>
> W/SKDBG   (  717): ?         * onTabChanged(LOCATION_CHANGE) 1468337150578 <main>
> W/SKDBG   (  717): ^      BrowserApp.updateHomePagerForTab() 1468337150578 <main>

Without restoring the session we almost instantly receive the SELECTED_TAB event which will trigger the same code LOCATION_CHANGE does.

> W/SKDBG   ( 1968): v BrowserApp.onCreate() 1468337251555 <main>
> W/SKDBG   ( 1968): v BrowserApp.onResume() 1468337251810 <main>
> W/SKDBG   ( 1968): ?         * onTabChanged(SELECTED) 1468337252077 <main>
> W/SKDBG   ( 1968): ^      BrowserApp.updateHomePagerForTab() 1468337252077 <main>

Something must have changed with the events. This delay is not in Beta which also has set tabs to always restore.

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

I think my patch in bug 1261008, which modifies the restore code, has fixed this issue for most cases (We now get the SELECT event pretty early and display the pager).

You can only reproduce it with the following STR now:
* Go to a random website
* Explicitly enter about:home in the URL bar
* Now kill the browser
* Restart the browser
* We restore the (selected) about:home tab (because it has a history attached, see bug 1261008 for details)
* We receive the event pretty late and until this happens you only see a white page.

Comment 5

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: Bug 1283627 - Update home pager immediately after restoring tabs.

Review commit: https://reviewboard.mozilla.org/r/64030/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/64030/

Comment 6

[Jan Henning [:JanH]]

Comment on attachment 8770593 [details]
Bug 1283627 - Update home pager immediately after restoring tabs.

https://reviewboard.mozilla.org/r/64030/#review61354

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/46fe278f9f76
Update home pager immediately after restoring tabs. r=JanH

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/46fe278f9f76

Comment 9

[Bogdan Surd, QA [:bsurd, NI]]

Verified as fixed in 50.1.0.
Device:
 -LG G4 (Android 6.0)