This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
PORTING from TRACKER, ISSUE-186 [see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0065.html] I removed EventException from DOM Core and I think that change makes sense. We use DOMException for most of our APIs. Only dispatchEvent() throws exceptions of this type and it seems like unneeded complexity to me. DOM Level 3 Events says dispatchEvent() can throw these exceptions: EventException.UNSPECIFIED_EVENT_TYPE_ERR, EventException.DISPATCH_REQUEST_ERR, DOMException.NOT_SUPPORTED_ERR, and DOMException.INVALID_CHARACTER_ERR. I have not been able to get implementations to throw any of the latter two exceptions. Examples would be most welcome. In fact the text for INVALID_CHARACTER_ERR seems to overlap with UNSPECIFIED_EVENT_TYPE_ERR as they are both talking about restrictions on Event.type. However, what the restrictions on Event.type are is not at all clear. Event.type only says that no events should be created that contain whitespace. It does not say anything about the empty string, or whether initializing events with whitespace in their type will throw an error or not (either then or later). I do not think we need UNSPECIFIED_EVENT_TYPE_ERR at all really. Why should we require invoking initEvent()? And DISPATCH_REQUEST_ERR could easily be replaced by INVALID_STATE_ERR. We use it that way in tons of APIs. ------------------ From: Ojan Vafai <ojan@chromium.org> Date: Wed, 9 Mar 2011 19:21:52 +1100 This change sounds good to me. I generally support simplifying and consolidating the exceptions thrown. I'm strongly suspect we could change the exceptions thrown in most cases without a hit to web compatibility. On Sat, Mar 5, 2011 at 1:52 AM, Anne van Kesteren <annevk@opera.com> wrote: > I removed EventException from DOM Core and I think that change makes sense. > We use DOMException for most of our APIs. Only dispatchEvent() throws > exceptions of this type and it seems like unneeded complexity to me. > > DOM Level 3 Events says dispatchEvent() can throw these exceptions: > EventException.UNSPECIFIED_EVENT_TYPE_ERR, > EventException.DISPATCH_REQUEST_ERR, DOMException.NOT_SUPPORTED_ERR, and > DOMException.INVALID_CHARACTER_ERR. > > I have not been able to get implementations to throw any of the latter two > exceptions. Examples would be most welcome. WebKit does throw NOT_SUPPORTED_ERR in a number of cases (see http://codesearch.google.com/codesearch?as_q=NOT_SUPPORTED_ERR&vert=chromium&as_lang=c%2B%2B&as_filename=WebKit). I haven't looked at most of these to see if they are actually valid uses of this exception or if the code can even be hit. It took some hunting but I finally got it to fire in one case to fire in a real page, http://plexode.com/eval3/#jt=document.createTreeWalker(). > In fact the text for INVALID_CHARACTER_ERR seems to overlap with > UNSPECIFIED_EVENT_TYPE_ERR as they are both talking about restrictions on > Event.type. However, what the restrictions on Event.type are is not at all > clear. Event.type only says that no events should be created that contain > whitespace. It does not say anything about the empty string, or whether > initializing events with whitespace in their type will throw an error or not > (either then or later). > > I do not think we need UNSPECIFIED_EVENT_TYPE_ERR at all really. Why should > we require invoking initEvent()? > Indeed.
[see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0081.html] On 3/9/11 3:21 AM, Ojan Vafai wrote: > WebKit does throw NOT_SUPPORTED_ERR So does Gecko: http://mxr.mozilla.org/mozilla-central/search?string=NS_ERROR_DOM_NOT_SUPPORTED_ERR Like Ojan, I have not checked whether these are places where the spec calls for it. -Boris
[see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0084.html] On Wed, 09 Mar 2011 19:04:23 +0100, Jacob Rossi <jrossi@microsoft.com> wrote: > IE9 also throws NOT_SUPPORTED_ERR (per the spec). I think what Boris and Ojan said is that WebKit and Gecko sometimes throw NOT_SUPPORTED_ERR. Not whether they throw it for dispatchEvent() and so far nobody has given an example of when dispatchEvent() would throw that (in actual code). -- Anne van Kesteren http://annevankesteren.nl/
[see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0093.html] From: Jacob Rossi <jrossi@microsoft.com> Date: Thu, 10 Mar 2011 23:04:11 +0000 Yes. Looks like IE9 throws it for the scenario I described (redispatching a trusted event) and also when you call createEvent( ) with an unrecognized interface, like createEvent("foo"). > -----Original Message----- > From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] > Sent: Wednesday, March 09, 2011 7:38 PM > To: Anne van Kesteren > Cc: www-dom@w3.org; Jacob Rossi > Subject: Re: [DOM3Events] Exceptions > > On 3/9/11 1:35 PM, Anne van Kesteren wrote: > > On Wed, 09 Mar 2011 19:04:23 +0100, Jacob Rossi <jrossi@microsoft.com> > > wrote: > >> IE9 also throws NOT_SUPPORTED_ERR (per the spec). > > > > I think what Boris and Ojan said is that WebKit and Gecko sometimes > > throw NOT_SUPPORTED_ERR. Not whether they throw it for dispatchEvent() > > and so far nobody has given an example of when dispatchEvent() would > > throw that (in actual code). > > Oh, I was missing that context. dispatchEvent does not throw > NOT_SUPPORTED_ERR in Gecko. The only event-related thing that seems to is > createEvent. > > Trying to redispatch a trusted event will reset it to untrusted, then allow > redispatch in Gecko. > > -Boris >
[see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0085.html] IE9 throws this if you receive a trusted event, cache the event object, then later try to dispatch that event object through dispatchEvent.
As part of the WebIDL update from several weeks ago, I yanked the old exceptions out and put in the new ones that (I believe) match the DOM4 set. Everything should be consistent now. Let me know if you notice anything out of the ordinary. Thanks! http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.216#event-exceptions
Was it not decided that InvalidCharacterError could never be thrown for Event.type? That Event.type could be anything.
(In reply to comment #6) > Was it not decided that InvalidCharacterError could never be thrown for > Event.type? That Event.type could be anything. I don't see InvalidCharacterError being thrown in DOM4. I also tested the major browsers to see if any threw a similar error, of those tested (Opera, IE, Chrome, Safari, Firefox), none of them threw this error (or an error by its former name). I tried with random unicode characters, spaces, null/"null" (which is still inconsistent between browsers), and embedded nulls. Given these test results, I will be removing the criteria for this exception. (I also don't see NotSupportedError being thrown from DOM4 either, though this test appears to pass in all major browsers: http://samples.msdn.microsoft.com/ietestcenter/domevents/domevents_harness.htm?url=createEvent.NOT_SUPPORTED_ERR.html)
NotSupportedError is thrown here: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-createevent The InvalidCharacterError is pretty clearly a bug, I think; a reference is made to "a DOMString as conforming to the restrictions in Event.type", but no such restrictions are listed anywhere I can find.
InvalidCharacterError is now gone. Thanks! http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.217#event-exceptions