User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 This is a new issue (didn't happen previously in Mozilla) If an onDblClick event handler (attribute on the select tag) is added to a select-multiple form element, it gets fired off, when a user double clicks on the scroll controls (arrow up, thumb screw, arrow down). This is very anoying, since users will click the arrows repeatedly to scroll a list. Since the dblClick event is ideal for 'special' selection of an item in a list, any JavaScript code attached to the event, will now either fail/behave strangly, as there will not actually be a "selected" item in the list. Reproducible: Always Steps to Reproduce: 1. Create an HTML <select/> element with a size > 1, more options than the specified size, and an onDblClick event handler. 2. Double Click on the scroll controls in the list. Actual Results: onDblClick event handler is fired, when it is not expected. Expected Results: I would expect the previous behavior / behaviour of other browser/form controls, whereby the onDblClick event is only fired, upon DblClicking an item in the list. Although I haven't tested yet, this may apply to a size=1 <select/> list, and this may also apply to the <textarea/> element as well. A Simple Test case will be attached shortly.

The "untested" patch in bug 207637 should fix this bug... it doesn't look like it will be used to fix bug 207637, but it should happen at some point, probably.

Simple Test Case.

I think we should definitely stop scroll events from bubbling but I'm not sure that the patch in bug 207637 is the right way to do it. It might be better to just add some event handlers to the <scrollbar> XBL and cancel bubbling there. CCing Neil...

Like this?

Yeah, like that, but for all mouse events :-) I don't suppose you know what the overhead is for adding these handlers? Would we pay a per-scrollbar space cost, or are the handlers shared?

Oh right: mouseover, mouseout, any others? Also, each scrollbar event handler costs, although peterv was working on sharing xbl event handlers - input and textarea have a large number of handlers.

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent So "click", "mousedown", "mouseup", "mouseover", "mousemove", "mouseout" (I guess "dblclick" is our extension ... don't know if we have any other mouse event extensions) I wonder how bloaty it would be to add all these. Could be fairly bloaty for pages with lots of comboboxes/listboxes. Shared event handlers sure would be nice, which bug is that? Maybe this should depend on that bug.

Do you want events on scrollbars to be ignored by capturing handlers too? I don't think that's possible in XBL...

I think it's OK for event capturers to capture events that happen in scrollbars. In that case they're not delivered to the scrollbar, right? The thing we want to avoid is events that cause two actions.

Here's a list from nsDOMEvent.cpp: mousedown mouseup click dblclick mouseover mouseout mousemove contextmenu dragenter dragover dragexit dragdrop draggesture I'm not sure which of the drag messages we should block, if any.

Let's not block any drag events for now. I hope that drags not initiated by a scrollbar get captured by the initiator anyway, and our scrollbar shouldn't be initiating drags.

You want to delete the first "contextmenu" line, right?

That line stops an apparently unwanted context menu popping up on a browser/frame/tree when you right-click its scrollbar. See bug 74380, bug 74688 and bug 149474.

Comment on attachment 131348 [details] [diff] [review] Proposed patch OK, I get it now. I'm not sure if it's really legit for me to r+ this one...

Comment on attachment 131348 [details] [diff] [review] Proposed patch Fixing roc's + for him.

Comment on attachment 131348 [details] [diff] [review] Proposed patch Review hokey-cokey...

Fix checked in.

*** Bug 190632 has been marked as a duplicate of this bug. ***

would this patch fix bug 227742 in Firefox?

I've noticed a similar issue with command events for which I'll file a new bug.

*** Bug 215472 has been marked as a duplicate of this bug. ***