1477781 - Incorrect regression range points to wrong bug

Status: NEW

(Testing :: mozregression, defect)

Description

[Gingerbread Man]

Attachment: mozregression_0927.txt

STR:
I was testing for bug 1477539 which involves these steps:
1. Open a site or local HTML file.
2. Zoom in repeatedly.
3. Bring up the Clear Recent History dialog (e.g. by pressing Ctrl+Shift+Del).
4. Select "Time range: Everything", and check only "Site Preferences".
5. Click the Clear Now button.

Actual results:
The zoom level is unchanged.

Expected results:
The zoom level resets, since the site preferences which include the zoom level have been cleared.


In mozregression-gui 0.9.27, steps were as follows:
1. File -> Run a new bisection.
2. Next button (defaults: firefox, 64, opt, <blank>)
3. Specific profile, reuse, <blank>, <blank>
4. 20180601100102, buildid, 20180602233306, buildid
5. cbf9ea7c5531a1ab80ab716eae4c8eb71f6ebaae rated good
6. 8c926373039374cd1a47d92215e9efb4d5557983 rated good
7. af6951f3fd418e6f363eaca1fb286658c627e57f rated bad
8. 538a689e3487689416f0c06630a19cbc4ab193f7 rated bad
9. 24447bd95fbd88c310b93e096f476873364a7ab1 rated bad
10. 178ac5165152f8a0978bf0740735da03122052d5 rated bad
11. ff4fa69beec83326b08a45b8abc0277e2972b4f4 rated bad
12. 4f9eec6361279d8657ffc4e6ef5c84e8f5d08c56 rated bad

Actual results:
Bug 1460617 is pointed out as the culprit.

Push log in Log View:
https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=4f9eec6361279d8657ffc4e6ef5c84e8f5d08c56&full=1

Push log in Bisection Informations with the last item in Bisection Progress selected:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ee1e13b5033892b805946ab20b42b7ea0a0b9aea&tochange=4f9eec6361279d8657ffc4e6ef5c84e8f5d08c56

Expected results:
Bug 1422365 is almost certainly to blame. I expect the push log link to be a short range that includes it.

Notes:
I clicked the build_url link any manually retested each build. The results were the same as what I picked in mozregression-gui.

Comment 1

[William Lachance (:wlach)]

The problem here is that there is no merge commit, because it's a fast forward and mozregression got confused.

I think we should be able to figure out that the offending changesets in the bad range came from autoland though. Will investigate when I return, leaving NI open for now.

Comment 2

[Ian Moody [:Kwan] (UTC+0)]

Isn't this just that the find-by-elimination branch lacks the logic[0] to grab the parent of the first changeset in the range and mark that as last-known-good, and instead treats first push in the range is last-known-good?

[0] https://github.com/mozilla/mozregression/blob/2b19b6d47f286303165d7e0e02ab0c757a2a4c6c/mozregression/bisector.py#L308-L322

Comment 3

[Ian Moody [:Kwan] (UTC+0)]

Hmm, and the comment there seems to have a typo, needs s/youngest/oldest/

So I think the best thing to do here, rather than copy the logic over ala my fix for bug 1426105, might be to de-dupe the push-fetching code a bit, so only the branch and youngest rev setting are split.  That would also have fixed 1426105.

Comment 4

[Ian Moody [:Kwan] (UTC+0)]

Experimenting with doing so here: https://github.com/KwanEsq/mozregression/commit/dedupeMergeHandling

Seems to be alright.  Will try and test a bit more.

Not sure if we lose anything logging-wise with exc_info instead of the new LOG.error([...] exc)) from https://github.com/mozilla/mozregression/commit/2b19b6d47f286303165d7e0e02ab0c757a2a4c6c but I'm assuming not. (and should that LOG be an error rather than debug?)

Comment 5

[William Lachance (:wlach)]

Thanks :Kwan for looking into this! Your changes seem to be on the right track to me, I'll assign the bug to you. Please let me know when you've opened a PR.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 7

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.