Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #24499
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Newsgroups | comp.lang.javascript |
| Subject | Re: Event target in browsers |
| Date | 2014-05-31 00:07 +0200 |
| Organization | PointedEars Software (PES) |
| Message-ID | <38956158.OWfjujO1v6@PointedEars.de> (permalink) |
| References | (2 earlier) <a8b0e$5388c83f$6def49ce$30211@nntpswitch.blueworldhosting.com> <5388cc48$0$6672$9b4e6d93@newsspool3.arcor-online.net> <28ef9$5388d14c$6def49ce$30712@nntpswitch.blueworldhosting.com> <5437208.zU8Ddvy3tv@PointedEars.de> <5388ea24$0$6669$9b4e6d93@newsspool3.arcor-online.net> |
Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> 2014-05-30 20:22, Christoph Michael Becker wrote:
>>>> <http://www.quirksmode.org/blog/archives/2005/08/addevent_consid.html>
>>>> for details and
>>>> <https://developer.mozilla.org/en-US/docs/Web/API/event.currentTarget#Browser_compatibility>
>>>> for a workaround that may be viable.
>>>
>>> I see there:
>>>
>>> "One solution to emulate the event.currentTarget feature is to wrap your
>>> handler in a function calling the handler using Function.prototype.call
>>> with the element as a first argument. This way, this will be the
>>> expected value."
>>>
>>> I'll take a look at it more closely.
>>
>> Whereas “this” is formatted with a fixed-width font, which is important.
>>
>> Anyhow, I can save you some time here:
>>
>> Note that this argument is based on the assumption that either “this”
>> would always refer to the object that the event handles or that circular
>> references involving host objects would not be a problem in non-W3C-DOM
>> implementations. AISB, the former lacks specification or at the very
>> least
>> some serious testing at this point. The latter has been shown to be
>> false: the FAQ has a long section on the IE Memory Leak issue.
>
> As I understand the MDN article, they suggest something like:
>
> el.attachEvent("onclick", function () {
> (function () {
> // handle the event
> }).call(el);
> });
>
> If I'm not mistaken, this should work as expected (i.e. with "this"
> bound to "el").
And it would create a circular reference involving a host object.
> Regarding the memory leak issue: where is this section in the FAQ? I
> was not able to find it on the start page, nor does it seem to be listed
> in the notes' TOC.
It can be found under “Javascript Closures” for now both in the original FAQ
and the “FAQ for comp.lang.javascript”. The issue arises because closures
are created accidentally, and this creates a circular reference. See below.
> Thanks to your comment in JSX:dom/events.js, I found PPK's article, but
> it is rather old (2005?), and the issue might have been fixed for later
> MSHTML versions.
The point of PPK’s article (which is not entirely correct either, see the
comments) is to avoid addEvent(), a wrapper devised at that time that used
attachEvent() as fallback for addEventListener(). Since both methods work
differently, that is demonstrated not to be a viable approach.
*That* issue was certainly fixed insofar as that Microsoft has finally
deprecated attachEvent() in favor of the W3C DOM API as of IE/MSHTML 9.0,
and removed as of IE/MSHTML 11.0. DOM Level 0 has “this”, and the W3C DOM
provides the “currentTarget” event property, which both make referring to
the handling object by context-external identifier unnecessary.
Googling for “dom events circular reference”, I have found
<http://blogs.msdn.com/b/ben_anderson/archive/2009/02/25/circular-references-no-more.aspx>
in which it is assumed that the memory leak issue has been resolved in IE 8
at least for circular references involving DOM objects.
Since “The Archive Gallery has been retired.” I have found the abstract of
the referred whitepaper in the Internet Archive:
<http://wayback.archive.org/web/20090904193035/http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapers&ReleaseId=578>
In this blog there never has been an update on this. As the link to MSDN in
the whitepaper was dead, too, this lead me to search MSDN Library, where I
finally found
<http://msdn.microsoft.com/en-us/library/dd361842(v=vs.85).aspx>
using “events circular reference” as keywords. It also links to a more
detailed explanation of the problem.
In short, Microsoft states there that they have resolved the memory leak
issue for DOM host objects as of Internet Explorer 8 by treating them like
native JScript objects.
If anyone has done some serious testing on this, I am looking forward to
updating the corresponding section of the “FAQ Notes” in the “FAQ for
comp.lang.javascript”.
--
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Event target in browsers Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-05-29 20:03 +0200
Re: Event target in browsers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-29 22:35 +0200
Re: Event target in browsers Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-30 13:26 +0200
Re: Event target in browsers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-30 14:31 +0200
Re: Event target in browsers Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-30 17:50 +0200
Re: Event target in browsers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-01 22:19 +0200
Re: Event target in browsers Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-05-30 20:04 +0200
Re: Event target in browsers Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-30 20:22 +0200
Re: Event target in browsers Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-05-30 20:43 +0200
Re: Event target in browsers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-30 21:47 +0200
Re: Event target in browsers Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-30 22:29 +0200
Re: Event target in browsers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-31 00:07 +0200
Re: Event target in browsers Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-02 14:53 +0200
Re: Event target in browsers Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-02 21:41 +0200
Re: Event target in browsers Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-30 21:38 +0200
csiph-web