[Webkit-unassigned] [Bug 22382] Middle click fires onclick event

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Jun 13 14:08:26 PDT 2010


Adam Barth <abarth at webkit.org> changed:

           What    |Removed                     |Added
                 CC|                            |darin at apple.com

--- Comment #26 from Adam Barth <abarth at webkit.org>  2010-06-13 14:08:21 PST ---
> For our internal convenience we have decided to retain an internal-only click event for middle clicks. And we are now creating such an event for right clicks.

Yes.  I didn't see another technical solution.  The events remain, they just aren't dispatched to the DOM because that confuses sites into doing dumb things and is different from Gecko (note that these two facts are likely related).

> To me, it seems unfortunate to do so and we may want to consider another way of handling that in the future. It seems confusing to have a click event that is used internally that is otherwise the same as the click events that go to the DOM. Is there really a need to create these click events and block them at the event dispatch level?

I don't see another way to fix this bug, but I'm open to suggestions.  The problem is that current WebKit clients have behavior we want to retain as the default event handler for these events.  If we don't create an event, I'm not sure how to call the proper default event handler.

Note that Eric tried to fix this bug a couple years ago at the higher level but couldn't quite come up with a working solution.

> I think that having this down here at the Node level is unfortunate layering. I'd like to see the code that creates the click event do this instead and it seems that the existing code for right click was at that more appropriate higher level; I suppose it was inelegant to have that in two places in EventHandler, but that code could have been refactored instead of moving the code down here.

I tried to extend the code for handling right-click to handle middle-click, but I couldn't get the right behavior.  I posted the patch for review a month ago, so I've forgotten the details by now.

> The code here makes it clear to me that dispatchEventToDefaultEventHandler should be named dispatchEventToDefaultEventHandlerOnly. One of the reasons for that is that the function is not used in the normal dispatch code path. The sole reason for its existence is to have a code path that simulates event dispatch but only sends the event to the default event handler. It's not the "dispatch to default event handler" part of the normal dispatch machinery.

Well, that and it removes a nasty goto that's simulating a function call return address.  :)

> I’m going to say review-. Why do we need click events at all for middle clicks? Can’t we fix this at the EventHandler level?

I'm open to suggestions for how to do that.  I'm certainly not an expert at the event code and could be missing how to get that done.  I bet we could do it by breaking all existing clients that handle middle-click via default events, but that sounds like a bad idea.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list