Looks like quite a noticeable regression on Galaxy Nexus and LG devices. http://eideticker.wrla.ch/#/samsung-gn/startup-abouthome-dirty/timetostableframe http://eideticker.wrla.ch/#/samsung-gn/startup-abouthome-fresh/timetostableframe http://eideticker.wrla.ch/#/lg-g2x/startup-abouthome-dirty/timetostableframe http://eideticker.wrla.ch/#/lg-g2x/startup-abouthome-fresh/timetostableframe A few things when comparing fast and slow test runs: 1. The profiling builds show that the LoginManagerStorage_mozStorage.dbInit is creating DB tables in the dirty profile, which seems weird. 2. The frame differences show the Fennec window being displayed at the same time, but the SUMO and AMO thumbnails are taking longer to appear. Nothing in LoginManagerStorage changed. So I am looking for potential patches that caused this: * SqliteBridge provider changes? * Home Page changes? * Banner changes? William - I'm wondering why the dirty profile tests are creating new DBs. Is the profile being cleared by accident?
On my Galaxy S4 (4.4.2), new profile first startup I am staring at a white screen for ~1.5 to ~2 seconds before UI is drawn in the top-sites default panel
tracking-fennec: --- → ?
> 1. The profiling builds show that the LoginManagerStorage_mozStorage.dbInit > is creating DB tables in the dirty profile, which seems weird. This is now a code path that is only tested on Fennec -- desktop no longer uses the DB backend. It uses a different LoginManagerStorage implementation altogether, which might have affected your sleuthing. We are at increasing risk from regressions here until we tackle Bug 946857.
OS: Mac OS X → Android
Hardware: x86 → All
Just an update here, we are tracking the investigation in this etherpad: https://mobile.etherpad.mozilla.org/35? Right now it's looking like the apps changes from this inbound landing are responsible: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=6638c6ade38c It also looks like there are some other smaller regressions around this time, so we need to continue to investigate those.
Severity: normal → major
status-firefox29: --- → affected
status-firefox30: --- → affected
Assignee: nobody → margaret.leibovic
tracking-fennec: ? → 29+
Through a serious of various attempts at things (most notably disabling snippets again), it looks like we're back to normal, so I'm closing out this bug. However, snippets are still enabled on aurora, so we need to figure out how to re-enable them on Nightly without causing regressions. We just re-landed bug 964510 without causing any regressions, so my next step is going to be re-landing bug 964511 and bug 962349. If these don't cause any problems, we should uplift bug 964510 and bug 964511 to aurora.
(In reply to :Margaret Leibovic from comment #4) > Through a serious of various attempts at things (most notably disabling > snippets again), it looks like we're back to normal, so I'm closing out this > bug. Does that mean we've ruled out synthetic APKs as a cause of the regression? Also, note that lg-g2x/startup-abouthome-dirty still looks elevated, although the other three device/test combinations appear back-to-normal: http://eideticker.wrla.ch/#/lg-g2x/startup-abouthome-dirty/timetostableframe
(In reply to Myk Melez [:myk] [@mykmelez] from comment #5) > Does that mean we've ruled out synthetic APKs as a cause of the regression? Not completely, but we will profile and look for specific issues. No need to back it out. > Also, note that lg-g2x/startup-abouthome-dirty still looks elevated, > although the other three device/test combinations appear back-to-normal: > > http://eideticker.wrla.ch/#/lg-g2x/startup-abouthome-dirty/timetostableframe Yep. We need to keep looking into why the LG is still slower. Again, we are looking for specifics.
Closing this out, since the regression has gone away.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.