Bug 178701

Summary: Overly-generic "XMLHttpRequest cannot load URL due to access control checks" error on flakiness dashboard
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: aboya, ap, bugs-noreply, dbates, mcatanzaro
Priority: P2    
Version: Other   
Hardware: PC   
OS: Linux   

Description Michael Catanzaro 2017-10-23 20:07:39 PDT
In our layout test results, we have a link to the flakiness dashboard, e.g.:

http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=imported%2Fw3c%2Fweb-platform-tests%2Fencrypted-media%2Fclearkey-mp4-playback-temporary-clear-encrypted.html

The flakiness dashboard has been a completely white page for as long as I remember. I noticed today that it works fine in Firefox and Chrome, so the fact that it doesn't work is probably a WebKit bug. It's filled with lovely errors like this:

XMLHttpRequest cannot load https://svn.webkit.org/repository/webkit/trunk/LayoutTests/platform/gtk/TestExpectations due to access control checks.
request — loader.js:56
_loadExpectationsFiles — loader.js:236
_loadNext — loader.js:111
_handleResourceLoad — loader.js:205
_handleResultsFileLoadError — loader.js:200
(anonymous function) — loader.js:139
(anonymous function) — dashboard_base.js:148
onreadystatechange — loader.js:53
request — loader.js:56

Cannot load XMLHttpRequest "due to access control checks." I've seen this very generic error result in breakage on many, many other websites, but let's focus on the flakiness dashboard for now. We should debug the code to figure out what's going on. It's probably a soup-specific issue.
Comment 1 Michael Catanzaro 2017-10-23 20:10:59 PDT
(In reply to Michael Catanzaro from comment #0)
> I've seen this
> very generic error result in breakage on many, many other websites, but
> let's focus on the flakiness dashboard for now.

Dan, this is an example of the issue that I mentioned to you at the Contributor's Meeting. At the time I assumed that Safari would be affected as well, but now I assume it's probably related to our network backend, as the flakiness dashboard is presumably working fine in Safari.

Taking a quick look at the code, it doesn't seem easy to figure out where ResourceErrors are coming from, so I'll need to add some more debugging to find out.
Comment 2 Michael Catanzaro 2017-10-24 19:21:20 PDT
Wow, turns out the flakiness dashboard actually does work: it's just extremely, extremely slow in WebKit. I thought it was broken because I never kept the page open long enough for it do show anything other than a white page.

Anyway, we can still continue to use this bug for debugging the access control issue.
Comment 3 Alexey Proskuryakov 2017-10-27 23:08:57 PDT
For some context, the feature that relies on loading TestExpectations is broken anyway. The code doesn’t understand modern expectations and fallback order. I can’t check it right now, but it’s entirely possible that the same access control failure occurs in Safari too. 

If the page loads much faster in other browsers, I’m super interested to figure out why.
Comment 4 Michael Catanzaro 2017-10-28 10:01:59 PDT
Sorry, this proved a bit tricker to debug than I expected and it fell off my priorities list. I'm suspecting it's GTK/WPE-specific. If the dashboard loads for you in fewer than about 40 seconds, then you're not experiencing the bug. It's a completely white page for us until then.

CCing aboya regarding the problem with computing expectations on the official flakiness dashboard, just so you're aware. I didn't know about that problem.
Comment 5 Alexey Proskuryakov 2017-10-28 15:34:46 PDT
The link from bug description loaded in 35 seconds for me in Safari, and in 40 seconds in Chrome.
Comment 6 Michael Catanzaro 2017-10-28 16:38:16 PDT
(In reply to Alexey Proskuryakov from comment #5)
> The link from bug description loaded in 35 seconds for me in Safari, and in
> 40 seconds in Chrome.

Hm, I must not have been paying attention the other day... it is very slow in all of Epiphany, Chrome, and Firefox, indeed. So not a WebKit problem, indeed.

We should still at least provide a more specific error message, so that web developers have some clue what is wrong.