[Webkit-unassigned] [Bug 46733] REGRESSION (r67261): Middle-mouse-release opens links regardless of "press" location

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=46733





--- Comment #11 from Peter Kasting <pkasting at google.com>  2010-09-28 12:07:59 PST ---
(In reply to comment #9)
> Personally, I think Firefox' handling is the most sane.

I talked some to Erik Arvidsson (JS hacker extraordinaire) about this and after some reflection he agreed that Firefox' behavior is the best route to go.

* For maximum web compat, we probably want to match Gecko.  It's far more likely people rely on its behavior than on Opera's, and because IE has historically had such different event handling, authors are likely to have separate codepaths for IE and everyone else for cases where behaviors differ.

* Gecko's behavior is the most consistent with other types of events.  Textareas don't add text when given artificial keydown/keyup/keypress events; focus doesn't change by firing an artificial focus event.  In general, as I noted in comment 8, having a behavior that causes an event doesn't mean you can create that event to cause that behavior.

* Opera's behavior is buggy anyway.  Even if we wanted to match them, they're not checking the button number on artificially-created click events.

So we'd need to change our behavior as such:
* Links are not opened in response to DOM click events.  Instead, they're opened directly in response to UI actions such as clicks and keypresses.
* For left-clicks, we need to process the DOM click event first, so that if it is default-prevented, we do not open the link.

(In reply to comment #10)
> Generally speaking, if preventDefault needs to prevent something, but that something should not be done in response to that event if it is DOM-created, then we need to either:
> 
>     1) Put some hidden state on the “real” event so that the defaultEventHandler function can tell what to do.
> 
>     2) Put the code to implement the behavior at the call site that sends the event rather than in the defaultEventHandler function. But to prevent EventHandler from becoming a giant god class we still may want to involve some virtual functions on the element involved.

I initially thought of #2, but you're right, #1 would work too.  We can't use the existing fromUserGesture() function because that just tells us whether we're in the chain of functionality triggered by a user event, meaning a click on one element could call a handler function that generates a click on a different element, and we'd go ahead and navigate.  I tested Firefox to make sure that in this case it still doesn't navigate links.

> There may possibly be a way to construct tests that could tell the difference between (1) and (2).

If we do it right, I can't imagine any way.  But as I said, JS is far from my strong suit.

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