A shared implementation with the W3C methods is possible.
attatchEvent("onload",functionRef) is 100% equivalent to addEventListener
("load",functionRef,false) for instance
Fixing this would fix bug 8534.
<http://www.quirksmode.org/blog/archives/2005/08/addevent_consid.html>: "addEventListener and attachEvent should not be considered equal".
This talks about the meaning of "this" keyword; looking at the documentation, the bubbling/canceling traits of similar IE and W3C events are also different.
We don't need to implement attachEvent and detachEvent in order to support live.com or start.com since the Mozilla compat layer is used which provides implementations of those functions
This is one of those areas I'm nervous about supporting.
If we added support for this, there are sites that would take us down the IE event handling code path. I'd rather wait to see if this is a real-world problem before adding support for it.
Couldn't this take the same approach as the hidden document.all support?
Support it if its used, but not if its tested for directly:
site does window.attachEvent("load",function); // Works
site does if( window.attachEvent ) window.attachEvent("load",function); // Doesn't, since window.attachEvent is "hidden".
here's a real website (popular in the alexa rankings) that depends on attachEvent:
granted, it uses attachEvent to scroll some advertisements as you scroll the page!
Well noted. Should we have a keyword to mark bugs that affect sites which are popular in the Alexa rankings?
Also, is there any way to quantify the risk of sites giving us the IE-compatibility event handling code path that Hyatt mentioned? I would hope most sites would use addEventListener in preference to attachEvent when both are available, but it's hard to be certain.
As a side note, I believe Opera supports the IE event handling methods.
(In reply to comment #9)
> Also, is there any way to quantify the risk of sites giving us the
> IE-compatibility event handling code path that Hyatt mentioned?
It seems that testing for attachEvent is a very common way to detect IE, so it clearly needs to be invisible if implemented. See, for example, <http://dev.rubyonrails.org/ticket/6800>.
The left navigation panel of the MSDN site requires attachEvent/detachEvent:
I don't understand the last comment -- Firefox doesn't support attachEvent(), and both Safari and Firefox are given attachEvent proxies in the aforementioned compat layer.
(In reply to comment #12)
> I don't understand the last comment -- Firefox doesn't support attachEvent(),
> and both Safari and Firefox are given attachEvent proxies in the aforementioned
> compat layer.
(In reply to comment #13)
> (In reply to comment #12)
> > I don't understand the last comment -- Firefox doesn't support attachEvent(),
> > and both Safari and Firefox are given attachEvent proxies in the aforementioned
> > compat layer.
> Perhaps the compat layer is not being activated with Safari 3, then.
And this would be Bug 13546!
Another example of site using this:
This is top 7th bank in China. Log in with IE from https://personal.bank.ecitic.com:444 (you need an account though)
(In reply to comment #9)
> As a side note, I believe Opera supports the IE event handling methods.
We are in the process of removing support for these.
Can this bug be closed since even IE11 dropped the support for "attachEvent" in 2013 (release date) and now IE11 is also getting marked as EOL / EOS tomorrow (based on my timezone).
Yeah, this is "won't fix"