601002 - `'onpopstate' in window` returns false (should be true)

Status: RESOLVED DUPLICATE of bug 414853

(Core :: DOM: Core & HTML, defect)

Description

[Ryan Grove]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.24 Safari/534.7
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

Firefox 4 supports the HTML5 onpopstate event, but it's difficult to detect that the event is supported, since `'onpopstate' in window` returns false.

Reproducible: Always

Steps to Reproduce:
1. Execute the following JavaScript: if ('onpopstate' in window) { alert('yay'); } else { alert('poo'); }

Actual Results:  
A "poo" alert is displayed.

Expected Results:  
A "yay" alert should be displayed, since Firefox 4 supports the onpopstate event.

Since `'onhashchange' in window` returns true, I would expect the onpopstate test to return true as well.

`'onpopstate' in window` returns true in Safari 5 and Google Chrome 6 and 7 (I didn't test earlier versions of either).

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Since `'onhashchange' in window` returns true

onhashchange is special-cased.  See bug 504220

Do we want to do the same special-casing for onpopstate?  Or is this just a duplicate of bug 414853?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'd say dupe of bug 414853 (or depend on it). The reason we did onhashchange special was that there was to enable feature detection of that feature. With the history API you can easily check "if ('pushState' in window) {"

Comment 3

[Justin Lebar (not reading bugmail)]

Ugh.  Yes, this is a dupe.  Maybe bz can talk me out of it, but I'm not convinced that we don't want to fix bug 414853.  Given that we want people to use |'onhashchange' in window| to detect that event, the fact that we don't export other events there seems to violate the principle of least surprise.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> but I'm not convinced that we don't want to fix bug 414853

We definitely want to fix it; it's a spec bug (see bug 414853 comment 2).  Or do you mean "drop everything else and fix it for 2.0"?

Comment 5

[Justin Lebar (not reading bugmail)]

(In reply to comment #4)
> We definitely want to fix it; it's a spec bug (see bug 414853 comment 2).  Or
> do you mean "drop everything else and fix it for 2.0"?

Oh, I see.  Definitely the former.  :)