patch: fix for event.cancelBubble and event.returnValue

[David Faure]

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?

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).

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.kde.org/mailman/private/khtml-devel/attachments/20031108/1cbbe833/eventhandler.html