Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #24499

Re: Event target in browsers

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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