21876 2013-04-30 12:48:56 +0000 It would be nice to distinguish error events. For example, specific errors should be generated for access control failures and for different kinds of underlying network failures. 2013-06-18 23:27:55 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#event-source-fail-reasons P3 normal Unsorted 1 contributor ian dirkjan ian mike contributor oldest_to_newest 87003 0 contributor 2013-04-30 12:48:56 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html Multipage: http://www.whatwg.org/C#event-source-fail-reasons Complete: http://www.whatwg.org/c#event-source-fail-reasons Referrer: Comment: It would be nice to disable error events. For example, specific errors should be generated for access control failures and for different kinds of underlying network failures. Posted from: 85.223.109.191 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130428 Firefox/22.0 87005 1 dirkjan 2013-04-30 13:20:07 +0000 I ran into this while testing EventSource today (as a somewhat unsuspecting webdev who does some Mozilla things once in a while). I actually ran into two problems that could be much easier to debug (seemingly without incurring a large implementation burden). - Require implementations to raise errors on connection soon after actually connecting. Gecko apparently doesn't do this: https://bugzilla.mozilla.org/show_bug.cgi?id=780396. - Require implementations to throw more specific error events. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=867105 about access control / CORS. Combined, these made for a big WTF on my first try of implementing this. I was suspecting CORS errors to be raised immediately (and clearly). Instead, I got a generic error only after getting the server to send a first event. The second WTF was generic failure on timeout. My server requires setting a heartbeat explicitly, so making it clear that there was a timeout would have made this much easier. I suspect the usual network error suspects should have somewhat specific errors, at least. 87033 2 ian 2013-04-30 18:18:45 +0000 We should definitely encourage browsers to report detailed errors to their consoles, but we can't report detailed errors to the script, because that would allow this to be used to do intranet port-scanning and resource discovery, which would be a huge security problem. 88115 3 dirkjan 2013-05-23 07:17:17 +0000 Is there anything I can do to help move this forward? 89128 4 ian 2013-06-11 22:15:19 +0000 One thing to do would be to file bugs on the browsers directly, asking for more information, giving specific examples (test cases) where the current debugging information is inadequate. As far as the spec goes, I can add some suggestions in the EventSource section saying that in case of errors, detailed information should be logged so the developer can see it, would that help? 89149 5 dirkjan 2013-06-12 07:19:00 +0000 As I mentioned in comment 1, I already filed bugs about this for Gecko. WebKit/Blink already log CORS errors to the console, at least. This bug was filed based on suggestion there, see https://bugzilla.mozilla.org/show_bug.cgi?id=867105#c1. So yes, it would be helpful if you could add some suggestions to the spec. CORS errors and underlying network errors would seem like no-brainer cases to me. 89520 6 ian 2013-06-18 23:25:51 +0000 I've added a section (see diff below). Please do file a new bug if you see anything else that we should encourage user agents to report. Thanks! 89521 7 contributor 2013-06-18 23:27:55 +0000 Checked in as WHATWG revision r7988. Check-in comment: Encourage more detailed debugging aids for EventSource http://html5.org/tools/web-apps-tracker?from=7987&to=7988