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.
Component: Tinderboxpushlog → Release Engineering
OS: Linux → All
Product: Webtools → mozilla.org
Summary: Network error when attempting to rebuild Valgrind builds → Network error when attempting to retrigger Valgrind builds using self-serve
Version: Trunk → other
Component: Release Engineering → Release Engineering: Developer Tools
QA Contact: hwine
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?
Component: Release Engineering: Developer Tools → XML
Keywords: regression, regressionwindow-wanted
Product: mozilla.org → Core
QA Contact: hwine
Summary: Network error when attempting to retrigger Valgrind builds using self-serve → Retriggering builds on TBPL using self-serve fails unless previously authenticated, as of 2012-10-08 Nightly
Version: other → 18 Branch
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.
Attachment #670339 - Flags: review?(bzbarsky)
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?
Attachment #670339 - Flags: review?(bzbarsky) → review+
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?
Assignee: nobody → amarchesini
Status: NEW → ASSIGNED
status-firefox18: --- → affected
tracking-firefox18: --- → ?
(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.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Whiteboard: [buildapi][selfserve] → [buildapi][selfserve] Workaround: Authenticate at https://secure.pub.build.mozilla.org/buildapi/self-serve/ first
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:
Attachment #670437 - Flags: approval-mozilla-aurora?
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
Attachment #670437 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
Summary: Retriggering builds on TBPL using self-serve fails unless previously authenticated, as of 2012-10-08 Nightly → XHR authentication prompt no longer appears for cross-origin requests (e.g. retriggering builds on TBPL using self-serve fails unless previously authenticated)
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.
tracking-firefox18: - → ?
status-firefox18: affected → fixed
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
status-firefox18: fixed → verified
Whiteboard: [buildapi][selfserve] Workaround: Authenticate at https://secure.pub.build.mozilla.org/buildapi/self-serve/ first
You need to log in before you can comment on or make changes to this bug.