The Valgrind builds at: https://tbpl.mozilla.org/?noignore=1&jobname=valgrind&rev=aa5e3b445810 show a "Rebuild request for Linux Valgrind opt failed. (network error)". It worked yesterday.
Rebuild uses self-serve/buildapi -> release engineering. See also bug 794192.
Actually, this appears to be a regression in Firefox. Clicking rebuild no longer shows the build.mozilla.org authentication prompt. Workaround: Use the "self-serve" link on tbpl, authenticate, switch back to TBPL and all should work. Finding regression range for this now.
STR: 1) In a session that hasn't yet authenticated on build.mozilla.org, visit: https://tbpl.mozilla.org/?jobname=build 2) Click one of the green 'B's on the right hand side. 3) Click the blue '+' icon in the bottom UI panel (tooltip "Rebuild"; is just above the text of form "started 04:14, finished 06:22, took 129mins") Expected: HTTP authentication prompt. Actual: No authentication prompt. Yellow banner at top of UI ("Rebuild request for <foo> failed. (network error)"). Web console shows: GET https://secure.pub.build.mozilla.org/buildapi/self-serve/mozilla-inbound/rev/<foo>?format=json [HTTP/1.1 401 Authorization Required 624ms] Partial regression range: Last good nightly: 2012-10-07 First bad nightly: 2012-10-08 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ecd4c4304219&tochange=9738e5a0190a Possibly bug 282547?
Probably I misunderstand the specs but I read: http://www.w3.org/TR/XMLHttpRequest/ If authentication fails, XMLHttpRequest origin and the request URL are same origin, Authorization is not in the list of author request headers, request username is null, and request password is null, user agents should prompt the end user for their username and password. Here we have a request URL that is not same-origin: [12:11:50.572] GET https://secure.pub.build.mozilla.org/buildapi/self-serve/try/rev/329478b78e3d?format=json [HTTP/1.1 401 Authorization Required 714ms] from: https://tbpl.mozilla.org/?tree=Try
Created attachment 670339 [details] [diff] [review] patch 1 It seems that chrome allows this type of requests (I'm not able to test IE). We have to decide if we want to follow the current XHR specs or ask for a change.
Can we test this one way or the other?
sure. This patch just comments out the same-origin check. I think we should land this patch and then discuss about what we want to do with the specs.
Comment on attachment 670339 [details] [diff] [review] patch 1 r=me, and please raise a spec issue after checking what other UAs do?
Created attachment 670409 [details] [diff] [review] patch 1b
Can you add a test too please?
Created attachment 670437 [details] [diff] [review] patch 1c I wrote a test for what the specs say and then I disabled it because of this bug. The opposite is going to be complex.. I don't really see a easy way to work with AuthPrompt from a mochitest.
Will this need an aurora landing as well?
(In reply to Boris Zbarsky (:bz) from comment #9) > Comment on attachment 670339 [details] [diff] [review] > patch 1 > > r=me, and please raise a spec issue after checking what other UAs do? Incidentally, with bug 771055 landed on tbpl-dev, IE 10 does not show the authorization prompt, causing the request to give a network error like the one in comment 0.
(In reply to Wes Kocher (:KWierso) from comment #15) > Incidentally, with bug 771055 landed on tbpl-dev, IE 10 does not show the > authorization prompt, causing the request to give a network error like the > one in comment 0. * And the workaround from comment 2 by signing in to self-serve first works as a workaround in IE10 as well, I should add.
Andrea, please may you request approval for aurora on the patch :-)
Comment on attachment 670437 [details] [diff] [review] patch 1c [Approval Request Comment] Bug caused by (feature/regressing bug #): 282547 User impact if declined: Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): String or UUID changes made by this patch:
Comment on attachment 670437 [details] [diff] [review] patch 1c Approving for aurora but not tracking for release as it is not a product regression or has a visible user facing impact
Taking a stab at adjusting the summary to reflect what this bug is actually about... (In reply to Andrea Marchesini (:baku) from comment #12) > The opposite is going to be complex.. I don't really see a easy way to work > with AuthPrompt from a mochitest. There are several ways to test auth prompts: one way is to just replace the auth prompt implementation entirely, as in e.g. test_auth_proxy.js or test_authentication.js.
If we're going to back off from our behavior change here, seems like we should back off entirely, and not leave it in one cycle to cause confusion.
Using the STR from comment 3, I can confirm that this issue is fixed on Firefox 18 beta 2. Checked on Windows 7 64-bit, Ubuntu 12.04 32-bit and Mac OSX 10.7. User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20121128060531 User Agent: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20121128060531 User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20121128060531