Last Comment Bug 414853 - Event handler attributes should be initialized to null, not undefined
: Event handler attributes should be initialized to null, not undefined
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: mozilla9
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.whatwg.org/specs/web-apps/...
: 522401 590198 598031 601002 642753 (view as bug list)
Depends on: 659350
Blocks: 264525 642753
  Show dependency treegraph
 
Reported: 2008-01-30 07:44 PST by Henri Sivonen (:hsivonen)
Modified: 2012-08-12 13:41 PDT (History)
21 users (show)
Ms2ger: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case that probes window.onload (246 bytes, text/html)
2008-01-30 07:44 PST, Henri Sivonen (:hsivonen)
no flags Details

Description Henri Sivonen (:hsivonen) 2008-01-30 07:44:47 PST
Created attachment 300376 [details]
Test case that probes window.onload

Build ID:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008012804 Minefield/3.0b3pre

Steps to reproduce:
1) Load the attachment

Actual results:
window.onload is undefined when not set.

Expected results:
Expected window.onload to be null, since Gecko support the load event.

Additional info:
I ran across this when trying to future-proof Validator.nu UI script. The use case is detecting support for upcoming event handlers such as onhashchanged.

HTML 5 says event handler DOM attributes should be initialized to null and that the window object is considered to have event handler DOM attributes. Safari 3, Opera 9.20 and, reportedly, IE6 initialize to null. Gecko and Opera 9.50 don't.
Comment 1 Peter Van der Beken [:peterv] 2008-01-30 09:29:43 PST
I thought we'd fixed this in bug 159849.
Comment 2 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-01-30 09:36:39 PST
We only fixed it for the assigning case.  That is, assigning in |with| works.  The default value is still null.

I assume HTML5 has an exhaustive list of all attributes that should return null.  If so, we should make that happen for things in that list.
Comment 3 Garrett Smith 2009-06-24 01:04:30 PDT
The default (In reply to comment #2)
> We only fixed it for the assigning case.  That is, assigning in |with| works. 
> The default value is still null.
> 

*What* default value?

Event handler properties are not present, as pointed out in bug 159849, comment 10. Being absent, they cannot have any value, and so obviously cannot have a value null. AFAIK, it has always been this way.

> I assume HTML5 has an exhaustive list of all attributes that should return
> null.  If so, we should make that happen for things in that list.

Regardless of HTML, It is important for feature detection of event properties. 

var isOnContextMenuSupported = "oncontextmenu" in document;
typeof document.oncontextmenu; // "function" or "object" (for null)

It is not possible to detect events this way. See the CFT project for some non-standard workarounds.
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-06-24 05:27:51 PDT
I clearly meant undefined in comment 2, for what it's worth.

> It is important for feature detection of event properties.

Assuming that such feature detection is desirable, of course.  I somewhat question that, since lack of a property doesn't mean the browser doesn't support the event... just that it has no on* property for it (which is the case for all sorts of events).  Your example is a good example of what I think people should NOT be doing.
Comment 5 Garrett Smith 2009-06-24 08:39:13 PDT
(In reply to comment #4)
> I clearly meant undefined in comment 2, for what it's worth.
> 

AISB, unset Event handlers do not have any value because they are not present as properties. [[Get]] looks on the object and then up the prototype chain until no [[Prototype]] exists, at which point it returns the value |undefined|. 

> > It is important for feature detection of event properties.
> 
> Assuming that such feature detection is desirable, of course.  I somewhat
> question that, since lack of a property doesn't mean the browser doesn't
> support the event... just that it has no on* property for it (which is the case
> for all sorts of events).  

Only in Mozilla. 

Your example is a good example of what I think
> people should NOT be doing.

What alternative do you propose? Can you show an example of how to detect "oncontextmenu"?
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-06-24 08:44:20 PDT
> Only in Mozilla. 

This is demonstrably false.  For example, no browser I know of has an onDOMNodeInserted property anywhere, even if it supports the DOMNodeInserted event.

> Can you show an example of how to detect "oncontextmenu"?

What you want to be detecting isn't "oncontextmenu" but whether the browser fires "contextmenu" events (which you can register for using addEventListener, not just oncontextmenu).  There is no way to determine this at the moment, and I think there should be.  But that has nothing to do with this bug.
Comment 7 Garrett Smith 2009-06-24 10:04:25 PDT
(In reply to comment #6)
> > Only in Mozilla. 
> 
> This is demonstrably false.  For example, no browser I know of has an
> onDOMNodeInserted property anywhere, even if it supports the DOMNodeInserted
> event.
> 

True, but my "only in Mozilla" comment was about event handlers as properties. 

The bug title uses the word "attributes" which is ambiguous, as "attribute" is more commonly used for an HTML attribute and "property" is more commonly used for a DOM property. 

Event handler properties are widely supported. They are more commonly used than events that do not have a dom property, such as MutationEvents, or the DOM API in general.

> > Can you show an example of how to detect "oncontextmenu"?
> 
> What you want to be detecting isn't "oncontextmenu" but whether the browser
> fires "contextmenu" events (which you can register for using addEventListener,
> not just oncontextmenu).  There is no way to determine this at the moment, and
> I think there should be.  But that has nothing to do with this bug.

Good point. Synthesizing events can provide stronger inferences. The DOM Events API makes sythesizing events hard. It is not implemented widely enough. 

A well-designed API should make it easy (among other characteristics). It should also be widely supported. 

To reduce bug noise, we should take further such discussion to email.
Comment 8 Jesse Ruderman 2009-10-14 20:25:52 PDT
*** Bug 522401 has been marked as a duplicate of this bug. ***
Comment 9 Anthony Ricaud (:rik) 2010-08-26 01:37:18 PDT
*** Bug 590198 has been marked as a duplicate of this bug. ***
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-09-20 09:34:15 PDT
*** Bug 598031 has been marked as a duplicate of this bug. ***
Comment 11 Justin Lebar (not reading bugmail) 2010-09-30 22:19:15 PDT
*** Bug 601002 has been marked as a duplicate of this bug. ***
Comment 12 Justin Lebar (not reading bugmail) 2010-10-01 11:14:44 PDT
(In reply to comment #2)
> I assume HTML5 has an exhaustive list of all attributes that should return
> null.  If so, we should make that happen for things in that list.

Is it just [1]?

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
Comment 13 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-10-01 11:29:36 PDT
For Window, yes.  For other objects there are other lists.
Comment 14 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-03-18 05:31:38 PDT
*** Bug 642753 has been marked as a duplicate of this bug. ***
Comment 15 Andreas Gal :gal 2011-05-24 11:01:50 PDT
Yeah I think I can fix this with bug 659350
Comment 16 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-08-12 10:09:13 PDT
Fixed long ago in bug 659350.

Note You need to log in before you can comment on or make changes to this bug.