[PATCH] tracking form value changes in onclick-handlers

[Tobias Anton]

On Dienstag, 13. Juli 2004 02:06, bj at altern.org wrote:
> On Monday 12 July 2004 19.52, Tobias Anton wrote:
> > I'm planning to commit a patch like this one, and then I'd like to change
> > the default event handlers of activatable elements (links, form controls
> > and labels) to react on DOMACTIVATE_EVENT instead of CLICK_EVENT, or
> > event worse, MOUSEUP_EVENTS.
> >
> > Is there anything basically wrong or can I try this approach?
>
> Many webmail have a checkbox with something like this:
>
> <form>
> <input type="checkbox" onclick="anotherform.checked=this.checked">1<br>
> <input id="anotherform" type="checkbox"
> onclick="anotherform.checked=this.checked">2
> </form>
>
> Clicking on the checkbox 1 should always set the second checkbox to the
> same value. If you process the javascript events first, the this.checked
> will return a wrong value...
>
> I don't think your patch adresses this issue.

Hmm, you're right. Actually, IE calls the onclick-handler after the change of 
the mouseclick.

However, if a DOM-2-event listener is registered in IE, it cannot affect the 
value of the calling form control at all, but this does not affect our code.

In any case, to be able to have the onclick-handler see the already changed 
document, it would have to be executed after the default event handler of 
DOMACTIVATE_EVENT, which makes me think of the following solution:

DOM::ElementImpl::defaultEventHandler(EventImpl *evt)
{
	if (evt->id() == DOMACTIVATE_EVENT && !evt->defaultPrevented)
	{
		dispatchGenericEvent(ONCLICK_EVENT);
	}
}

HTML::HTMLInputElementImpl::defaultEventHandler(EventImpl *evt)
{
	if (evt->id() == DOMACTIVATE_EVENT)
	{
		setChecked(m_type==RADIO?true:!checked());
	}
	HTMLGenericFormElementImpl::defaultEventHandler(evt);
}

So basically, I'd have to separate the js event listeners for the CLICK_EVENT 
from the attribute-based DOM-0-handlers. Would this be better or is there any 
reason not do this i have overlooked?

-- Tobias