Bug 4573

Created attachment 3496 [details] patch to check on khtmlClick rather than click, not insist on a mouse event

Comment on attachment 3496 [details] patch to check on khtmlClick rather than click, not insist on a mouse event I need Dave's input on whether this is the right way to fix this.

The change itself looks ok, however, I think the whole pre-dispatch event handling concept may be bogus. Other browsers will allow the click event handler for a radio button or checkbox to prevent the default action of toggling its checked state.

Comment on attachment 3496 [details] patch to check on khtmlClick rather than click, not insist on a mouse event Assuming you tested this with both click() and real mouse clicks, r=me. However - our handling here is somewhat wrong. Preventing default in or returning false from a mouse handler will not prevent the checkbox or radio button from being checked, and it should.

Comment on attachment 3496 [details] patch to check on khtmlClick rather than click, not insist on a mouse event Assuming you tested this with both click() and real mouse clicks, r=me. However - our handling here is somewhat wrong. Preventing default in or returning false from a mouse handler will not prevent the checkbox or radio button from being checked, and it should.

Comment on attachment 3496 [details] patch to check on khtmlClick rather than click, not insist on a mouse event Assuming you tested this with both click() and real mouse clicks, r=me. However - our handling here is somewhat wrong. Preventing default in or returning false from a mouse handler will not prevent the checkbox or radio button from being checked, and it should.

Actually it's much weirder than that. onmousedown preventDefault does not stop checking. onclick preventDefault actually *reverses* the checking/unchecking in WinIE and Firefox. In other words you let the checking/unchecking happen and then undo it! I'm not sure if this is going to be necessary or not... Anyway, r- on the patch since the real bug is just that the click method was sending a KHTML_CLICK and not a real CLICK event.

KHTML_CLICK needs to be eliminated as well, since its presence causes onclick to fire at the wrong time, after bubbling has happened in the real DOM. I'm going to file a follow-up bug to eliminate KHTML_CLICK.

Fixed.