Earlier this year

• Oct 29, 2009

  issue 14 (Hover event causes permission denied in FF when hovering ont...) Status changed by gregreimer   -   Okay, I added the try/catch block to the method. Thanks for finding this issue.

  Status: Started

  Okay, I added the try/catch block to the method. Thanks for finding this issue.

  Status: Started
• Oct 29, 2009

  r206 (added try/catch to Node.prototype.contains method) committed by gregreimer   -   added try/catch to Node.prototype.contains method

  added try/catch to Node.prototype.contains method
• Oct 29, 2009

  issue 14 (Hover event causes permission denied in FF when hovering ont...) reported by rhaddon   -   What steps will reproduce the problem? 1. Setup hover handler on Div element with scrollbar (overflow:scroll) 2. move mouse from scrollbar onto adjacent element with hover handler 3. Error is encountered: "Error: uncaught exception: [Exception... "Operation is not supported" code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location: "http://localhost/vz/script/reglib/reg1.0.6.js Line: 17"]" 4. Error is caused by the relatedTarget property of the event object referring to the Firefox chrome element (scrollbar), when the Node.prototype.contains method tries to interrogate this it's throw a permission denied error. What is the expected output? What do you see instead? No error What version of the product are you using? On what operating system? reg1.0.6 - Firefox 3.5.3 on Win 2K Please provide any additional information below. Here is a solutions which prevents FF throwing the error and returns the appropriate response for this scenario... if (window.Node && Node.prototype && !Node.prototype.contains) { Node.prototype.contains = function (arg) { try { return !!(this.compareDocumentPosition(arg) & 16); } catch (e) { return false; } } }

  What steps will reproduce the problem? 1. Setup hover handler on Div element with scrollbar (overflow:scroll) 2. move mouse from scrollbar onto adjacent element with hover handler 3. Error is encountered: "Error: uncaught exception: [Exception... "Operation is not supported" code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location: "http://localhost/vz/script/reglib/reg1.0.6.js Line: 17"]" 4. Error is caused by the relatedTarget property of the event object referring to the Firefox chrome element (scrollbar), when the Node.prototype.contains method tries to interrogate this it's throw a permission denied error. What is the expected output? What do you see instead? No error What version of the product are you using? On what operating system? reg1.0.6 - Firefox 3.5.3 on Win 2K Please provide any additional information below. Here is a solutions which prevents FF throwing the error and returns the appropriate response for this scenario... if (window.Node && Node.prototype && !Node.prototype.contains) { Node.prototype.contains = function (arg) { try { return !!(this.compareDocumentPosition(arg) & 16); } catch (e) { return false; } } }
• Jul 17, 2009

  issue 13 (Replace custom node-walking by Sizzle or Sly?) commented on by gpistatistics   -   I checked NWMatcher and NWEvents and both looks nice!. I will try it. Mostly NWEvents, as I have my own framework and only need an event handler that works like reglib/NWEvents.

  I checked NWMatcher and NWEvents and both looks nice!. I will try it. Mostly NWEvents, as I have my own framework and only need an event handler that works like reglib/NWEvents.
• Jul 16, 2009

  issue 13 (Replace custom node-walking by Sizzle or Sly?) commented on by diego.perini   -   mvolmaro, NWMatcher is faster on Firefox and Opera too, in the Sly test they just disabled the caching system without removing the caching code and conditionals, that was the only way to avoid loosing on all the browsers. ;-) For the task Greg is working on NWMatcher also has a "match()" method that will highly increase speed in event delegation. No other library has that, and it supports more specs than any other CSS selector.

  mvolmaro, NWMatcher is faster on Firefox and Opera too, in the Sly test they just disabled the caching system without removing the caching code and conditionals, that was the only way to avoid loosing on all the browsers. ;-) For the task Greg is working on NWMatcher also has a "match()" method that will highly increase speed in event delegation. No other library has that, and it supports more specs than any other CSS selector.
• Jul 02, 2009

  r205 (import no longer throws error but just logs errors to consol...) committed by gregreimer   -   import no longer throws error but just logs errors to console

  import no longer throws error but just logs errors to console
