Last Comment Bug 453968 - Support IE extension Event.srcElement
: Support IE extension Event.srcElement
: dev-doc-needed
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
-- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on:
Blocks: 752800 771949
  Show dependency treegraph
Reported: 2008-09-06 05:09 PDT by henryfhchan
Modified: 2017-02-08 09:14 PST (History)
17 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

List of 4910 JS and HTML URLs from 900 domains that have e.srcElement but no reference (388.00 KB, text/csv)
2012-07-17 14:01 PDT, John Jensen
no flags Details
srcElement-asus.png (362.58 KB, image/png)
2017-02-08 09:14 PST, Mike Taylor [:miketaylr]
no flags Details

Description User image henryfhchan 2008-09-06 05:09:28 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080903034741 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080903034741 Minefield/3.1b1pre

Since firefox already has an added undetectable document.all method, and has had detectable clientWidth clientHeight offsetWidth offsetHeight scrollWidth scrollHeight offsetLeft offsetRight scrollLeft scrollRight (just to name a few properties), why not add more undetectable Proprietary methods/properties?

The escape, find, atob, btab are other methods not found in w3c either.

Reproducible: Always

event.srcElement should just map directly to (I find no problems and no difference in my scripts in IE and Fx if I just swap them over.)
Comment 1 User image Olli Pettay [:smaug] 2008-09-07 08:24:25 PDT
IE's event model is so different comparing to DOM Events that I don't see
real reason to support srcElement. (And IIRC, IE will support DOM Events at some point)
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2008-10-01 21:21:02 PDT
We implemented document.all (which was a major pain, btw) because it was a big compat win.  I don't see that doing srcElement will be nearly as big a win, but perhaps you have data to the contrary?
Comment 3 User image John Jensen 2012-06-01 16:37:33 PDT
Not sure if this helps, but on a whim I today went through my dataset of 1m HTML/JS/CSS urls from the top 25,000 websites on the web, all collected recently using the latest Fennec UA. They were crawled by visiting the home page of each domain and each page in the same domain linked from the home page (ie one level deep).

1,580 of the domains had some Javascript that include the string "event.srcElement".
Comment 4 User image Olli Pettay [:smaug] 2012-06-01 16:39:13 PDT
Note, IE9 supports DOM Events, so there shouldn't be need for this.
Comment 5 User image Mark D. 2012-07-05 11:53:46 PDT
Note: Chrome, Safari, and Opera all support srcElement now.
Comment 6 User image John Jensen 2012-07-17 14:01:29 PDT
Created attachment 643135 [details]
List of 4910 JS and HTML URLs from 900 domains that have e.srcElement but no reference

Please find attached a list of 4910 HTML and Javascript URLs from 900 of the top 18,000 sites on the web that make reference to .srcElement without a nearby reference to .target, implying that the latter is not present. While I can't say for certain that the evidence for each site is 100% conclusive, I can say that I've hand-checked a decent random sample of them.
Comment 7 User image Olli Pettay [:smaug] 2012-07-17 14:41:00 PDT
(In reply to John Jensen from comment #6)
> I can say that I've hand-checked a decent random sample of them.
Meaning what? You've checked that the site doesn't work with FF?
Comment 8 User image John Jensen 2012-07-17 14:48:55 PDT
(In reply to Olli Pettay [:smaug] from comment #7)

> Meaning what? You've checked that the site doesn't work with FF?

 a) there isn't a DOM reference in same portion of JS code to both .srcElement and .target, and
 b) in most cases, that the related functionality doesn't work in Firefox. (In some cases I wasn't able to because my JS knowledge is not good enough to figure out what it was trying to do).

I should add that all data was collected using a very recent Fennec UA (v12 or 13).
Comment 9 User image Olli Pettay [:smaug] 2012-07-17 14:55:37 PDT
Sounds like some very odd mobile-only problem.
It would be sad if we had to add more IE-ism, when IE has itself moved to DOM Events.
There is no specification for srcElement, so we should probably just look at webkit source code
and copy their behavior and hope the best.
But, I'm still against adding srcElement.

(Btw, the original comment mentions few properties and all those are specified in some spec.)
Comment 10 User image Olli Pettay [:smaug] 2012-07-17 15:00:07 PDT
John, have you tried passing some webkit UA string?
Comment 11 User image John Jensen 2012-07-17 15:06:16 PDT
> John, have you tried passing some webkit UA string?

I have a very similar datasets, collected with either the iPhone or stock Android UAs. I can rerun the effort, although my experience with a number of similar issues regarding CSS and UAs tells me the results will not be that different.
Comment 12 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-07-17 17:04:17 PDT
I'd really rather not support another undetectable property. We should definitely look at WebKit and look at what their implementation does. If it simply maps .srcElement to .target then it doesn't seem like a big deal to support.

It's not very surprising that a few "IE-isms" have taken foot hold in the mobile space given how prevalent webkit is there, and how many "IE-isms" are also "webkit-isms". I.e. given how many features webkit has copied from IE.
Comment 13 User image Masatoshi Kimura [:emk] 2012-07-18 02:34:45 PDT
If we add srcElement, maybe we also need to support window.event. I don't think those sites consider the possibility that window.event is absent.
Comment 14 User image Masatoshi Kimura [:emk] 2012-07-18 02:37:53 PDT
And we should propose to spec srcElement instead of imposing reverse-engineering on all implementers.
Comment 15 User image :Ms2ger (⌚ UTC+1/+2) 2013-01-20 04:04:00 PST
srcElement does return the same thing as target in WebKit:

I filed
Comment 16 User image Mike Taylor [:miketaylr] 2016-05-04 09:08:59 PDT
Chrome usage shows this at 9.8%: (but I suspect they're hitting code like `target = event.srcElement ||`.

Some related srcElement bugs (some fixed by evangelism): mentions have busted icons due to srcElement

ni? myself to dig thru our bugs and see how much pain is caused on the window.event side of things (my gut feeling is it's much more than srcElement).
Comment 17 User image Chris Peterson [:cpeterson] 2016-07-12 23:57:29 PDT
Microsoft's "Global CSS Property Usage" dashboard is broken on Firefox because the page uses Event#srcElement.

2) Enter some text in the "Filter properties" field, such as "font".

Expected Behavior:
The list of CSS properties should only show the "font" names. This works correctly in Chrome, Safari, and (unsurprisingly) IE11 and Edge.

Actual Behavior:
Nothing happens on the page. The following JavaScript error is logged to the console:

TypeError: a.srcElement is undefined. usage.4e36d87.js:15:48

which points to the following code in

// As the user types (or clicks the Clear button), perform filtering
i.addEventListener("input",function(a){k(),l(),m(a.srcElement.value)}),n(),window.addEventListener("popstate",n)}}(),/* eslint "strict": [2, "function"] */
Comment 18 User image Karl Dubost :karlcow 2016-07-14 22:04:45 PDT Comment hidden (obsolete)
Comment 19 User image Karl Dubost :karlcow 2016-07-14 22:06:22 PDT
Sorry for closing quickly I thought it was in Tech Evangelism. :)
The issue reported in Comment #17 is fixed.
Comment 20 User image Mike Taylor [:miketaylr] 2017-02-08 09:14:05 PST
Created attachment 8834986 [details]

My ASUS router is complaining about this too.

Note You need to log in before you can comment on or make changes to this bug.