As a web developer creating an service that provides cross-domain requests to web client similar to Google or Github, I would like to see much more obvious handling of CORS related errors - probably under the security category?

Actually, the scenario is more like: I make a web page that includes a resource served without the appropriate CORS headers. In Firefox, the console says nothing but the page doesn't load. In Chrome console, there's a loud red line which specifically points to the absence of x-origin headers.

Mark, is there any work being done in other bugs for reporting CORS errors to the console? Afaik there were some bugs open about related issues.

There is. There's bug 713980 that I did some work on before handing over to grobinson (who was looking at logging other errors to the webconsole). I think there was one open for web fonts too; will see if I can find it.

could use some detail about how we could make this easier.

There are two areas: * we should add a security category message colored in red that indicates that a request wasn't loaded because it is a cross-domain request that lacks the correct headers. I think the specific messages would be: - missing/invalid X-origin headers - mis-matched X-origin headers * we should ensure that in the netmonitor we clearly indicate that there is no response available due to the same reasons Note: I'm not sure what plans there are for the future of viewing the network things in the tools so it makes sense to me to view this as both a security-related console message in the console as well as an annotation of the network request ( wherever that request is shown ) Aside: do we have the right info from the platform to derive this info and show it to the user?

I was going to make a test case to compare & contrast w/ chrome canary, but i'm pressed for time today. The one color commentary I'll add to what jeffg said is I think it's important that a failure-to-load-because-of-cors shows up in console, not just in network. In particular unlike a traditional 404, these errors tend to show up on deployment after the code 'just worked' on a dev server, in my experience. (don't know if you guys track chrome-parity at the bug-tag level, but when I do anything x-domain, and things don't work as i expect, I switch to chrome just because of that.)

(In reply to David Ascher (:davida) from comment #6) ... > The one color commentary I'll add to what jeffg said is I think it's > important that a failure-to-load-because-of-cors shows up in console, not > just in network. In particular unlike a traditional 404, these errors tend > to show up on deployment after the code 'just worked' on a dev server, in my > experience. Yeah, I think it should really be logged under the security category - something has failed to load due to security policy. This feels to me to be exactly the reason we have the security logging category in the first place.

(In reply to Jeff Griffiths (:canuckistani) from comment #5) > There are two areas: > > * we should add a security category message colored in red that indicates > that a request wasn't loaded because it is a cross-domain request that lacks > the correct headers. This is what Garrett was working on for XHR - I wasn't aware that this hadn't landed; you can follow the progress for that in the bug I referred to in comment 3. > I think the specific messages would be: > > - missing/invalid X-origin headers > - mis-matched X-origin headers Guidance messages could be helpful; we already have messages for some CORS failures but they're not too good (e.g. see bug 769525 for a complaint on the current web fonts message).

(In reply to Mark Goodwin [:mgoodwin] from comment #8) > Guidance messages could be helpful *guidance on message content

I just filled a related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=972343 (about false positive CORS errors in dev console.)

Closing this as it's really just a dupe of bug 1121824. I added bug 1157817 to focus specifically on representing CORS / CSP problems in the netmonitor.

Did you mean to close this? Or commented on the wrong bug...?

(In reply to J. Ryan Stinnett [:jryans] from comment #12) > Did you mean to close this? Or commented on the wrong bug...? I think this is the right bug? What I'm saying is that the improvements we landed in bug 1121824 cover this bug.