Re-enable disabled form elements when user goes 'Back'

[Richard Maher]

Hi David,

I'm looking over the many addEvent implementations and trying to
distill something that's cross-browser functional and without memeory
leaks (if not "best practice") and was wondering if David had a
matching removeEvent, or is the optimized-back-button friendly
behaviour meant to leave all handlers ready for a swift return?

Of course there is a removeEvent equivalent (detachListener in My
Library IIRC).

[Ok, I'll trace back and find out what your library is called and have a
look. Thanks.]

Is there still no universally applauded (and publicly available) add/
remove event mechanism?

Mechanism for what?

[Adding and Removing event handlers perhaps]

Your thinking is too broad here.

[I think you're right.]

Personally, I use applets and will stick an onunload event in there

Java applets on the client side?!

[Yes]

even if it does nothing just to disable the disasterously "clever"
behaviour of the back-button on some browsers.

That's completely silly.

[I dispute "completely" Anyway, anyone who's ever tried to debug Applet
behaviour across FF's Back Button optimization might think differently]

Regards Richard Maher

 

[David Mark]

Hi David,

I'm looking over the many addEvent implementations and trying to
distill something that's cross-browser functional and without memeory
leaks (if not "best practice") and was wondering if David had a
matching removeEvent, or is the optimized-back-button friendly
behaviour meant to leave all handlers ready for a swift return?

Of course there is a removeEvent equivalent (detachListener in My
Library IIRC).

[Ok, I'll trace back and find out what your library is called and have a
look. Thanks.]

I took it down over the summer. I still fill email requests for the
last official version.

Is there still no universally applauded (and publicly available) add/
remove event mechanism?

Mechanism for what?

[Adding and Removing event handlers perhaps]

Your thinking is too broad here.

[I think you're right.]

Personally, I use applets and will stick an onunload event in there

Java applets on the client side?!

[Yes]
OMG.

even if it does nothing just to disable the disasterously "clever"
behaviour of the back-button on some browsers.

That's completely silly.

[I dispute "completely" Anyway, anyone who's ever tried to debug Applet
behaviour across FF's Back Button optimization might think differently]

Granted, I didn't make that connection. Still, if you lose the Java
applets...

 

[abozhilov]

var addEvent = (function(){

   var globalContext = this,
       contextId = 0,
       eventContexts = [ ];

   function getNormalizedHandler(contextId, handler) {
     return function() {
       return handler.call(eventContexts[contextId],
         globalContext.event);
     }
   }

   if (window.addEventListener) {
     return function(element, eventName, handler) {
       return element.addEventListener(eventName, handler, false);
     };
   }
   else if (window.attachEvent) {
     return function(element, eventName, handler) {
       eventContexts[contextId++] = element;
       var normalizedHandler = getNormalizedHandler(contextId, handler);
       element.attachEvent('on' + eventName, normalizedHandler);
     };
   }

})();

It's an interesting solution, but has potential of creating a bunch of
"repeating" element references. For example, invoking `attachListener`
with same element, same event name and same handler 100 times will
result in an array of 100 objects, `context` property of which will
reference that same element. If expandos were used, N invocations would
result in 1 reference, not N.

If you then delete an element (that has an attached event listener
through your wrapper) from the document, you still have 1 or more
references to that element in your array. If you want to delete that
reference at some point (to let removed element be garbage collected)
you need to go through N objects, not 1. This can be costly, but would
all depend on a context of course.

These are the only downsides I can see in that approach as of now.

`addEvent` looks will never implement `removeEvent`. In this design, i
can't dettachEvent, because every time attached anonymous function.
Pointer of that anonymous function is loose when i call dettachEvent.
We have and another problem:

function testFunc() {
alert('testFunc');
}
addEvent(obj, 'click', testFunc);
addEvent(obj, 'click', testFunc);

When triggered click event, handler function execute twice time. Again
from anonymous function and recreation pointer of that anonymous
function.

 

[Richard Maher]

Hi David,

Hi David,




Of course there is a removeEvent equivalent (detachListener in My
Library IIRC).

Any chance of you posting a copy here? I first thought that somehow your
implementation of the addEvent was so fiendishly clever that the listener
function's signature was so generic as to be renderable at will, and as long
as you knew the "element" and the "eventName" you were listening for then an
appropriate removeEventListener or detachEvent was mere child's play. But,
if I'm not mistaken, those functions want a pointer to the actual handler so
I'm at a loss as to how you expose the closure in addEvent to your
detachListener. Sorry for floundering arround and being a bit slow on the
up-take but I like your addevent and am very interested in seeing the
detachListener.

[Ok, I'll trace back and find out what your library is called and have a
look. Thanks.]

[I took it down over the summer. I still fill email requests for the
last official version.]

Ok, I'm happy to send an e-mail but, cards on the table, I'd want to use
this in a commercial(ish) product so if you're understandably reluctant to
share then that's fine.

[Granted, I didn't make that connection. Still, if you lose the Java
applets...]

- Single-Signon without session-hijackable cookie bollocks?
- Single, persistent network connection across multiple active tabs in a
browser instance?
- Full-on synchronous of asynchrous i/o capability?
- 1:M relationship between messages sent to received?
- Retention of server-affinity if/when needed?

It's alright if you're into that sort of thing I suppose. Works for me!

Cheers Richard Maher

 

[David Mark]

Hi David,






Any chance of you posting a copy here?

Too long. Email me and I'll send you the whole script...

I first thought that somehow your
implementation of the addEvent was so fiendishly clever that the listener
function's signature was so generic as to be renderable at will, and as long
as you knew the "element" and the "eventName" you were listening for thenan
appropriate removeEventListener or detachEvent was mere child's play.

Uh yes, child's play. I have no idea what you mean.

But,
if I'm not mistaken, those functions want a pointer to the actual handlerso
I'm at a loss as to how you expose the closure in addEvent to your
detachListener.

Yeah, my wrappers work. You'll be at less of a loss once you actually
see them.

Sorry for floundering arround and being a bit slow on the
up-take but I like your addevent and am very interested in seeing the
detachListener.

No problem here. I await your email... Disregard if sent. Haven't
read personal mail in the last day or so.

[Ok, I'll trace back and find out what your library is called and have a
look. Thanks.]

[I took it down over the summer.  I still fill email requests for the
last official version.]

Ok, I'm happy to send an e-mail but, cards on the table, I'd want to use
this in a commercial(ish) product so if you're understandably reluctant to
share then that's fine.

Who said I was reluctant? I don't know you or your project. As for
my disclaimer about not using My Library for free, write to the
address shown and ask... A few have and got free licenses for their
"trouble".

[Granted, I didn't make that connection.  Still, if you lose the Java
applets...]

- Single-Signon without session-hijackable cookie bollocks?
- Single, persistent network connection across multiple active tabs in a
browser instance?
- Full-on synchronous of asynchrous i/o capability?
- 1:M relationship between messages sent to received?
- Retention of server-affinity if/when needed?

And all but unusable on the Web. Good luck with that!

It's alright if you're into that sort of thing I suppose. Works for me!

What sort of thing?

 

[abozhilov]

When you have little time. Look `getNormalizedHandler` in code.

It's not, when created with original `attachEvent`. Again, `_fnId` is
probably the one guarding against that.

With `_fnId` in first look, maybe we have a problem with same
anonymous function. If that `_fnId` is string value like:

obj[evt_t + handler] = handler;

In this way when i call addEvent twice time with:
addEvent(obj, 'click', function(){alert('test');});
addEvent(obj, 'click', function(){alert('test');});

When triggered click, this code alerting only once time. Because
anonymous_func.toSring() is the same.

I use something like that:
function addEvent(obj, evt_t, handler)
{
obj.detachEvent(evt_t, handler);
obj.attachEvent(evt_t, handler);
}
addEvent(obj, 'onclick', testFunc);
addEvent(obj, 'onclick', testFunc);

 

[abozhilov]

function addEvent(element, eventName, handler) {
   ...
   if (!('_fnId' in handler)) {
     handler._fnId = fnId++;
   }
   ...

}

Interesting, but again need downsides to DOM element and attach
property something like this:

obj[eventName + handler._fnId];

Or using "hash" table, without attaching and removing attributes from
DOM elements.

Actually, `toString` on anonymous function - `(function(){ ...}).toString` - propagates to `Function.prototype.toString`. That method

returns implementation-dependent function representation (in both - ES3
and ES5 draft) and - for these reasons - is better avoided.

Interesting, i will be read that. Thanks :~)

 

[Richard Maher]

Hi David.

No problem here. I await your email... Disregard if sent. Haven't
read personal mail in the last day or so.

Sent today, sorry for the delay, and I understand if there's nothing you can
do.

And all but unusable on the Web.

Go on then - "Why not?"

Good luck with that!

Thanks, but I don't think luck will hav anything to do with it!

Cheers Richard Mhher