Re: IE leaks, circular references, addevent et al

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

[...]

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. For all we know, such property (e.g. `oncontextmenu`) can be no better that `_foobar` one and can lead to all the same consequences.


[...]

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;

[...]

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.




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

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

[...]

--
kangax
.

Relevant Pages

  • 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: 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, ... // Result is ambiguous in all but modern browsers, ...
    (comp.lang.javascript)
  • Re: Windows Vista Imitates Mac OS X Features @ CES
    ... Mr. Pogue apparently made one error in his article regarding 'window miniatures' in the new version of IE. ... It's a lot like the Dashboard in Mac OS X, except that apparently, you can't put the widgets anywhere on the screen you like. ... It's a lot like the Expose feature in Mac OS X, except that you don't get to see all of the windows simultaneously; you have to walk through them one at a time with the mouse or keyboard. ... Internet Explorer will finally get tabbed browsing, in which you can keep multiple Web pages open at once, all in the same window; you switch from one to the next by clicking little file-folder tabs at the top. ...
    (comp.sys.mac.advocacy)
  • 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)
  • Re: TCP packets : end of thre-way handshake and start of data-transmission - how to dete
    ... RFC 793 Section 3.4 (Establishing a connection) says in part: ... packet because it would be necessary to assume a window size. ... client has already indicated a non-empty window). ... Server sends SYN/ACK and data ...
    (comp.arch.embedded)
Loading