• Jun 09, 2009

  issue 13 (Replace custom node-walking by Sizzle or Sly?) commented on by mvolmaro   -   Well, I tried both and had no issues at all. Sly is smaller. I did not make any speed tests, but the speed test at http://digitarald.de/repos/sly/speed/index.php shows (on my machine) that Sizzle is faster for most of the tests on the latest Opera, I get a nice patchwork on both Safari 4 and Firefox 3 (no clear winner at all) while on IE8 the winner is NWMatcher. So, I too think it is safe to go with Sizzle :).

  Well, I tried both and had no issues at all. Sly is smaller. I did not make any speed tests, but the speed test at http://digitarald.de/repos/sly/speed/index.php shows (on my machine) that Sizzle is faster for most of the tests on the latest Opera, I get a nice patchwork on both Safari 4 and Firefox 3 (no clear winner at all) while on IE8 the winner is NWMatcher. So, I too think it is safe to go with Sizzle :).
• Jun 08, 2009

  issue 13 (Replace custom node-walking by Sizzle or Sly?) commented on by gregreimer   -   Actually yes, if it didn't significantly impact performance, I'd be in favor of doing that. I hope it wouldn't, since the selector libs seem to be in competition for who can be the fastest. I was thinking of Sizzle since that one seems to be relatively mature.

  Actually yes, if it didn't significantly impact performance, I'd be in favor of doing that. I hope it wouldn't, since the selector libs seem to be in competition for who can be the fastest. I was thinking of Sizzle since that one seems to be relatively mature.
• Jun 08, 2009

  issue 13 (Replace custom node-walking by Sizzle or Sly?) reported by mvolmaro   -   Hi!, Do you think it is worth the effort to replace your actual "Selector" method and all its dependencies with Sizzle or Sly?

  Hi!, Do you think it is worth the effort to replace your actual "Selector" method and all its dependencies with Sizzle or Sly?
• Jun 08, 2009

  issue 12 (Stopping event processing) Status changed by gregreimer   -  

  Status: Fixed

  Status: Fixed
• Jun 08, 2009

  r204 (delegate() function now unaffected by mutations to DOM while...) committed by gregreimer   -   delegate() function now unaffected by mutations to DOM while event handlerss execute

  delegate() function now unaffected by mutations to DOM while event handlerss execute
• Jun 06, 2009

  issue 12 (Stopping event processing) commented on by fsicre   -   > So basically, if you move the target of the event, or change the ancestor chain of > the target, you get undefined behavior. Yes. <script> reg.click('#div1 span', function(e) {- /* move span target to div2 */ document.getElementById('div2').appendChild(reg.getTarget(e)); }); reg.click('#div2 span', function(e) {- /* move span target to div1 */ document.getElementById('div1').appendChild(reg.getTarget(e)); }); </script> <div id="div1" style="border:2px solid red"> <span>A</span> <span>B</span> </div> <div id="div2" style="border:2px solid blue"> </div> If you click on <span>A</span>, Firebug will show you that the <span> goes to div2 and immediatly goes back to div1. That means that both handlers where triggered, although one click event was done. > What you're proposing is a panic button for coders who think they're triggering this > bug. So coders have to be cognizant of delegate()'s implementation details in order > to step around such issues. My first reaction was thinking of cancelBubble...If you want to stop bubbling...you can. Your solution of snapshot is probably closer to the spirit of reglib and the implementation is perfect : it works ! Thanks a lot.

  > So basically, if you move the target of the event, or change the ancestor chain of > the target, you get undefined behavior. Yes. <script> reg.click('#div1 span', function(e) {- /* move span target to div2 */ document.getElementById('div2').appendChild(reg.getTarget(e)); }); reg.click('#div2 span', function(e) {- /* move span target to div1 */ document.getElementById('div1').appendChild(reg.getTarget(e)); }); </script> <div id="div1" style="border:2px solid red"> <span>A</span> <span>B</span> </div> <div id="div2" style="border:2px solid blue"> </div> If you click on <span>A</span>, Firebug will show you that the <span> goes to div2 and immediatly goes back to div1. That means that both handlers where triggered, although one click event was done. > What you're proposing is a panic button for coders who think they're triggering this > bug. So coders have to be cognizant of delegate()'s implementation details in order > to step around such issues. My first reaction was thinking of cancelBubble...If you want to stop bubbling...you can. Your solution of snapshot is probably closer to the spirit of reglib and the implementation is perfect : it works ! Thanks a lot.
