414853 - Event handler attributes should be initialized to null, not undefined

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Henri Sivonen (:hsivonen)]

Attachment: 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]]

I thought we'd fixed this in bug 159849.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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]

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 [:bzbarsky]]

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]

(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 [:bzbarsky]]

> 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]

(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 12

[Justin Lebar (not reading bugmail)]

(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 [:bzbarsky]]

For Window, yes.  For other objects there are other lists.

Comment 15

[Andreas Gal :gal]

Yeah I think I can fix this with bug 659350

Comment 16

[Boris Zbarsky [:bzbarsky]]

Fixed long ago in bug 659350.