This is probably the most glaring flaw in RC0: any event types that
are not part of the DOM L2 Events spec, but are nonetheless honored by
one or more browsers, are handled incorrectly by Prototype as custom

We've got to figure out a way around this, even if it means we create
a whitelist of all known event types to work in modern browsers. The
convenience of handling both custom and standard events with the same
API shouldn't make it harder to (for instance) skate on the bleeding
edge of Web Forms 2.

I'll make sure we figure this out before RC1.


On Aug 17, 8:12 am, Wiktor Ihárosi <[EMAIL PROTECTED]> wrote:
> The new prototype is under heavy test and I find another intresting
> bug...
> The modified observe method try to get the name of the passed
> eventName by getDOMEventName but this is limited to the well-known
> events. Any unknown event will handled as 'dataavailable'.
> This cause problems if you use predefined events, for example using
> fantastic repetitionmodel (webforms2 now) implementation by Weston
> Ruter which implements new Web Forms 2 events. But the problem is same
> if you use Opera9, it has native support for these events.
> Here is an example 
> page:
> Please check in Opera, and click on the Add Row button. You should see
> two alerts, but you will only one.
> Unfortunately I am not good at the event model, so I don't know what
> is the reason of the 'dataavailable', but my dirty hack is to return
> eventName is condition fail. It works for me. :)
> if (!Event.DOMEvents.include(eventName)) return eventName;
> instead of
> if (!Event.DOMEvents.include(eventName)) return "dataavailable";

You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to