Re: IE leaks, circular references, addevent et al

On Sep 19, 3:56 pm, kangax <kan...@xxxxxxxxx> wrote:
David Mark wrote:
On Sep 18, 3:41 pm, kangax <kan...@xxxxxxxxx> wrote:
David Mark wrote:
On Sep 17, 10:53 pm, kangax <kan...@xxxxxxxxx> wrote:
David Mark wrote:
On Sep 17, 10:18 pm, kangax <kan...@xxxxxxxxx> wrote:
[...]
For example, `attachListener` delegates to
`addNormalizedListener` which in turn calls `getTargetId` which then
assigns unique "uniqueID" to an element (if not yet present) via
`elementUniqueId` method.
Yes and this is not a good practice.
I know. However, avoiding this practice seems to make things much harder
(and some things - even impossible).

I recently stumbled upon a post by Zakas, where he gives a solution to

Who?

http://www.nczonline.net/

"Professional JavaScript" author

I see.


[...]

This is seemingly a more robust way. The downside here (and is my actual
point) is that if `iframe` element doesn't support "readystatechange"
event in some client, assignment to that "onreadystatechange" property
is essentially a host object augmentation. It's no different than
`iframe.foo = function(){ ... }` or `iframe._uniqueId = '_id12345'`.

Isn't it?

That's correct, but are you planning to use DOM0?

Well, obviously this is only an issue with using DOM0 (whether
explicitly or if `addEvent` abstraction falls back to it after not
finding anything better in some crippled clients).

My point is that "augmenting host object" has somewhat blurry
definition. We all understand that assigning "_foobar" property to an
element is not a good idea; yet we assign event handler properties not
knowing whether client does in fact support corresponding events.

Do we?

http://thinkweb2.com/projects/prototype/detecting-event-support-without-browser-sniffing/



For
all we know, such property (e.g. `oncontextmenu`) can be no better that
`_foobar` one and can lead to all the same consequences.

I wouldn't blindly assign to that particular property.




[...]

but I
don't understand:
1) Why any target that has falsy `tagName` gets special treatment and is
injected with unique `"_api" + uniqueTargetHandle`
Because I was avoiding expandos in IE by using their built-in unique
identifier, which doesn't work at all for document objects.  All could
have been avoided, of course.
Understood.

One thing you could do is use the DOM0 properties to stash the
normalized listeners (or a handle that points to them).  Then you are
just augmenting a Function object.

Do you mean something along:

function f(){};
f._handlerId = _handlerId++;
someElement.onclick = f;

Something like that.


[...]

I don't think
having `addEvent` which behaves differently in W3C browsers and IE is a
good idea.

Why not?  They goal is not to emulate addEventListener exactly, but to
provide an API for attaching and detaching listeners.  None of this
really matters though as you can keep the duplicate detection in
without using expandos.

Yep. There's a fine range of ways to implement `addEvent` abstraction.
Some features simply lead to more fragile implementation.



If we were to choose a particular set of traits for event handling
mechanism, than we might as well drop not only duplicate handling, but
`this` normalization too (which would prevent leaks handling in the
first place) :)

The leak problem has been solved a ways back and did not involve
expandos.  Setting - this - is definitely a useful feature, but not
always needed.  It always comes back to the context.

Yes, it always does.

[...]

and clearly it is because the design was trying to do too much.
Surely there is a happy medium between that and requiring an ID for
every node (and how would that work for documents and windows anyway?)
Determine that object is a `window`, then store it as a reference in
array of such `window` objects? Later, that array can be iterated over
in order to determine `id` of a given `window` object.

Not sure if it's a good idea and how practical it is, though.

I wouldn't bother to write such a wrapper for window objects.  ;)

Sure. Supporting multiple contexts is like supporting quirksmode or xhtml..

Certainly for attaching listeners to window objects.




3) Whether you had any problems with all this host objects augmentation
in any environment.
Not that I kmow of.  Of course, I never used my library.  ;)  I do
But tested on a variety of clients nevertheless, right?

Yes.  By myself two years ago and many others since.  Doesn't prove
much though.  Expandos are still ill-advised.

If you're interested, I noticed that some things might fail in older
Safari (e.g. 2.0) due to missing `compatMode` there, which seems to be
used in `getContainerElement`. You need to feature test quirks mode when
`compatMode` is missing (so that code doesn't erroneously fall into
`body-acting-as-root` mode).

This?

// Result is ambiguous in all but modern browsers, so don't assume too
much from it.
getContainerElement = function(docNode) {
docNode = docNode || global.document;
return (docNode.documentElement && (!docNode.compatMode ||
docNode.compatMode.indexOf('CSS') != -1))?
docNode.documentElement:getBodyElement(docNode);
};

See the comment. :)

If you look at the library code, it doesn't assume much from this
(e.g. the result doesn't necessarily house the scroll* properties).
It's a function that could (and probably should) be factored out as
its presence confuses more than it clears up.


IIRC, one of the snippets in Cornford's "not browser detect" article
uses `compatMode` without test as well.

Probably for measuring the viewport. Richard published a really nice
(and involved) version of that at one point. I'm sure it didn't
assume much from compatMode (or the lack thereof).

One thing you can look at for the viewport measurement is if
documentElement.clientWidth === 0. That's a browser that doesn't
render the documentElement at all (e.g. IE < 6). I still wouldn't
assume the scroll* properties are on that object though (they are in
IE, of course).
.

Relevant Pages

  • Re: IE leaks, circular references, addevent et al
    ... We all understand that assigning "_foobar" property to an element is not a good idea; yet we assign event handler properties not knowing whether client does in fact support corresponding events. ... array of such `window` objects? ... If you're interested, I noticed that some things might fail in older Safari due to missing `compatMode` there, which seems to be used in `getContainerElement`. ... You need to feature test quirks mode when `compatMode` is missing. ...
    (comp.lang.javascript)
  • Re: IE leaks, circular references, addevent et al
    ... knowing whether client does in fact support corresponding events. ... array of such `window` objects? ... Safari due to missing `compatMode` there, ... viewport measurement stuff uses a wrapper for getContainerElement. ...
    (comp.lang.javascript)
  • Re: send page to OE
    ... browsers but the one thing keeping me with IE is when I choose Send ... browsers can't seem to send the webpage to the OE message window. ... it's whatever email client that is used to send. ... to tell the OS or OE to put the web page into the Message Composition ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: send page to OE
    ... browsers but the one thing keeping me with IE is when I choose Send ... browsers can't seem to send the webpage to the OE message window. ... it's whatever email client that is used to send. ... to tell the OS or OE to put the web page into the Message Composition ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: Rem Desktop conflict with Interactive Logon Message
    ... > for users" window is not sent to the RD client. ... In the Group Policy window, which is focused on the Default Domain ... Security Settings, then to Local Policies, and select Security Options. ...
    (microsoft.public.windowsxp.work_remotely)