Closed
Bug 1192416
Opened 9 years ago
Closed 9 years ago
Make trackingprotection not make a remote connection in talos
Categories
(Testing :: Talos, defect, P1)
Testing
Talos
Tracking
(firefox42 fixed)
Tracking | Status | |
---|---|---|
firefox42 | --- | fixed |
People
(Reporter: bgrins, Assigned: bgrins)
References
Details
(Whiteboard: [fxprivacy] [campaign])
Attachments
(2 files)
1.39 KB,
patch
|
MattN
:
review+
|
Details | Diff | Splinter Review |
837 bytes,
patch
|
bgrins
:
review+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•9 years ago
|
||
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
Assignee | ||
Comment 2•9 years ago
|
||
Updated•9 years ago
|
Iteration: --- → 42.3 - Aug 10
Flags: firefox-backlog+
Whiteboard: [fxprivacy] [campaign]
Updated•9 years ago
|
Attachment #8645203 -
Flags: review?(MattN+bmo) → review+
Assignee | ||
Comment 3•9 years ago
|
||
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)
Comment 4•9 years ago
|
||
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)
Assignee | ||
Comment 5•9 years ago
|
||
(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)
Assignee | ||
Comment 6•9 years ago
|
||
(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)
Assignee | ||
Comment 7•9 years ago
|
||
Landed in talos: https://hg.mozilla.org/build/talos/rev/c7446ecc3bfb
Assignee | ||
Comment 8•9 years ago
|
||
Try push with the updated talos.json: https://treeherder.mozilla.org/#/jobs?repo=try&revision=60b6d44a881d
Assignee | ||
Comment 9•9 years ago
|
||
Attachment #8645236 -
Flags: review+
Assignee | ||
Comment 10•9 years ago
|
||
Try push with the offending patch from Bug 1175606 applied: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2a29513c92b
Comment 11•9 years ago
|
||
Hey Brian, when you have a moment go ahead and set the point value.
Flags: needinfo?(bgrinstead)
Comment hidden (typo) |
Assignee | ||
Comment 13•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Points: --- → 1
Flags: needinfo?(bgrinstead)
Updated•9 years ago
|
Priority: -- → P1
Assignee | ||
Comment 14•9 years ago
|
||
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.
Assignee | ||
Comment 15•9 years ago
|
||
(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)
Comment 16•9 years ago
|
||
Backed out the bump in https://hg.mozilla.org/integration/fx-team/rev/222f1e42ebd9
Comment 17•9 years ago
|
||
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)
Comment 20•9 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox42:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in
before you can comment on or make changes to this bug.
Description
•