1315161 - Back button/history bustage on merge to mozilla-central

Status: RESOLVED WORKSFORME

(Firefox :: Toolbars and Customization, defect)

Description

[Phil Ringnalda (:philor)]

I don't see any reasonable candidate for a cause, but when https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=4f09d9469e73adf32c7db6720504fcbe580516b3 landed on top of https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=38fcc30d818f99f3798865d551acce5681b0a3c0 apparently something in each one disagreed with the other, and now we have back button/history bustage like

https://treeherder.mozilla.org/logviewer.html#?job_id=5487900&repo=mozilla-central
https://treeherder.mozilla.org/logviewer.html#?job_id=5486060&repo=mozilla-central

and, dunno, customization

https://treeherder.mozilla.org/logviewer.html#?job_id=5487916&repo=mozilla-central

spread across all three trees now that it's merged around, so m-i/m-c/autoland are all closed.

Comment 1

[Phil Ringnalda (:philor)]

Since the failures that have anything to say before they fail are all complaining that "URLBarZoom.updateZoomButton is not a function", I'm looking at https://hg.mozilla.org/mozilla-central/rev/325acea6a61c as the autoland half of the bustage, but I don't yet have a theory for the mozilla-inbound half.

Comment 2

[Phil Ringnalda (:philor)]

Well, that was mozilla-inbound, what I don't know is what from autoland disliked it, causing it to go from perfectly happy on m-i to unhappy everywhere once it was on top of the autoland merge.

Comment 3

[Phil Ringnalda (:philor)]

Bleah. https://treeherder.mozilla.org/#/jobs?repo=try&author=[e-mail]&fromchange=e0f7fb990d67bf29fee46f2fe320001da1f24196&group_state=expanded&tochange=79c8acd7f09d3e5a359f6378cd5590ff37bf8732 is https://hg.mozilla.org/mozilla-central/rev/325acea6a61c (the thing that should be the cause of the troubles) and https://hg.mozilla.org/mozilla-central/rev/2f00f2194b90 (the cset before it), but both of them are green on try. Does that mean that something from autoland plus the backout in 325acea6a61c are busted, but only because they need a clobber to clear up the bustage? Seems really unlikely, but I had to push a backout to m-i anyway, so https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=561b87e98adacbd47769a71a0e6c72c5dcf66a9d is with everything clobbered.

Comment 4

[Phil Ringnalda (:philor)]

Clobbered with the clobberer, which Taskcluster ignores, so failures on Taskcluster are no surprise.

Comment 5

[Mark Banner (:standard8)]

This was fixed by landing:

https://hg.mozilla.org/mozilla-central/rev/8002299dfc3fb3b2c53e50e40a8e16f8dff2c3e7

which was a part re-backout based on the backout https://hg.mozilla.org/mozilla-central/rev/325acea6a61c

It looks something happened in the merge process that caused this.

Comment 6

[:Gijs (he/him)]

Resolving per comment #5. philor/standard8, is there anything we should be doing about "the merge process" to avoid this happening in future, or was this just bad luck / bad manual merge resolution, or something? If we need to do something else presumably it can happen in a followup bug filed in a better component (ie not Firefox itself)?

Comment 7

[:Gijs (he/him)]

Tomcat pointed out bug 1315227 which has more discussion about why stuff broke, so I guess we're done here.