20713 2013-01-20 12:03:19 +0000 Consider defining window.event and Event.srcElement 2016-09-27 13:35:37 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified All All RESOLVED MOVED blocked on implementers weighing in P2 normal --- 1 Ms2ger annevk bugs bzbarsky mike philipj w3bugs www-dom public-webapps-bugzilla oldest_to_newest 81605 0 Ms2ger 2013-01-20 12:03:19 +0000 See <https://bugzilla.mozilla.org/show_bug.cgi?id=453968>. At least in WebKit, it appears to be identical to Event.target. 81628 1 annevk 2013-01-21 12:11:43 +0000 So what about window.event? 81629 2 annevk 2013-01-21 12:52:15 +0000 ("event" in window) is true in Chrome and in Opera too I believe. Adding event.srcElement without window.event seems risky. 84921 3 annevk 2013-03-25 13:01:54 +0000 SVG also contributes to this: https://bugzilla.mozilla.org/show_bug.cgi?id=854213 85005 4 annevk 2013-03-26 10:22:02 +0000 Chrome is going to investigate removing this: https://code.google.com/p/chromium/issues/detail?id=223749 100499 5 annevk 2014-02-13 11:27:56 +0000 The WindowEvent counter in Chrome was 7.641600241 :-( However, we still haven't added anything to Gecko... 116593 6 philipj 2014-12-19 23:31:21 +0000 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. 116605 7 annevk 2014-12-20 10:01:52 +0000 (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. 116612 8 bugs 2014-12-20 13:29:52 +0000 (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. 116618 9 philipj 2014-12-21 00:57:03 +0000 (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()" 116623 10 annevk 2014-12-21 18:25:59 +0000 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... 116625 11 bugs 2014-12-21 18:29:37 +0000 (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? 116630 12 bzbarsky 2014-12-21 20:18:45 +0000 > 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. 116638 13 philipj 2014-12-22 08:14:44 +0000 (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. 116639 14 philipj 2014-12-22 09:20:25 +0000 (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. 116645 15 bzbarsky 2014-12-22 19:33:16 +0000 > 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. 121781 16 philipj 2015-07-06 09:04:22 +0000 Some things from the Blink bug: https://code.google.com/p/chromium/issues/detail?id=223749 First, the use counter is over 3%: https://www.chromestatus.com/metrics/feature/timeline/popularity/69 That cannot be an accurate estimate of the risk of removing window.event in Blink, so we need better data. Is the only case worth measuring when window.event is non-undefined while accessed from a non-inline event listener, like in this following? x.addEventListener('click', function() { if (event.type == 'foo') bar(); }); Also, I learned that there's a difference between SVG and HTML: https://code.google.com/p/chromium/issues/detail?id=223749#c10 Of the three end states mentioned there, does any seem more worth aiming for, or are there other, better, end states? 121800 17 annevk 2015-07-06 09:37:48 +0000 It's not clear to me what the constraints are on SVG (perhaps both "evt" and "event" can be exposed as variables in the event handler scope?), but I don't think it should have any bearing on whether or not to keep window.event. 121805 18 philipj 2015-07-06 12:21:59 +0000 It does add the risk things like onload="StartAnimation(event)" in SVG into the mix. If we assume that nothing about inline event handlers will change, what kind of data do we need to move this along? To put it another way, what kind of breakage is most likely if Gecko adds window.event and if Blink removes window.event, respectively? I'm still not sure about the connection between Window.event and Event.srcElement, see comment #9. It sounds like IE-sniffing on the form `'event' in window` or `window.event` (inside an event handler) are the main concerns. 121822 19 philipj 2015-07-06 15:19:42 +0000 I found the source of window.event in WebKit/Blink: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/f7067e7d6d17aeece5d8bf4b12b73ae8af7c8f9a """ Discussing with tobias, we found a nice and easy way to implement "window.event". JSEventListener::handleEvent simply sets the event in the Window object, and from there we use Peter's magic (getDOMEvent()). This would fix #30780 if there wasn't a bug in the script itself :( """ The bug was https://bugs.kde.org/show_bug.cgi?id=30780 with reference to this site: http://web.archive.org/web/20010813082633/http://azzuma.com/HTML/antinea.html I don't know if the local binding for inline event listeners existed at the time. All in all, this didn't reveal anything interesting about the compat situation. 127546 20 annevk 2016-09-27 13:35:37 +0000 Now discussing this here together with other Microsoft extensions: https://github.com/whatwg/dom/issues/334.