• Jun 05, 2009

  issue 12 (Stopping event processing) commented on by gregreimer   -   I think the best way to fix is to ensure delegate() operates against a snapshot of the DOM. This can be done by building an execution list and executing it after the DOM searching is done. This way even if the target jumps to another spot as you describe, it will only ever be executed in the context of the original selector. // the delegator function delegate(selectionHandlers, event) { if (selectionHandlers) { var execList = []; var targ = getTarget(event); for (var sel in selectionHandlers) { if(!selectionHandlers.hasOwnProperty(sel)) { continue; } for(var a=0; a<selectionHandlers[sel].length; a++) { var selHandler=selectionHandlers[sel][a]; var depth = (selHandler.depth==-1) ? 100 : selHandler.depth; var el = targ; for (var b=-1; b<depth && el && el.nodeType == 1; b++, el=el.parentNode) { if (selHandler.selector.matches(el)) { // replicate mouse enter/leave if (selHandler.hoverFlag) { var relTarg = getRelatedTarget(event); if (relTarg && (el.contains(relTarg) || el == relTarg)) { break; } } execList.push({"handle":selHandler.handle,"element":el}); break; } } } } for (var i=0; i<execList.length; i++) { var exec = execList[i]; var retVal=exec.handle.call(exec.element,event); // if they return false from the handler, cancel default if(retVal!==undefined && !retVal) { cancelDefault(event); } } } }

  I think the best way to fix is to ensure delegate() operates against a snapshot of the DOM. This can be done by building an execution list and executing it after the DOM searching is done. This way even if the target jumps to another spot as you describe, it will only ever be executed in the context of the original selector. // the delegator function delegate(selectionHandlers, event) { if (selectionHandlers) { var execList = []; var targ = getTarget(event); for (var sel in selectionHandlers) { if(!selectionHandlers.hasOwnProperty(sel)) { continue; } for(var a=0; a<selectionHandlers[sel].length; a++) { var selHandler=selectionHandlers[sel][a]; var depth = (selHandler.depth==-1) ? 100 : selHandler.depth; var el = targ; for (var b=-1; b<depth && el && el.nodeType == 1; b++, el=el.parentNode) { if (selHandler.selector.matches(el)) { // replicate mouse enter/leave if (selHandler.hoverFlag) { var relTarg = getRelatedTarget(event); if (relTarg && (el.contains(relTarg) || el == relTarg)) { break; } } execList.push({"handle":selHandler.handle,"element":el}); break; } } } } for (var i=0; i<execList.length; i++) { var exec = execList[i]; var retVal=exec.handle.call(exec.element,event); // if they return false from the handler, cancel default if(retVal!==undefined && !retVal) { cancelDefault(event); } } } }
• Jun 05, 2009

  issue 12 (Stopping event processing) commented on by gregreimer   -   So basically, if you move the target of the event, or change the ancestor chain of the target, you get undefined behavior. What you're proposing is a panic button for coders who think they're triggering this bug. So coders have to be cognizant of delegate()'s implementation details in order to step around such issues. Am I understanding the issue?

  So basically, if you move the target of the event, or change the ancestor chain of the target, you get undefined behavior. What you're proposing is a panic button for coders who think they're triggering this bug. So coders have to be cognizant of delegate()'s implementation details in order to step around such issues. Am I understanding the issue?
