Closed Bug 1074933 Opened 5 years ago Closed 5 years ago

Autophone - webappstartup Throbber stop regression 2014-09-29

Categories

(Firefox for Android Graveyard :: Search Activity, defect, P1)

ARM
Android
defect

Tracking

(firefox35 fixed, fennec35+)

RESOLVED FIXED
Firefox 35
Tracking Status
firefox35 --- fixed
fennec 35+ ---

People

(Reporter: bc, Assigned: Margaret)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

3-7% regression in throbber stop for webappstartup tests though it appears not for local blank or local throbber.

http://phonedash.mozilla.org/#/org.mozilla.fennec/throbberstop/webappstartup/norejected/2014-09-29/2014-09-30/notcached/noerrorbars/standarderror

before
2014-09-29 20:41:27
nexus-s-4
(fx-team/rev/fb47e92d7752):
8694±55
N=8

after
2014-09-29 20:57:28
nexus-s-4
(fx-team/rev/135564e9e7f5):
9325±202
N=8

==
before
2014-09-29 20:41:27
nexus-4-jdq39-2
(fx-team/rev/fb47e92d7752):
5932±67
N=8

after
2014-09-29 20:57:28
nexus-4-jdq39-2
(fx-team/rev/135564e9e7f5):
6102±77
N=8

before
2014-09-30 06:06:20
nexus-s-3
(mozilla-inbound/rev/ab4869c0049d):
8759±80
N=8

after
2014-09-30 06:37:29
nexus-s-3
(mozilla-inbound/rev/68ea04e7f688):
9226±130
N=8

Regression range:

https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=fb47e92d7752&tochange=135564e9e7f5

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ab4869c0049d&tochange=68ea04e7f688

Appears to be due to bug 1065891
Gr, that's probably due to the migration code we added. Maybe instead of doing that migration on startup, we should do it the first time the search service is initialized.
Assignee: nobody → margaret.leibovic
Blocks: search
Priority: -- → P1
I just updated my Nightly, and this migration didn't even seem to work... this might need more attention than just addressing the regression.
(In reply to :Margaret Leibovic from comment #2)
> I just updated my Nightly, and this migration didn't even seem to work...
> this might need more attention than just addressing the regression.

FYI, this is because Nightly updates don't trigger this onAppUpdated code path. This will only be run when the Firefox version number changes, or when there's a new profile (like in autophone tests).
Fixing this by backing out the offending patch:
https://hg.mozilla.org/integration/fx-team/rev/e45de3a150aa
tracking-fennec: ? → 35+
https://hg.mozilla.org/mozilla-central/rev/e45de3a150aa
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
bc, can you help me verify that this regression is fixed? I see at least one of the curves went back down, but I want to make sure I'm reading things correctly.
Flags: needinfo?(bclary)
Margaret, your patch is definitely in the range where fx-team improved:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=ab4869c0049d&tochange=c3793a1dd33b

We'll be more certain when the patch is merged across the branches and the builds are tested. I'll follow them and give you an final opinion in a bit.
mozilla-central has now improved and your changeset is also in the range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=46f41cc9392d&tochange=84204f793602

We could wait for inbound, I would say you are good to go.
Flags: needinfo?(bclary)
Flags: qe-verify-
Flags: in-testsuite?
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.