I’ve solved it! A week ago started a series of unfortunate events that program progress on my application to a screeching halt. My efforts and work did not quit but every fix seemed to reveal another bizarre issue. But surely a professional programmer could figure all this out in a day rather than a week? No. Problem solving isn’t always that simple. This was akin to hiring a contractor to add a room to the back of the house but in starting to dig his foundations he discovers an old septic tank buried behind the house and in trying to remove it he discovers a cave under that. My problem began with a test when I cleared all my cookies.
On problem set off another. The development server, long overdue for an upgrade, lost its mind but this wasn’t immediately evident to me so I did a line by line inspection of the code searching for the answer to some really whacked out behavior. Eventually I realized the server was shot and moved to another server. After fixing several issues either hidden and discovered in the line by line inspection or caused by experimentation in attempts to fixed the oddities caused by the flaked out server, I eventually discovered the source of the original issue. In short, jQuery’s .filter gets overridden by jQuery’s .listen plugin so it appears.
jQuery has a built-in traversing function called filter() but handlers for events get bound only on the initial rendering of the DOM. If the DOM is modified dynamically, for instance if content is added with AJAX, then the newly added event handlers will not be recognized by filter(). Fortunately, Ariel Flesler stepped up and created a plugin called listen() (use the 1.0.3 version!) which registers the handlers for the matching events and this works for new content added via AJAX or other DOM manipulation. It seems, unless I am misinterpreting something, that listen() overrides filter() so if you have both filter() and listen() on the same page, your filter() events will never fire.