• Jun 05, 2009

  issue 12 (Stopping event processing) commented on by fsicre   -   // FS 2009-06-05 : reg.stopDelegate = function() { reg.delegateStopped = true; }; // the delegator function delegate(selectionHandlers, event) { // FS 2009-06-05 : reg.delegateStopped = false; var targ = getTarget(event); if (selectionHandlers) { for (var sel in selectionHandlers) { if(!selectionHandlers.hasOwnProperty(sel)) { continue; } for(var a=0; a<selectionHandlers[sel].length; a++) { var selHandler=selectionHandlers[sel][a]; if (selHandler.paused) { continue; } var depth = (selHandler.depth==-1) ? 100 : selHandler.depth; var el = targ; for (var b=-1; b<depth && el && el.nodeType == 1; b++, el=el.parentNode) { if (selHandler.selector.matches(el)) { // replicate mouse enter/leave if (selHandler.hoverFlag) { var relTarg = getRelatedTarget(event); if (relTarg && (el.contains(relTarg) || el == relTarg)) { break; } } var retVal=selHandler.handle.call(el,event); // if they return false from the handler, cancel default if(retVal!==undefined && !retVal) { cancelDefault(event); } break;; } // FS 2009-06-05 : if (reg.delegateStopped) { reg.delegateStopped = false; return; } } // FS 2009-06-05 : if (reg.delegateStopped) { reg.delegateStopped = false; return; } } // FS 2009-06-05 : if (reg.delegateStopped) { reg.delegateStopped = false; return; } } } }

  // FS 2009-06-05 : reg.stopDelegate = function() { reg.delegateStopped = true; }; // the delegator function delegate(selectionHandlers, event) { // FS 2009-06-05 : reg.delegateStopped = false; var targ = getTarget(event); if (selectionHandlers) { for (var sel in selectionHandlers) { if(!selectionHandlers.hasOwnProperty(sel)) { continue; } for(var a=0; a<selectionHandlers[sel].length; a++) { var selHandler=selectionHandlers[sel][a]; if (selHandler.paused) { continue; } var depth = (selHandler.depth==-1) ? 100 : selHandler.depth; var el = targ; for (var b=-1; b<depth && el && el.nodeType == 1; b++, el=el.parentNode) { if (selHandler.selector.matches(el)) { // replicate mouse enter/leave if (selHandler.hoverFlag) { var relTarg = getRelatedTarget(event); if (relTarg && (el.contains(relTarg) || el == relTarg)) { break; } } var retVal=selHandler.handle.call(el,event); // if they return false from the handler, cancel default if(retVal!==undefined && !retVal) { cancelDefault(event); } break;; } // FS 2009-06-05 : if (reg.delegateStopped) { reg.delegateStopped = false; return; } } // FS 2009-06-05 : if (reg.delegateStopped) { reg.delegateStopped = false; return; } } // FS 2009-06-05 : if (reg.delegateStopped) { reg.delegateStopped = false; return; } } } }
• Jun 05, 2009

  issue 12 (Stopping event processing) reported by fsicre   -   Imagine you have 2 divs with childs span. You setup two click event handlers for the #div .span that move the clicked span from its parent div to the other div. Seence there is also a click event on the childs of the destination div, the 2 handlers will be running and the span returns to its original div. This is because the break used in the delegate do not stop the search of an event handler. If you write return instead of break, the problem disappear : the first matching event handler do the job, moves the span for one div to the other, and that's it. This is not a good solution. I would like to have de really mechanism in the spirit of cancelBubble() : like stopHandlerSearch(). When a handler call reg.stopHAndlerSearch(), the delegate() will known that he got to stop asap. What do you think of that ? Thanx guys

  Imagine you have 2 divs with childs span. You setup two click event handlers for the #div .span that move the clicked span from its parent div to the other div. Seence there is also a click event on the childs of the destination div, the 2 handlers will be running and the span returns to its original div. This is because the break used in the delegate do not stop the search of an event handler. If you write return instead of break, the problem disappear : the first matching event handler do the job, moves the span for one div to the other, and that's it. This is not a good solution. I would like to have de really mechanism in the spirit of cancelBubble() : like stopHandlerSearch(). When a handler call reg.stopHAndlerSearch(), the delegate() will known that he got to stop asap. What do you think of that ? Thanx guys
