> Diego A.,
> thank you for finding this inconsistency about my patch for
> event.fix(),
>
> I didn't know much about namespaced event, after reading a bit those
> are "Custom Namespaced" events, as you said I don't know if there
> is a real need for that complexity and this is absolutely slowing
> down even real DOM0/DOM2 event processing.
>
> Anyway I will have a look at it and see if I can submit another
> version
> of the event.fix() patch that considers these capabilities too.
>
> In these days I was really thinking that all this work of re-creating
> events with loops to copy properties is really unnecessary, it
> would be enough to let plugins re-create events with standard
> DOM calls (createEvent/createEventObject) and passing them
> when triggering Custom/Namespaced/Special events.
>
> In this way we could really improve things in a drastic way.
>
> Probably something like an internal "createEvent" as suggested
> in my patch but instead of looping through all the properties and
> copying them just let the standard createEvent() methods do that.
>
> The "createEvent" would just be a cross-browser wrapper
> to createEvent() or createEventObject(). In this way the
> properties that were read-only will remain read-only and
> this will be as from the W3C specifications.
>
> In the current implementation it seems to me that the W3C
> specs have been completely forgotten and penalized in
> favor of personalized implementations for special events,
> custom events and namespaced events.
>
> I don't think this is correct, we should go back and try
> to rethink about it now while the changes are few and
> localized to just few plugins using it.
>
> As I said it is not a good moment for me now, but I will
> try to include a patch that resumes what I said above
> with a really small correction to Brandon special events.
>
> Diego Perini
>
> On 23 Apr, 12:54, "Diego A." <diego.a...@...> wrote:
>
> > Hi Diego, (hope you're still monitoring this thread)
>
> > I found a problem. jQuery.ui.slider does not work with your patch.
> > This is beyond my understand of jQuery's event handling, but I believe
> > the problem is happening because of lines like this:
>
> > $(element).bind("setData.slider", function(event, key, value){
>
> > I don't understand the purpose of the periods in the event ID and how
> > jQuery uses it, but it seems to be the cause of the problem in your
> > patch.
>
> > The question is, is this complex event handling actually necessary?
> > Any ideas?
>
> > Cheers,
> > Diego A.
>
> > On Apr 16, 2:07 pm, "Diego A." <diego.a...@...> wrote:
>
> > > Hi Diego,
>
> > > The fix works perfectly now. Massive improvement!
> > > I hope it makes its way into the next jQuery release...
>
> > > Thanks for all your work!
>
> > > Diego A.
>
> > > On Apr 13, 11:57 pm, Diego Perini <diego.per...@...> wrote:
>
> > > > Diego A.,
> > > > you are correct...I forgot the "special" "custom" event... :-)
>
> > > > There are probably a couple of ways to solve this long puzzle,
> > > > the first is easy and hope finally backward compatible with
> > > > existing code; remove the following conditional lines so
> > > > the contained block is always executed:
>
> > > >    // is it a custom event
> > > >    if ( !ev.initEvent ) {
> > > > ...
> > > >    }
>
> > > > Above code start around line 2220 in the patched jQuery source.
>
> > > > This will decrease a bit in performances for every other type of
> > > > event on every browser but IE (event properties are writable).
>
> > > > That code block is what makes the event object writable on other
> > > > browsers different from IE, the conditional around it was put in
> > > > place to only do this when dealing with custom events,
> > > > but special events are still another case (similar...).
>
> > > > I will do my best to setup a new patch with that correction.
>
> > > > I am currently closing a long waiting work and not too much
> > > > time left. Thank you for reviving this out of that long thread.
>
> > > > Diego Perini
>
> > > > On 12 Apr, 16:57, "Diego A." <diego.a...@...> wrote:
>
> > > > > Continued from:http://groups.google.com/group/jquery-dev/browse_frm/thread/8cce225d1...
>
> > > > > Hi Diego (Perini),
>
> > > > > I've been away for a few days, and now I've tested the latest version
> > > > > of your patch, I still get an error with the TreeView plugin. I don't
> > > > > know if it's something the TreeView plugin.
>
> > > > > I've setup a test here:http://www.fyneworks.com/jquery/event.fix/DiegoPerini/readOnlyProperty/
>
> > > > > The error messages are:
>
> > > > > (line 2315) setting a property that has only a getter
> > > > > [Break on this error] arguments[0].type = "mouseleave";
>
> > > > > (line 2293) setting a property that has only a getter
> > > > > [Break on this error] arguments[0].type = "mouseenter";
>
> > > > > As far as I can see, the problem originates from the use of the .hover
> > > > > function, which in turn uses the special jQuery mouseenter /
> > > > > mouseleave events. I found some information about them here:http://jquery.com/blog/2008/01/15/jquery-122-2nd-birthday-present/
>
> > > > > I hope this helps.
>
> > > > > Diego A.