Open Bug 1477781 Opened 6 years ago Updated 5 months ago

Incorrect regression range points to wrong bug


(Testing :: mozregression, defect)



(Not tracked)


(Reporter: gingerbread_man, Unassigned)



(1 file, 1 obsolete file)

Attached file mozregression_0927.txt
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:

Push log in Bisection Informations with the last item in Bisection Progress selected:

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

I clicked the build_url link any manually retested each build. The results were the same as what I picked in mozregression-gui.
Flags: needinfo?(wlachance)
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.
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?

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.
Experimenting with doing so here:

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 but I'm assuming not. (and should that LOG be an error rather than debug?)
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.
Assignee: nobody → moz-ian
Flags: needinfo?(wlachance)
Ever confirmed: true

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

Assignee: nobody → moz-ian
Severity: normal → S3

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

Assignee: moz-ian → nobody
Attachment #9383315 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.