Bug 16333 - Exceptions
Exceptions
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: DOM3 Events
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Travis Leithead [MSFT]
public-webapps-bugzilla
http://lists.w3.org/Archives/Public/w...
: LC, needsReview
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-12 20:51 UTC by Travis Leithead [MSFT]
Modified: 2012-03-20 01:20 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Travis Leithead [MSFT] 2012-03-12 20:51:43 UTC
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.
Comment 1 Travis Leithead [MSFT] 2012-03-12 20:52:51 UTC
[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
Comment 2 Travis Leithead [MSFT] 2012-03-12 20:54:40 UTC
[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/
Comment 3 Travis Leithead [MSFT] 2012-03-12 20:56:04 UTC
[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
>
Comment 4 Travis Leithead [MSFT] 2012-03-12 20:56:47 UTC
[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.
Comment 5 Travis Leithead [MSFT] 2012-03-17 00:20:32 UTC
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
Comment 6 Anne 2012-03-19 16:03:03 UTC
Was it not decided that InvalidCharacterError could never be thrown for Event.type? That Event.type could be anything.
Comment 7 Travis Leithead [MSFT] 2012-03-19 19:02:19 UTC
(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)
Comment 8 Ms2ger 2012-03-19 21:33:14 UTC
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.
Comment 9 Travis Leithead [MSFT] 2012-03-20 01:20:52 UTC
InvalidCharacterError is now gone. Thanks!

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.217#event-exceptions