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

Groups > comp.lang.javascript > #24463 > unrolled thread

Event target in browsers

Back to article view | Back to comp.lang.javascript

Contents

  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

#24463 — Event target in browsers

I have a example:

[HTML - fragment]
<button id="btn" type="submit" name="example" value="0">
     <img id="image" alt="Feed icon" 
src="http://www.ctomczyk.pl/wp-content/themes/ct/images/icoFeed.png" />
</button>
<div id="log"></div>

[Client-side script]

var el = document.getElementById('btn'),
     elLog = document.getElementById('log');

function getEventTarget(e) {
     var target = e.target;
     if (target) {
         if (target.nodeType !== 1) {
             target = target.parentNode;
         }
     } else {
         target = e.srcElement;
     }
     return target;
}

function getElementNodeName(el) {
     var nn = 'unknown';

     if (el.tagName) {
         nn = el.tagName;
     } else if (el.nodeName) {
         nn = el.nodeName;
     }

     return nn.toLowerCase();
}

function listener(e) {
     var tar = getEventTarget(e);
     if (getElementNodeName(tar) === 'img') {
         tar = tar.parentNode;
     }
     elLog.innerHTML = getElementNodeName(tar);
}


el.addEventListener('click', listener, false);

Working above example: http://jsfiddle.net/GnH8d/3/

In Firefox 29.0.1 and IE 11 I am getting as a target HTML "button" 
element, but in Chrome 35.0.1916.114 m I am getting HTML "img" element.

Because I want to get target as a HTML "button" element I've applied 
"if" statement "if (getElementNodeName(tar) === 'img')" just to check if 
the target is "button", not "img".

My understand is because different browsers implementing different way 
how the events works.
http://www.w3.org/wiki/Handling_events_with_JavaScript#How_events_work

Is my approach correct?

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [next] | [standalone]

#24465

Cezary Tomczyk wrote:

> <button id="btn" type="submit" name="example" value="0">
>      <img id="image" alt="Feed icon" […] />
> </button>
> […]
> var el = document.getElementById('btn') […];
> 
> function getEventTarget(e) {
>      var target = e.target;
>      if (target) {
>          if (target.nodeType !== 1) {
>              target = target.parentNode;
>          }
>      } else {
>          target = e.srcElement;
>      }
>      return target;
> }
> 
> function getElementNodeName(el) {
>      var nn = 'unknown';
> 
>      if (el.tagName) {
>          nn = el.tagName;
>      } else if (el.nodeName) {
>          nn = el.nodeName;
>      }
> 
>      return nn.toLowerCase();
> }
> 
> function listener(e) {
>      var tar = getEventTarget(e);
>      if (getElementNodeName(tar) === 'img') {
>          tar = tar.parentNode;
>      }
>      […]
> }
> 
> el.addEventListener('click', listener, false);
> […]
> In Firefox 29.0.1 and IE 11 I am getting as a target HTML "button"
> element, but in Chrome 35.0.1916.114 m I am getting HTML "img" element.
> […]
> My understand is because different browsers implementing different way
> how the events works.
> http://www.w3.org/wiki/Handling_events_with_JavaScript#How_events_work
> 
> Is my approach correct?

No.  The “click” event bubbles in all DOM implementations, and 
getElementNodeName() is overkill.

getEventTarget() does not work because where only “srcElement” is available, 
the reference to the event object is _not_ passed as first argument to the 
listener (IE/MSHTML < 9 or Compatibility Mode in IE 9), and “window.event” 
must be accessed instead.  But since EventTarget::addEventListener() is not 
implemented in the latter case, and you would not want to augment host 
objects, getEventTarget() is superfluous.

As you are relying on the W3C DOM API already, just use “currentTarget” 
instead of “target”.  (Works in Chromium 34.  I need NSAPI plugin support, 
so I cannot test in Chromium 35 for the time being.)

<http://www.w3.org/TR/2014/CR-dom-20140508/#interface-event>

-- 
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.

[toc] | [prev] | [next] | [standalone]

#24471

Thomas 'PointedEars' Lahn wrote:

> As you are relying on the W3C DOM API already, just use “currentTarget” 
> instead of “target”.  (Works in Chromium 34.  I need NSAPI plugin support, 
> so I cannot test in Chromium 35 for the time being.)

I can confirm that the currentTarget property works as expected in
Chrome 35.0.1916.114 m.

Another alternative might be to use "this", as that should be bound to
the current target by default, if I'm not mistaken.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24474

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> As you are relying on the W3C DOM API already, just use “currentTarget”
>> instead of “target”.  (Works in Chromium 34.  I need NSAPI plugin
>> support, so I cannot test in Chromium 35 for the time being.)
> 
> I can confirm that the currentTarget property works as expected in
> Chrome 35.0.1916.114 m.
> 
> Another alternative might be to use "this", as that should be bound to
> the current target by default, if I'm not mistaken.

