Closed Bug 982988 Opened 6 years ago Closed 6 years ago

Fix browser_bug415846.js and then re-enable it for all except Mac

Categories

(Toolkit :: Safe Browsing, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 30

People

(Reporter: KWierso, Assigned: philor)

References

Details

Attachments

(1 file)

browser_bug415846.js recently started failing pretty much everywhere today with failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=36028549&tree=Fx-Team#error0 assumedly after bug 982664 pushed some itsatrap/itsanattack changes to production. 

One of the changes pushed that might have caused this failure is bug 971244 which redirected the pages from mozilla.org to itisatrap.org.

Did this make the test hit the network now?
This test was already disabled on Mac for being special, so when it gets re-enabled, it should stay disabled on Mac.

I disabled it on all platforms in https://hg.mozilla.org/mozilla-central/rev/4b3e5148fd02 and will be merging that around to various trees soon.
Summary: Fix browser_bug415846.js and then re-enable it. → Fix browser_bug415846.js and then re-enable it for all except Mac
My guess would be that it has been hitting the network and getting the redirect since gcp landed http://hg.mozilla.org/mozilla-central/rev/b0406a8daedd last week, but some burp in the redirect today caused it to fail for a while.
Component: Pages & Content → Phishing Protection
Product: www.mozilla.org → Firefox
Version: Production → Trunk
The longer version of that being:

The bug here is that http://hg.mozilla.org/mozilla-central/rev/b0406a8daedd#l4.14 changed the URL that we stuff into the phishing db, without changing http://mxr.mozilla.org/mozilla-central/source/browser/components/safebrowsing/content/test/browser_bug415846.js#41. The way things are supposed to work, the db knows that the page phishing tests load should be treated as bad, so they treat it as bad, and the http://hg.mozilla.org/mozilla-central/rev/b0406a8daedd#l3.10 part just keeps the page from loading in the background, confusing the issue and looking like a test might be depending on hitting the network.

Once we changed to not stopping mozilla.org loads, and to telling the db about itisatrap.org instead of the old mozilla.org URL, the test started actually hitting the network, loading the mozilla.org URL, getting redirected to itisatrap.org, and finding that URL in the phishing db, and still passing because it recognized itisatrap.org as phishing.

So the failure would have been when the test started loading the mozilla.org URL, but not getting the redirect. Disabling the test was still the right thing to do, it had become a test which depended on the network, which is a fatal mistake, but what caused us to see that wasn't a permanent change, it was just the usual sort of random infra failure that's the reason we don't hit the network.
Fixed and re-enabled in https://hg.mozilla.org/integration/fx-team/rev/cbce1167c712
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Thanks for the help, I indeed missed that URL.
https://hg.mozilla.org/mozilla-central/rev/cbce1167c712
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
QA Whiteboard: [qa-]
Product: Firefox → Toolkit
Depends on: 1246115
You need to log in before you can comment on or make changes to this bug.