patch: fix for event.cancelBubble and event.returnValue

[Maciej Stachowiak]

On Nov 8, 2003, at 9:33 AM, David Faure wrote:

> On Wednesday 29 October 2003 02:31, Maciej Stachowiak wrote:
>>
>> The most important part of this is ensuring that cancelBubble = true
>> does not prevent default. A lot of sites apparently use cancelBubble 
>> to
>> eat the event but still alow default handling, as for a link click.
>
> Indeed.
> However this matches the DOM3 stopPropagation behaviour:
> "Note: This method does not prevent the default action from being 
> invoked; use preventDefault for that effect."
>
> So I think it's wrong to add the new boolean m_cancelBubble.
> This can be done by using m_propagationStopped instead (and 
> propagationStopped()/setPropagationStopped()),
> can't it?

OK, that makes sense. I'll merge your approach to things.

>
> The code in HEAD for setting the value of those two MSIE attributes is:
>
> void DOMEvent::putValueProperty(ExecState *exec, int token, const 
> Value& value, int)
> {
>   switch (token) {
>   case ReturnValue: // MSIE equivalent for "preventDefault" (but with 
> a way to reset it)
>     // returnValue=false means "default action of the event on the 
> source object is canceled",
>     // which means preventDefault(true). Hence the '!'.
>     event.handle()->preventDefault(!value.toBoolean(exec));
>     break;
>   case CancelBubble: // MSIE equivalent for "stopPropagation" (but 
> with a way to reset it)
>     event.handle()->stopPropagation(value.toBoolean(exec));
>     break;
>   default:
>     break;
>   }
> }
>
> I think the only problem is if stopPropagation indeed prevents the 
> default from
> being executed....  But this seems to be fixed in HEAD too. The 
> attached testcase
> passes (it's not good looking, but the associated eventhandler.js in 
> CVS allows
> to run this through test_regression).

It did prevent it in the version we merged, but now I understand that 
stopPropagation ought not prevent default.

Regards,
Maciej