In Chromium 34 it does, and it did in all previous W3C DOM-enabled browsers 
AFAICR, so although I am not aware of a standard saying this, at least it is 
a quasi-standard (probably derived from DOM Level 0).  You can test it thus:

  document.body.addEventListener("click", function (e) {
    console.log(e, e.target, e.currentTarget, this);
  }, false);

Then primary-click anywhere within the viewport (preferably not on a 
navigating widget unless you keep the log then).

It should be noted that logging the value of “e” does not give you the 
correct value of the “currentTarget” property in Chromium 34: expanding the 
object display shows “currentTarget” and various other properties to be 
“null” even though they are not.

OTOH, the object display indicates that Chromium WebCore now also implements 
formerly MSHTML-specific properties like “srcElement”.  The differences 
apparently gradually disappearing, this supports my approach of shallow-
copying event properties to a user-defined object through 
jsx.dom.createEventListener() when necessary, instead of others’ approach of 
calling user-defined methods from the event listener to sort out the DOM 
differences on specific occasion.  Because with my approach it is possible 
to just stop using the wrapper and continue without modifying the listener 
code.  (See <http://PointedEars.de/wsvn/JSX/trunk/dom/events.js> for 
details.)

-- 
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.

[toc] | [prev] | [next] | [standalone]

#24482

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>
>> Another alternative might be to use "this", as that should be bound to
>> the current target by default, if I'm not mistaken.
> 
> In Chromium 34 it does, and it did in all previous W3C DOM-enabled browsers 
> AFAICR, so although I am not aware of a standard saying this, at least it is 
> a quasi-standard (probably derived from DOM Level 0).  You can test it thus:
> 
>   document.body.addEventListener("click", function (e) {
>     console.log(e, e.target, e.currentTarget, this);
>   }, false);
> 
> Then primary-click anywhere within the viewport (preferably not on a 
> navigating widget unless you keep the log then).

