Closed Bug 1192416 Opened 4 years ago Closed 4 years ago

Make trackingprotection not make a remote connection in talos

Categories

(Testing :: Talos, defect, P1)

defect
Points:
1

Tracking

(firefox42 fixed)

RESOLVED FIXED
mozilla42
Iteration:
42.3 - Aug 10
Tracking Status
firefox42 --- fixed

People

(Reporter: bgrins, Assigned: bgrins)

References

Details

(Whiteboard: [fxprivacy] [campaign])

Attachments

(2 files)

Bug 1175606 burned Talos because "Non-local network connections are disabled and a connection attempt to tracking.services.mozilla.com (52.10.204.176) was made.": https://bugzilla.mozilla.org/show_bug.cgi?id=1175606#c17

We need to update the prefs to match what we do for tests in-tree: http://mxr.mozilla.org/mozilla-central/source/testing/profiles/prefs_general.js#91
We need to land this update to talos prefs ASAP so that we can land Bug 1175606 in time to ride the trains to 42.

I've reproduced the crash without my patch applied (and that it's fixed with it applied) by running:

talos --develop --executablePath /fx-team/objdir.noindex/dist/Nightly.app/Contents/MacOS/firefox --activeTests tresize
Copied from http://mxr.mozilla.org/mozilla-central/source/testing/profiles/prefs_general.js#91
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Attachment #8645203 - Flags: review?(MattN+bmo)
Iteration: --- → 42.3 - Aug 10
Flags: firefox-backlog+
Whiteboard: [fxprivacy] [campaign]
Attachment #8645203 - Flags: review?(MattN+bmo) → review+
Joel / William - just a heads up about this change.  Is there any reason we can't land some pref changes and then bump talos.json?  I see quite a few commits [0] since the last talos.json bump on 08-01 [1]

[0]: http://hg.mozilla.org/build/talos/
[1]: https://hg.mozilla.org/mozilla-central/filelog/d6ea652c579992daa9041cc9718bb7c6abefbc91/testing/talos/talos.json
Flags: needinfo?(wlachance)
Flags: needinfo?(jmaher)
I was going to update talos and have a try run with all the latest:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d79187e347f

if you want, when that is green we can land and update.  If this is on Beta, we need to talk, otherwise aurora/central are just fine.

Speaking of which, would there be an issue with this on Aurora?
Flags: needinfo?(jmaher)
(In reply to Joel Maher (:jmaher) from comment #4)
> I was going to update talos and have a try run with all the latest:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d79187e347f
> 
> if you want, when that is green we can land and update.  If this is on Beta,
> we need to talk, otherwise aurora/central are just fine.
> 
> Speaking of which, would there be an issue with this on Aurora?

Thanks for the response!  My plan will be to push to talos and then create a try push with the updated talos.json.  If that looks good, we'll push the update to fx-team.  This doesn't need any uplift, it's just going on central.
Flags: needinfo?(wlachance)
(In reply to Joel Maher (:jmaher) from comment #4)
> Speaking of which, would there be an issue with this on Aurora?

It doesn't need to be uplifted, but it wouldn't hurt to be uplifted if it happened to be for some reason (it's just overriding some safe browsing style prefs for Tracking Protection that will never be used on anything pre-42)
Hey Brian, when you have a moment go ahead and set the point value.
Flags: needinfo?(bgrinstead)
Points: --- → 1
Flags: needinfo?(bgrinstead)
Priority: -- → P1
So.. apparently this is burning Windows T-E10s with what looks like an infrastructure issue: https://treeherder.mozilla.org/#/jobs?repo=fx-team&revision=7fe4321e40bc.

I'm guessing it's due to one of the pushes since the last talos bump on 8-1 and not due to this simple pref change, but it's hard to say for sure since my try runs didn't include T-E10s (and in fact I don't know how to include them with the try syntax).

My best idea as a workaround is to branch talos from d44548b8feb9 (last known good rev) and apply 2181cef265e7 (our pref-change rev) on top of that.
(In reply to Brian Grinstead [:bgrins] from comment #14)
> So.. apparently this is burning Windows T-E10s with what looks like an
> infrastructure issue:
> https://treeherder.mozilla.org/#/jobs?repo=fx-team&revision=7fe4321e40bc.
> 
> I'm guessing it's due to one of the pushes since the last talos bump on 8-1
> and not due to this simple pref change, but it's hard to say for sure since
> my try runs didn't include T-E10s (and in fact I don't know how to include
> them with the try syntax).
> 
> My best idea as a workaround is to branch talos from d44548b8feb9 (last
> known good rev) and apply 2181cef265e7 (our pref-change rev) on top of that.

Talking with :philor, we decided the best thing to do was back out this bump commit.  Apparently there isn't a way to run T-E10s on try and I don't know enough about this problem to make a good decision.  Joel, a couple of things we discussed were to branch talos as outlined above or just say hide WinXP e10s until we can figure it out.  Or maybe the failure will be immediately obvious to you.  Is there any possible way you could give some guidance on this before the merge on Monday?  Thanks!
Flags: needinfo?(jmaher)
I am fine hiding winxp e10s if that is needed, we just enabled this yesterday, so hiding them for another week if needed isn't a big deal.  It fails fast which is good, so less concern on tying up machines for 1 hour just for a failure.  

I have a couple ideas of the problem, but it will take some debugging.
Flags: needinfo?(jmaher)
Duplicate of this bug: 1192367
https://hg.mozilla.org/mozilla-central/rev/d2da80a77302
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.