Bug 20713 - Consider defining window.event and Event.srcElement
Consider defining window.event and Event.srcElement
Status: NEW
Product: WebAppsWG
Classification: Unclassified
Component: DOM
unspecified
All All
: P2 normal
: ---
Assigned To: Anne
public-webapps-bugzilla
blocked on implementers weighing in
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-20 12:03 UTC by Ms2ger
Modified: 2014-12-22 19:33 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ms2ger 2013-01-20 12:03:19 UTC
See <https://bugzilla.mozilla.org/show_bug.cgi?id=453968>. At least in WebKit, it appears to be identical to Event.target.
Comment 1 Anne 2013-01-21 12:11:43 UTC
So what about window.event?
Comment 2 Anne 2013-01-21 12:52:15 UTC
("event" in window) is true in Chrome and in Opera too I believe. Adding event.srcElement without window.event seems risky.
Comment 3 Anne 2013-03-25 13:01:54 UTC
SVG also contributes to this: https://bugzilla.mozilla.org/show_bug.cgi?id=854213
Comment 4 Anne 2013-03-26 10:22:02 UTC
Chrome is going to investigate removing this: https://code.google.com/p/chromium/issues/detail?id=223749
Comment 5 Anne 2014-02-13 11:27:56 UTC
The WindowEvent counter in Chrome was 7.641600241 :-( However, we still haven't added anything to Gecko...
Comment 6 Philip Jägenstedt 2014-12-19 23:31:21 UTC
Event.srcElement is around 20%:
https://www.chromestatus.com/metrics/feature/timeline/popularity/343

It's just an alias of target, so adding that seems like the only way to go.

Window.event is around 4% now:
https://www.chromestatus.com/metrics/feature/timeline/popularity/69

https://code.google.com/p/chromium/issues/detail?id=223749#c3 says that "Inline event handlers have a local `event` binding in scope." but I'm not sure if that's how it works in Blink. However it works, stuff like onclick="event.target.style.color='red'" has to work.
Comment 7 Anne 2014-12-20 10:01:52 UTC
(In reply to Philip Jägenstedt from comment #6)
> Event.srcElement is around 20%:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/343
> 
> It's just an alias of target, so adding that seems like the only way to go.

This seems very similar to the isSameNode() situation as Mozilla never added it. If Mozilla wants to add this, we should probably define it, along with window.event as I believe they cannot be decoupled.


> Window.event is around 4% now:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/69
> 
> https://code.google.com/p/chromium/issues/detail?id=223749#c3 says that
> "Inline event handlers have a local `event` binding in scope." but I'm not
> sure if that's how it works in Blink. However it works, stuff like
> onclick="event.target.style.color='red'" has to work.

event.target can work by putting that in the local scope, you don't need a global property for that to work per se.
Comment 8 Olli Pettay 2014-12-20 13:29:52 UTC
(In reply to Anne from comment #7)
> (In reply to Philip Jägenstedt from comment #6)
> > Event.srcElement is around 20%:
> > https://www.chromestatus.com/metrics/feature/timeline/popularity/343
> > 
> > It's just an alias of target, so adding that seems like the only way to go.
> 
> This seems very similar to the isSameNode() situation as Mozilla never added
> it. If Mozilla wants to add this, we should probably define it, along with
> window.event as I believe they cannot be decoupled.

I haven't heard recently anyone asking us to add  window.event or Event.srcElement.
I'd expect adding window.event to actually break things (when using Gecko), since at least at some point there were pages doing 
if (window.event) {
  // some more IE-style stuff
}
Not sure how blink copes with that.
Comment 9 Philip Jägenstedt 2014-12-21 00:57:03 UTC
(In reply to Anne from comment #7)
> (In reply to Philip Jägenstedt from comment #6)
> > Event.srcElement is around 20%:
> > https://www.chromestatus.com/metrics/feature/timeline/popularity/343
> > 
> > It's just an alias of target, so adding that seems like the only way to go.
> 
> This seems very similar to the isSameNode() situation as Mozilla never added
> it. If Mozilla wants to add this, we should probably define it, along with
> window.event as I believe they cannot be decoupled.

What's the connection between Window.event and Event.srcElement other than being IE-isms?

> > Window.event is around 4% now:
> > https://www.chromestatus.com/metrics/feature/timeline/popularity/69
> > 
> > https://code.google.com/p/chromium/issues/detail?id=223749#c3 says that
> > "Inline event handlers have a local `event` binding in scope." but I'm not
> > sure if that's how it works in Blink. However it works, stuff like
> > onclick="event.target.style.color='red'" has to work.
> 
> event.target can work by putting that in the local scope, you don't need a
> global property for that to work per se.

It looks like window.event is undefined in Blink/WebKit/IE when no event is firing, but 'event' in window is always true. What does it mean to put event in the local scope? Something like "arguments" in function calls?

I have no data to back this up, but it seems wise to ensure that this works:

function handle() {
  event.target.style.color = 'red';
}

onclick="handle()"
Comment 10 Anne 2014-12-21 18:25:59 UTC
I think it means that if you lookup "event" that it's found on the environment record. So yes, that example should work. As for srcElement and window.event, I remember a conclusion that they were coupled based on some examination of code. Perhaps that changed...
Comment 11 Olli Pettay 2014-12-21 18:29:37 UTC
(In reply to Philip Jägenstedt from comment #9)
> I have no data to back this up, but it seems wise to ensure that this works:

Why it would be wise?
Comment 12 Boris Zbarsky 2014-12-21 20:18:45 UTC
> So yes, that example should work.

Why would it?  It doesn't work in Gecko, and we have no evidence that the web depends on it.

I share Olli's concern about adding window.event.  I expect it's common for people to pull in other nonstandard stuff that IE had and WebKit copied if that's defined.

I have some questions about the data here, though.

> Event.srcElement is around 20%:

How many of those are:

  var target = event.srcElement || event.target;

?

> Window.event is around 4% now:

Again, do we have any data on what the uses look like?

> This seems very similar to the isSameNode()

No, it's very different, because we know for a fact people use at least window.event for browser detection, so implementing it in Gecko carries huge compat risks which are not present with implementing isSameNode.
Comment 13 Philip Jägenstedt 2014-12-22 08:14:44 UTC
(In reply to Olli Pettay from comment #11)
> (In reply to Philip Jägenstedt from comment #9)
> > I have no data to back this up, but it seems wise to ensure that this works:
> 
> Why it would be wise?

It's a mutation of the code in comment #6 that seems almost certain to have happened. If others don't share that hunch, then we'd need actual data.
Comment 14 Philip Jägenstedt 2014-12-22 09:20:25 UTC
(In reply to Boris Zbarsky from comment #12)
> > So yes, that example should work.
> 
> Why would it?  It doesn't work in Gecko, and we have no evidence that the
> web depends on it.
> 
> I share Olli's concern about adding window.event.  I expect it's common for
> people to pull in other nonstandard stuff that IE had and WebKit copied if
> that's defined.

Which specific other IE-isms are you concerned about? We should either standardize or remove them, and if deemed necessary due to entanglement they could be done in a batch.

> I have some questions about the data here, though.
> 
> > Event.srcElement is around 20%:
> 
> How many of those are:
> 
>   var target = event.srcElement || event.target;
> 
> ?
>
> > Window.event is around 4% now:
> 
> Again, do we have any data on what the uses look like?

The use counter data can't answer either of these questions. My only idea for answering questions like these would be to check how often Event.srcElement but not Event.target is accessed in a script run (event handler, setTimeout, etc.) Even that wouldn't be conclusive, so I haven't tried to add the scaffolding to make it possible.
Comment 15 Boris Zbarsky 2014-12-22 19:33:16 UTC
> It's a mutation of the code in comment #6 that seems almost certain to have
> happened.

It has, in the past, but it's common knowledge that this doesn't work in Firefox, so people are a bit more careful now.

> Which specific other IE-isms are you concerned about?

I've seen people assume all sorts of things if window.event over the years.  What they assume right now is something we'd need data on.

> We should either standardize or remove them

Sounds nice, depending on what they are.  Just watch out for the assumptions being ones we can't do either one with, like some of the irreconcilable differences in ES behavior (e.g. around handling of function declarations inside conditionals).

What's needed is data.  Assuming we want to go in this direction, of course.  It may actually be simpler to remove window.event from all UAs than to get sufficient data on what breaks if it's added and what other crud then has to become part of the web platform forever.

Note that we haven't even started the conversation about what behavior window.event should have, which is not at all obvious to me either.