The default bug view has changed. See this FAQ.

Event handler attributes should be initialized to null, not undefined

RESOLVED FIXED in mozilla9

Status

()

Core
DOM: Events
RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: hsivonen, Unassigned)

Tracking

Trunk
mozilla9
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.
I thought we'd fixed this in bug 159849.
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

8 years ago
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.
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

8 years ago
(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"?
> 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

8 years ago
(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.

Updated

8 years ago
Duplicate of this bug: 522401
Flags: wanted1.9.2?

Updated

7 years ago
Duplicate of this bug: 590198
Duplicate of this bug: 598031
Duplicate of this bug: 601002
(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
For Window, yes.  For other objects there are other lists.

Updated

7 years ago
Blocks: 264525

Updated

6 years ago
Flags: wanted1.9.2?
Whiteboard: [wanted2.1?]

Updated

6 years ago
Blocks: 642753
Duplicate of this bug: 642753

Comment 15

6 years ago
Yeah I think I can fix this with bug 659350
Fixed long ago in bug 659350.
Depends on: 659350

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → WORKSFORME
Whiteboard: [wanted2.1?]
Target Milestone: --- → mozilla9
Resolution: WORKSFORME → FIXED
You need to log in before you can comment on or make changes to this bug.