• Jun 03, 2009

  r203 (reg.elementText() is recursive, but it was calling its own s...) committed by gregreimer   -   reg.elementText() is recursive, but it was calling its own shorthand alias, which failed when reg.importAll() wasn't being called first. fixed.

  reg.elementText() is recursive, but it was calling its own shorthand alias, which failed when reg.importAll() wasn't being called first. fixed.
• May 13, 2009

  r202 (elem() wouldn't accept numbers as content, fixed) committed by gregreimer   -   elem() wouldn't accept numbers as content, fixed

  elem() wouldn't accept numbers as content, fixed
• May 13, 2009

  r201 (newElement() can now take a number as a content arg without ...) committed by gregreimer   -   newElement() can now take a number as a content arg without throwing an error

  newElement() can now take a number as a content arg without throwing an error
• May 07, 2009

  reg.js (reglib 1.1.0) file uploaded by gregreimer
• May 07, 2009

  r200 (creating the 1.1.0 tag) committed by gregreimer   -   creating the 1.1.0 tag

  creating the 1.1.0 tag
• May 07, 2009

  r199 (creating the 1.1.x branch) committed by gregreimer   -   creating the 1.1.x branch

  creating the 1.1.x branch
• May 07, 2009

  r198 (removed unnecessary return statement in cleanup() function) committed by gregreimer   -   removed unnecessary return statement in cleanup() function

  removed unnecessary return statement in cleanup() function
• Apr 28, 2009

  r197 (fixed attribute end-selection bug) committed by gregreimer   -   fixed attribute end-selection bug

  fixed attribute end-selection bug
• Apr 10, 2009

  r196 (errors in setup functions were resulting in them being run t...) committed by gregreimer   -   errors in setup functions were resulting in them being run twice in browsers supporting the DOMContentLoaded event

  errors in setup functions were resulting in them being run twice in browsers supporting the DOMContentLoaded event
• Mar 05, 2009

  r195 (fixed an inconsistency between querySelector branch and old ...) committed by gregreimer   -   fixed an inconsistency between querySelector branch and old dom crawl branch

  fixed an inconsistency between querySelector branch and old dom crawl branch
• Mar 02, 2009

  issue 11 (user-generated events do not fire in IE.) commented on by mvolmaro   -   I forgot: As you may expect, if I do a node.focus(); before i change the index and fire the event, it works.

  I forgot: As you may expect, if I do a node.focus(); before i change the index and fire the event, it works.
• Mar 02, 2009

  issue 11 (user-generated events do not fire in IE.) commented on by mvolmaro   -   You are correct. I created a simple test case. On the attached file, after you select an option from the dropdown, a 5 secs. timer starts. When the timer ends, it changes the index of the selected item on the select and fires the change event. If the select is focused, the event is fired. If you has focus on the input field, the event it is not fired.

  You are correct. I created a simple test case. On the attached file, after you select an option from the dropdown, a 5 secs. timer starts. When the timer ends, it changes the index of the selected item on the select and fires the change event. If the select is focused, the event is fired. If you has focus on the input field, the event it is not fired.
• Mar 02, 2009

  issue 11 (user-generated events do not fire in IE.) commented on by gregreimer   -   Ah, yes I suspect this is because IE change events don't bubble. To test this hypothesis, if you focus the select element manually before programmatically firing the event, does it then work?

  Ah, yes I suspect this is because IE change events don't bubble. To test this hypothesis, if you focus the select element manually before programmatically firing the event, does it then work?
• Feb 24, 2009

  issue 11 (user-generated events do not fire in IE.) reported by mvolmaro   -   What steps will reproduce the problem? 1. Suscribe a dropdown to a change event (reg.onChange("#selectid"...) 2. Fire the change event manually by using el.fireEvent('onchange') What is the expected output? What do you see instead? The function registered on the event handler should be executed. Under IE, it is not. Under any other browser, it works as expected.

  What steps will reproduce the problem? 1. Suscribe a dropdown to a change event (reg.onChange("#selectid"...) 2. Fire the change event manually by using el.fireEvent('onchange') What is the expected output? What do you see instead? The function registered on the event handler should be executed. Under IE, it is not. Under any other browser, it works as expected.

Older

• Dec 18, 2008

  r194 (fixed bug in querySelector branch where comma-separated sele...) committed by gregreimer   -   fixed bug in querySelector branch where comma-separated selectors caused dupe setups

  fixed bug in querySelector branch where comma-separated selectors caused dupe setups
• Dec 18, 2008

  r193 (cleaned up memint stuff ) committed by gregreimer   -   cleaned up memint stuff

  cleaned up memint stuff
• Dec 13, 2008

  issue 9 (change & select events (cont.)) Status changed by gregreimer   -   Closing this issue, we should continue the discussion in the reglib group.

  Status: WontFix

  Closing this issue, we should continue the discussion in the reglib group.

  Status: WontFix
• Dec 13, 2008

  issue 10 (External selectors) commented on by hbiestro   -   Corrected a bug in addEvent for IE (creation of event handlers closure in a loop...).

  Corrected a bug in addEvent for IE (creation of event handlers closure in a loop...).
• Dec 12, 2008

  issue 10 (External selectors) reported by hbiestro   -   A prototype implementation of external selectors (as outlined in the mailing list thread http://groups.google.com/group/reglib/browse_thread/thread/66e7924a6f4c7604?hl=en ). This also includes the modifications proposed in issue#9 .

  A prototype implementation of external selectors (as outlined in the mailing list thread http://groups.google.com/group/reglib/browse_thread/thread/66e7924a6f4c7604?hl=en ). This also includes the modifications proposed in issue#9 .
• Dec 11, 2008

  issue 9 (change & select events (cont.)) commented on by hbiestro   -   Trying to respect more the spirit, here is another take based on 192. addEvent / removeEvent are modified to further allow array of event types, array of handlers as parameters allowing to remember multiple event-type*handler pairs in one memorized binding. I've also added a checkEvent that checks an element is pointed at by a memorized event 'binding'. This makes the IE6 part use only one event binding memory-id per element (instead of the 2 _prep_*) & allows to re-bind only if necessary. Just in case, my email is hbiestro at gmail dot com . Let me know if/when I'm intruding. (reposted because the file had an error)

  Trying to respect more the spirit, here is another take based on 192. addEvent / removeEvent are modified to further allow array of event types, array of handlers as parameters allowing to remember multiple event-type*handler pairs in one memorized binding. I've also added a checkEvent that checks an element is pointed at by a memorized event 'binding'. This makes the IE6 part use only one event binding memory-id per element (instead of the 2 _prep_*) & allows to re-bind only if necessary. Just in case, my email is hbiestro at gmail dot com . Let me know if/when I'm intruding. (reposted because the file had an error)
• Dec 11, 2008

  issue 9 (change & select events (cont.)) commented on by hbiestro   -   Trying to respect more the spirit, here is another take based on 192. addEvent / removeEvent are modified to further allow array of event types, array of handlers as parameters allowing to remember multiple event-type*handler pairs in one memorized binding. I've also added a checkEvent that checks an element is pointed at by a memorized event 'binding'. This makes the IE6 part use only one event binding memory-id per element (instead of the 2 _prep_*) & allows to re-bind only if necessary. Just in case, my email is hbiestro at gmail dot com . Let me know if/when I'm intruding.

  Trying to respect more the spirit, here is another take based on 192. addEvent / removeEvent are modified to further allow array of event types, array of handlers as parameters allowing to remember multiple event-type*handler pairs in one memorized binding. I've also added a checkEvent that checks an element is pointed at by a memorized event 'binding'. This makes the IE6 part use only one event binding memory-id per element (instead of the 2 _prep_*) & allows to re-bind only if necessary. Just in case, my email is hbiestro at gmail dot com . Let me know if/when I'm intruding.
• Dec 10, 2008

  r192 (reduced closures ) committed by gregreimer   -   reduced closures

  reduced closures
• Dec 10, 2008

  issue 9 (change & select events (cont.)) commented on by hbiestro   -   One last version where the whole delegation fix is in a separate function; splitting this into a separate file would allow to use IE conditional comments for inclusion and completely unclutter the main code line. The function has only one dependency on reglib, the delegator(eventType) function. I guess this could make the function suitable for other 'delegation' based libs. Hope you'll find some use to it; Thanks again.

  One last version where the whole delegation fix is in a separate function; splitting this into a separate file would allow to use IE conditional comments for inclusion and completely unclutter the main code line. The function has only one dependency on reglib, the delegator(eventType) function. I guess this could make the function suitable for other 'delegation' based libs. Hope you'll find some use to it; Thanks again.
• Dec 09, 2008

  issue 9 (change & select events (cont.)) commented on by gregreimer   -   Whoops wrote #11 without seeing #10...

  Whoops wrote #11 without seeing #10...
• Dec 09, 2008

  issue 9 (change & select events (cont.)) commented on by gregreimer   -   I see. I think the proliferation of closures issue could be avoided by simply defining the event handlers outside of reg.focus and passing in a reference. This (untested) code is identical to the trunk except for the lexical nesting. Yes there are 4x the number of functions but none of them generates a closure: function ieSubmitDelegate(e) { delegate(submitHandlers,e); cancelBubble(e); }; function ieResetDelegate(e) { delegate(resetHandlers,e); cancelBubble(e); }; function ieChangeDelegate(e) { delegate(changeHandlers,e); cancelBubble(e); }; function ieSelectDelegate(e) { delegate(selectHandlers,e); cancelBubble(e); }; reg.focus('form',function(){ removeEvent(this._submit_prep); this._submit_prep=addEvent(this,'submit',ieSubmitDelegate,false,true); removeEvent(this._reset_prep); this._reset_prep=addEvent(this,'reset',ieResetDelegate,false,true); },function(){ removeEvent(this._submit_prep); removeEvent(this._reset_prep); }); reg.focus('select,input@type="text",input@type="password",input@type="radio",input@type="checkbox",textarea',function(){ removeEvent(this._change_prep); this._change_prep=addEvent(this,'change',ieChangeDelegate,false,true); },function(){ removeEvent(this._change_prep); }); reg.focus('input@type="text",input@type="password",textarea',function(){ removeEvent(this._select_prep); this._select_prep=addEvent(this,'select',ieSelectDelegate,false,true); },function(){ removeEvent(this._select_prep); });

  I see. I think the proliferation of closures issue could be avoided by simply defining the event handlers outside of reg.focus and passing in a reference. This (untested) code is identical to the trunk except for the lexical nesting. Yes there are 4x the number of functions but none of them generates a closure: function ieSubmitDelegate(e) { delegate(submitHandlers,e); cancelBubble(e); }; function ieResetDelegate(e) { delegate(resetHandlers,e); cancelBubble(e); }; function ieChangeDelegate(e) { delegate(changeHandlers,e); cancelBubble(e); }; function ieSelectDelegate(e) { delegate(selectHandlers,e); cancelBubble(e); }; reg.focus('form',function(){ removeEvent(this._submit_prep); this._submit_prep=addEvent(this,'submit',ieSubmitDelegate,false,true); removeEvent(this._reset_prep); this._reset_prep=addEvent(this,'reset',ieResetDelegate,false,true); },function(){ removeEvent(this._submit_prep); removeEvent(this._reset_prep); }); reg.focus('select,input@type="text",input@type="password",input@type="radio",input@type="checkbox",textarea',function(){ removeEvent(this._change_prep); this._change_prep=addEvent(this,'change',ieChangeDelegate,false,true); },function(){ removeEvent(this._change_prep); }); reg.focus('input@type="text",input@type="password",textarea',function(){ removeEvent(this._select_prep); this._select_prep=addEvent(this,'select',ieSelectDelegate,false,true); },function(){ removeEvent(this._select_prep); });
• Dec 09, 2008

  issue 9 (change & select events (cont.)) commented on by hbiestro   -   Another version based on trunk 191 & previous comment. I've widened the selector to target all 'input' (since input type='file' may also change), added a stupid check (just in case some handlers can not be set on a given element type) and removed closures creation. The code itself does not add any functionality to the trunk; it's just another way to solve the IE pb in case something can be used.

  Another version based on trunk 191 & previous comment. I've widened the selector to target all 'input' (since input type='file' may also change), added a stupid check (just in case some handlers can not be set on a given element type) and removed closures creation. The code itself does not add any functionality to the trunk; it's just another way to solve the IE pb in case something can be used.
• Dec 08, 2008

  issue 9 (change & select events (cont.)) commented on by hbiestro   -   on #8, instead of creating one closure per event handler, the ieCallDelegate function is used by all of them; the 'switch' on which delegate to call is performed within the function body based on the event type (1 closure for all handlers rather than 1 for each). On the same principle,I should have unified the the 'unhooking' closure using the srcElement from the deactivate event handler (to find which events to unhook from the ieHooks[srcElement.reglibHookId] hook). The benefit is that the onactivate/ondeactivate handlers would then both be fixed functions making them easier to attach/detach. In more general terms, I was trying to segregate the IE specifics and be (very) memory conscious - I do not event trust that ondeactivate will be enough to cleanup in all cases (does setting elt.innerHTML trigger ondeactivate in any/all cases? IE6 has so many edge cases...). I'm probably over defensive. :-)

  on #8, instead of creating one closure per event handler, the ieCallDelegate function is used by all of them; the 'switch' on which delegate to call is performed within the function body based on the event type (1 closure for all handlers rather than 1 for each). On the same principle,I should have unified the the 'unhooking' closure using the srcElement from the deactivate event handler (to find which events to unhook from the ieHooks[srcElement.reglibHookId] hook). The benefit is that the onactivate/ondeactivate handlers would then both be fixed functions making them easier to attach/detach. In more general terms, I was trying to segregate the IE specifics and be (very) memory conscious - I do not event trust that ondeactivate will be enough to cleanup in all cases (does setting elt.innerHTML trigger ondeactivate in any/all cases? IE6 has so many edge cases...). I'm probably over defensive. :-)
• Dec 08, 2008

  r191 (autocleanup ) committed by gregreimer   -   autocleanup

  autocleanup
• Dec 08, 2008

  issue 9 (change & select events (cont.)) commented on by gregreimer   -   In the code you posted, where it says "one func to unite them all and avoid creating new ones on the fly" what do you mean by "creating new ones on the fly"?

  In the code you posted, where it says "one func to unite them all and avoid creating new ones on the fly" what do you mean by "creating new ones on the fly"?
• Dec 08, 2008

  issue 9 (change & select events (cont.)) commented on by hbiestro   -   Looks great, thanks.

  Looks great, thanks.
• Dec 08, 2008

  issue 9 (change & select events (cont.)) commented on by gregreimer   -   Okay it should more fully support change and it also removes the event onblur now.

  Okay it should more fully support change and it also removes the event onblur now.
• Dec 08, 2008

  r190 (updated removeEvent to delete the reference entirely, instea...) committed by gregreimer   -   updated removeEvent to delete the reference entirely, instead of just removing the event

  updated removeEvent to delete the reference entirely, instead of just removing the event
• Dec 08, 2008

  r189 (ie change subdelegation, updated selector to include other i...) committed by gregreimer   -   ie change subdelegation, updated selector to include other input elements, added removal of events on blur

  ie change subdelegation, updated selector to include other input elements, added removal of events on blur
• Dec 08, 2008

  issue 9 (change & select events (cont.)) commented on by hbiestro   -   Just for the sake (& fun) of it, here is a modified r188 version attempting to unhook things.

  Just for the sake (& fun) of it, here is a modified r188 version attempting to unhook things.