However, testing on all browsers that one wants to support is difficult. :(

> It should be noted that logging the value of “e” does not give you the 
> correct value of the “currentTarget” property in Chromium 34: expanding the 
> object display shows “currentTarget” and various other properties to be 
> “null” even though they are not.

Chrome 35.0.1916.114 m shows the same irritating behavior.

> OTOH, the object display indicates that Chromium WebCore now also implements 
> formerly MSHTML-specific properties like “srcElement”.  The differences 
> apparently gradually disappearing, this supports my approach of shallow-
> copying event properties to a user-defined object through 
> jsx.dom.createEventListener() when necessary, instead of others’ approach of 
> calling user-defined methods from the event listener to sort out the DOM 
> differences on specific occasion.  Because with my approach it is possible 
> to just stop using the wrapper and continue without modifying the listener 
> code.  (See <http://PointedEars.de/wsvn/JSX/trunk/dom/events.js> for 
> details.)

Interesting.  I wonder if it would be possible to avoid using the
wrapper function listener() for browsers already supporting the W3C
event model.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24529

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
> 
> […] testing on all browsers that one wants to support is difficult.
> :(

There are no guarantees in this field.  Code that works here today may break 
elsewhere or tomorrow.  One can only write code as robust as reasonably 
possible so that it is less likely to break there or then.
 
>> OTOH, the object display indicates that Chromium WebCore now also
>> implements formerly MSHTML-specific properties like “srcElement”.  The
>> differences apparently gradually disappearing, this supports my approach
>> of shallow-copying event properties to a user-defined object through
>> jsx.dom.createEventListener() when necessary, instead of others’ approach
>> of calling user-defined methods from the event listener to sort out the
>> DOM differences on specific occasion.  Because with my approach it is
>> possible to just stop using the wrapper and continue without modifying
>> the listener code.  (See
>> <http://PointedEars.de/wsvn/JSX/trunk/dom/events.js> for
>> details.)
> 
> Interesting.  I wonder if it would be possible to avoid using the
> wrapper function listener() for browsers already supporting the W3C
> event model.

The general idea of jsx.dom.createEventListener() is that if your listener 
code is written to the W3C DOM Events API and you are sure that your target 
environments support that, you do not need to call it.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#24486

2014-05-29 22:35, Thomas 'PointedEars' Lahn wrote:
[...]
>> Is my approach correct?
>
> No.  The “click” event bubbles in all DOM implementations, and
> getElementNodeName() is overkill.
>
> getEventTarget() does not work because where only “srcElement” is available,
> the reference to the event object is _not_ passed as first argument to the
> listener (IE/MSHTML < 9 or Compatibility Mode in IE 9), and “window.event”
> must be accessed instead.  But since EventTarget::addEventListener() is not
> implemented in the latter case, and you would not want to augment host
> objects, getEventTarget() is superfluous.

True, I forgot about "window.event" for IE < 9. For browsers that do not 
support "currentTarget" Christoph mention about solution, also I'll take 
a look at http://pointedears.de/wsvn/JSX/trunk/dom/events.js.

> As you are relying on the W3C DOM API already, just use “currentTarget”
> instead of “target”.  (Works in Chromium 34.  I need NSAPI plugin support,
> so I cannot test in Chromium 35 for the time being.)
>
> <http://www.w3.org/TR/2014/CR-dom-20140508/#interface-event>

That simplifying everything. Thank you. This is exactly what I wanted. 
Plus, I'll remove getEventTarget(). It's not needed.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#24490

Cezary Tomczyk wrote:

> 2014-05-29 22:35, Thomas 'PointedEars' Lahn wrote:
> [...]
>>> Is my approach correct?
>>
>> No.  The “click” event bubbles in all DOM implementations, and
>> getElementNodeName() is overkill.
>>
>> getEventTarget() does not work because where only “srcElement” is
>> available,
>> the reference to the event object is _not_ passed as first argument to
>> the
>> listener (IE/MSHTML < 9 or Compatibility Mode in IE 9), and
>> “window.event”
>> must be accessed instead.  But since EventTarget::addEventListener()
>> is not
>> implemented in the latter case, and you would not want to augment host
>> objects, getEventTarget() is superfluous.
> 
> True, I forgot about "window.event" for IE < 9. For browsers that do not
> support "currentTarget" Christoph mention about solution, also I'll take
> a look at http://pointedears.de/wsvn/JSX/trunk/dom/events.js.

If you are referring to my comment regarding "this", be aware that this
will not work for IE/MSHTML < 9.  See
<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.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24491

2014-05-30 20:22, Christoph Michael Becker wrote:
> Cezary Tomczyk wrote:
[...]
>> True, I forgot about "window.event" for IE < 9. For browsers that do not
>> support "currentTarget" Christoph mention about solution, also I'll take
>> a look at http://pointedears.de/wsvn/JSX/trunk/dom/events.js.
>
> If you are referring to my comment regarding "this", be aware that this
> will not work for IE/MSHTML < 9.  See

Yes, I was referring to your comment.

Plus, I am not sure if I still should support browser that do not 
provide currentTarget (e.g. IE < 9), but that is another story.

> <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.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#24494

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.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#24496

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").

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.

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.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24499

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.

[toc] | [prev] | [next] | [standalone]

#24536

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
> 
>> 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.

ACK.  However, with "this issue" I was referring to the mentioned memory
leaks.  I should have been more clear.

> 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.

Thanks for your thourough investigation.  I had heard of these memory
leaks, but I wondered how they could happen.  Now I understand the issue
better.

> 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”.

I will not be able to do some serious testing, unfortunately.  But I
made some rough tests with function leaktest1()[1], which confirmed
memory leaks in IE 6 and 7 (JScript 5.6.8820 resp. 5.7.5730), while I
was not able to find memory leaks in IE 8 and 11 (JScript 5.8.23141
resp. 11.0.17041).

It would be interesting to know which other browser versions are
affected (Ben Anderson mentionend similar problems in early versions of
Firefox[2]).

[1] <http://msdn.microsoft.com/en-us/library/dd361842(v=vs.85).aspx>
[2]
<http://blogs.msdn.com/b/ben_anderson/archive/2009/02/25/circular-references-no-more.aspx>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24582

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
> 
>> 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”.
> 
> I will not be able to do some serious testing, unfortunately.  But I
> made some rough tests with function leaktest1()[1], which confirmed
> memory leaks in IE 6 and 7 (JScript 5.6.8820 resp. 5.7.5730), while I
> was not able to find memory leaks in IE 8 and 11 (JScript 5.8.23141
> resp. 11.0.17041).
> 
> It would be interesting to know which other browser versions are
> affected (Ben Anderson mentionend similar problems in early versions of
> Firefox[2]).
> 
> [1] <http://msdn.microsoft.com/en-us/library/dd361842(v=vs.85).aspx>
> [2]
> <http://blogs.msdn.com/b/ben_anderson/archive/2009/02/25/circular-references-no-more.aspx>

FWIW: Another article about the memory leak issue:
<http://javascript.crockford.com/memory/leak.html>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24492

Christoph Michael Becker wrote:

> Cezary Tomczyk wrote:
>> True, I forgot about "window.event" for IE < 9. For browsers that do not
>> support "currentTarget" Christoph mention about solution, also I'll take
>> a look at http://pointedears.de/wsvn/JSX/trunk/dom/events.js.
> 
> If you are referring to my comment regarding "this", be aware that this
> will not work for IE/MSHTML < 9.

It will work there, but …

> See
> <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.

… not if you use the MSHTML-proprietary attachEvent().  So you are better 
off not calling that method.  See also the comment in JSX:dom/events.js.

-- 
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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web