|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
58 bytes, text/x-review-board-request
|Details | Review|
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.
[Tracking Requested - why for this release]: This seems like a regression, startup should not be as slow.
I can repro this, but I think we need to get a frontend person to investigate.
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.
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.
Created attachment 8770593 [details] 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 on attachment 8770593 [details] Bug 1283627 - Update home pager immediately after restoring tabs. https://reviewboard.mozilla.org/r/64030/#review61354
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/46fe278f9f76 Update home pager immediately after restoring tabs. r=JanH
Verified as fixed in 50.1.0. Device: -LG G4 (Android 6.0)