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 event.target (I find no problems and no difference in my scripts in IE and Fx if I just swap them over.)
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)
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?
Note, IE9 supports DOM Events, so there shouldn't be need for this.
Note: Chrome, Safari, and Opera all support srcElement now.
(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?
(In reply to Olli Pettay [:smaug] from comment #7) > Meaning what? You've checked that the site doesn't work with FF? That 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).
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.)
John, have you tried passing some webkit UA string?
> 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.
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.
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.
And we should propose to spec srcElement instead of imposing reverse-engineering on all implementers.
srcElement does return the same thing as target in WebKit: http://mxr.mozilla.org/chromium/source/src/third_party/WebKit/Source/WebCore/dom/Event.h#114 I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20713
Chrome usage shows this at 9.8%: https://www.chromestatus.com/metrics/feature/timeline/popularity/343 (but I suspect they're hitting code like `target = event.srcElement || event.target`. Some related srcElement bugs (some fixed by evangelism): https://github.com/webcompat/web-bugs/issues/705 https://github.com/webcompat/web-bugs/issues/1090 https://bugzilla.mozilla.org/show_bug.cgi?id=1117220#c1 https://bugzilla.mozilla.org/show_bug.cgi?id=1107378#c6 mentions m.taobao.com 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).
Sorry for closing quickly I thought it was in Tech Evangelism. :) The issue reported in Comment #17 is fixed.
5 months ago
Created attachment 8834986 [details] srcElement-asus.png My ASUS router is complaining about this too.
(In reply to Mike Taylor [:miketaylr] from comment #20) > Created attachment 8834986 [details] > srcElement-asus.png > > My ASUS router is complaining about this too. I like that your search term was "asus router ip" :)
bumping because MDN claims this will never be supported by Firefox, and this thread was never resolved.
> MDN claims this will never be supported by Firefox MDN can be wrong. :) This is waiting on some spec work, which is in progress. At that point it'll be up to DOM to prioritize.
P2 means "in a month or three we'll re-evaluate if we can do this very soon (P1) or if it just gets into the bigger prioritization bucket (P3)"
(In reply to alex.m.sheehan from comment #22) > bumping because MDN claims this will never be supported by Firefox, and this > thread was never resolved. Can you point me to the page where we say "never"? Things can change, so that's not very useful language to use; I'm happy to change it.
Sorry, the combination of the "Non-standard" warning, and the fact that this thread is so old, and FF has no support for it led me to the scathing accusation :) https://developer.mozilla.org/en-US/docs/Web/API/Event/srcElement