Closed
Bug 1283627
Opened 8 years ago
Closed 8 years ago
Slow startup + top sites loading
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(fennec50+, firefox50 verified)
RESOLVED
FIXED
Firefox 50
People
(Reporter: liuche, Assigned: sebastian)
Details
Attachments
(1 file)
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.
Reporter | ||
Comment 1•8 years ago
|
||
[Tracking Requested - why for this release]: This seems like a regression, startup should not be as slow.
tracking-fennec: --- → ?
I can repro this, but I think we need to get a frontend person to investigate.
Assignee: nobody → s.kaspari
tracking-fennec: ? → 50+
Assignee | ||
Comment 3•8 years ago
|
||
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.
Assignee | ||
Comment 4•8 years ago
|
||
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.
Assignee | ||
Comment 5•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/64030/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/64030/
Attachment #8770593 -
Flags: review?(jh+bugzilla)
Comment 6•8 years ago
|
||
Comment on attachment 8770593 [details] Bug 1283627 - Update home pager immediately after restoring tabs. https://reviewboard.mozilla.org/r/64030/#review61354
Attachment #8770593 -
Flags: review?(jh+bugzilla) → review+
Pushed by s.kaspari@gmail.com: https://hg.mozilla.org/integration/autoland/rev/46fe278f9f76 Update home pager immediately after restoring tabs. r=JanH
Comment 8•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/46fe278f9f76
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 50
Comment 9•8 years ago
|
||
Verified as fixed in 50.1.0. Device: -LG G4 (Android 6.0)
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•