Intent to ship: auxclick

[Navid Zolghadr]

Contact emails
nzol...@chromium.org

Spec
https://navidz.github.io/auxclick/

Summary
The new input event type "auxclick" introduced here provides web developers a way to listen to the click behavior of non-primary buttons, and potentially cancel their effect (eg. opening a new tab when middle clicking on a link). This new input type is needed because the "click" event is restricted to primary button only according to the spec https://w3c.github.io/uievents/#event-type-click. So after this change "click" event will no longer be dispatched for non-primary buttons.

Previous Intents:
Intent to Implement: auxclick

Intent to remove: Non-primary button click event

Motivation
In attempting to remove the click event for non-primary buttons in Chrome as per UI Event Spec it was discovered there is no way for the developers to prevent opening a new tab when the user middle clicks on a link.

Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug
https://crbug.com/625847

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/5663174342737920

Requesting approval to ship?

Yes

[Domenic Denicola]

From: Navid Zolghadr [mailto:nzol...@chromium.org]

> Motivation
> In attempting to remove the click event for non-primary buttons in Chrome as per UI Event Spec it was discovered there is no way for the developers to prevent opening a new tab when the user middle clicks on a link.

Apologies in that I guess this should have been discussed during intent to implement, but why are we adding a new event (without support from other browsers) just to allow web developers to be more hostile to users? When I as a user middle-click on a link, I don't want the website to be able prevent me from opening a new tab. The user agent, acting on my behalf, is being explicitly told I should open in a new tab; that should override any of the web page's wishes.

Combined with the interop risk of this not having other browser support, and the stated "no signals" from web developers, I'm not sure why we're rushing to ship this :-/

[Dave Tapuska]

Domenic you seem to be bring up a point that is fundamental to the web in general. The fact that a web page can prevent the default action and the user doesn't anticipate that. The needs of the web page author and the user predictability needs are at odds and I don't see how we can solve this. Ctrl-Click can also be preventDefaulted which can have the same user predictability frustrations you highlighted.

How will web developers be more hostile towards users? They currently can prevent the click action and it won't open a new tab. In fact we found devtools and chrome UI do this on a number of occasions to cause different actions. So removing the click action on the middle button wholesale felt just wrong because we couldn't write an implementation to meet our own needs.

We want to ship this because it solves a class of problems where a webpage didn't intend to prevent middle click but have prevented it. If you read the spec today it would match when a web developer could implement but it would break new tab opening.

dave.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Domenic Denicola]

From: Dave Tapuska [mailto:dtap...@chromium.org]

> Domenic you seem to be bring up a point that is fundamental to the web in general. The fact that a web page can prevent the default action and the user doesn't anticipate that. The needs of the web page author and the user predictability needs are at odds and I don't see how we can solve this. Ctrl-Click can also be preventDefaulted which can have the same user predictability frustrations you highlighted.

I think the situation is more nuanced than that. There are a number of user gestures which cannot be intercepted and prevented: easy examples include Alt+F4 and Ctrl+Tab, or Esc in fullscreen. In all these cases we have made the decision that the user is unambiguously expressing a preference for a certain action, and that it would be user-hostile for the web page to intercept and preventDefault that action.

There are other cases which are more ambiguous, and if I recall are the subject of certain debate. For example, we recently stopped honoring autocomplete="off", since we believe the user's expressed preference to use autocomplete overrides the needs of the web page author. Similar debates have occurred about making onpaste uncancelable, due to its abuse by web developers in preventing password fields from being pasted into. I can easily see us having a debate in 6 months' time about making auxclick uncancelable as a new "user agent intervention" along these lines.

In general, my argument is based largely on my frustration as a user in trying to open things in a new tab and failing due to poorly-code sites (or malicious web sites that wish to prevent standalone views of certain links). From this perspective, middle-click is such a feature that expresses user intent, and it should get the same treatment as the other privileged shortcuts. (I'd argue that Ctrl+Click is also such a feature!) In other words, we can solve this by acting as the user's agent.

> How will web developers be more hostile towards users? They currently can prevent the click action and it won't open a new tab. In fact we found devtools and chrome UI do this on a number of occasions to cause different actions. So removing the click action on the middle button wholesale felt just wrong because we couldn't write an implementation to meet our own needs.

I think it's fine for parts of the browser with special needs, which are incidentally implemented using web technologies, to get access to special APIs. But I don't think that should mean shipping them to the web at large, especially in this case given the feature's abuse potential and its lack of support or interest ("No signals") from web developers and other browsers.

[Rick Byers]

We can't change our "click" behavior to match the standard without this.  We tried but found that too many valuable use cases were broken, and often these were use cases that weren't at all "web developers being more hostile to users" but actually doing a good job of providing the UX that users wanted (eg. opening in a new tab themselves).

I see the real problem here as not developers TRYING to be hostile to users.  That does happen but it's MUCH more common that developers are accidentally hostile to users by handling "click" without thinking to check the buttons value and so accidentally breaking the middle click scenario.

So yes there's some risk that developers will use this API to annoy users, but that's true of almost every powerful API we add and directly in conflict with the goals of the extensible web.  But in practice I expect it to be a HUGE net win for the user AND for the developer.

Our only real alternative is to keep our non-standard behavior (maybe try to get the spec updated) which results in a LOT of sites accidentally being hostile to users (by breaking the middle-click feature without intending to do so).  

That said, I'd still love to get some signals from the other vendors here.  In informal talks with some Edge folks they seemed to support it, but nothing public AFAIK.

[PhistucK]

Note that even if click stops firing for middle clicks, you can still prevent a new tab (by changing the hRef temporarily on mousedown to javascript:void(0), for example (there are of course more workarounds).

I am not sure auxclick is needed and I am not sure click should fire for middle clicks. The problem is that I am not sure how to explain my opposition to it. It just seems like an overkill, basically, when you have many ways of preventing it anyway.

☆PhistucK

[Navid Zolghadr]

Right now there are two sets of developers concerning this issue. One that forgot to check the button value for click event and they mistakenly do whatever they do (like opening a link in the current page) for middle click as well. You can see they have expressed their opinions here in this bug: https://crbug.com/255 and it seems they are a lot more than the second group. The other set is using click event for middle button legitimately and do some stuff with it. Like closing a tab in Chrome devtools or gathering some metrics when user middle click on a link like the history page in Chrome. Changing the url of the link on mousedown or generating synthetic click event for middle button by listening to mousedown/up are both having some blind spots which will cause some problems for this second group to easily use auxclick event instead of click event.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[John Mellor]

Why is auxclick only for middleclick? It seems weird for the behavior of Ctrl/Cmd+click and middleclick to diverge. And presumably the same arguments about websites accidentally blocking open in new tab also apply to Ctrl/Cmd+click?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Navid Zolghadr]

It is not only for middle button. It is for non-primary buttons. Only that middle button seems to be the most important use case of it right now.

Regarding the behavior we are not changing the default behavior of middle click here. So it will still behave the same. Only the event that we fire for it will have different name. If this didn't answer the second part then I probably mis-understood the second part. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[John Mellor]

I understand. But why won't Ctrl/Cmd+click also fire an auxclick event instead of a click event, since it is usually equivalent to middle-click when clicking links?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Navid Zolghadr]

I can see that the default behavior of the browser in these two different scenarios (i.e. middle click and Ctrl/Cmd+click) are the same but they are still different user actions. The idea at first wasn't about sending an event for a particular default action. It was about exposing what user did with the input device.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

I think the main reason these are different is that the spec (and Firefox, maybe also IE?) send 'click' only for the primary button click.  So to follow the spec as written we need to stop sending click for non-primary buttons.

If we can succeed at making that breaking change, then I could totally imagine following the same logic to propose a spec change to fire "auxclick" instead of "click" when ANY modifiers are pressed.  That's going to be riskier from a compat perspective though since I think all browsers already agree on this - I'm not sure if it's a breaking change we could pull off.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Domenic Denicola]

From: Navid Zolghadr [mailto:nzol...@chromium.org]

> Right now there are two sets of developers concerning this issue. One that forgot to check the button value for click event and they mistakenly do whatever they do (like opening a link in the current page) for middle click as well. You can see they have expressed their opinions here in this bug: https://crbug.com/255 and it seems they are a lot more than the second group. The other set is using click event for middle button legitimately and do some stuff with it. Like closing a tab in Chrome devtools or gathering some metrics when user middle click on a link like the history page in Chrome. Changing the url of the link on mousedown or generating synthetic click event for middle button by listening to mousedown/up are both having some blind spots which will cause some problems for this second group to easily use auxclick event instead of click event.

This phrasing helps me understand that my concern is somewhat separable from the auxclick feature as a whole. In particular, auxclick seems likely to have good use cases: you point out closing a tab in Chrome devtools, and I could imagine this being useful for web authors as well writing similar tabbed UIs. I wish we had web developers expressing these needs that you could cite, instead of "No signals", because right now the use cases you've given can be solved with a privileged API that is not exposed to the web. But it makes sense that web developers at large would benefit from this.

In contrast, my concern is about the specific user gesture of middle clicking on a link. As in my earlier message, I think this is similar to Alt+F4ing a window, or Escing from fullscreen, and should not be cancelable. So I guess my concern would be addressed simply by making auxclick uncancelable when clicking on a link. This would allow auxclick to be used for cases like closing a tab or performing a specific action in a web-based game, but would prevent the overriding of user intent that I am concerned about.

What do you think?

[Rick Byers]

On Fri, Aug 26, 2016 at 1:13 PM, Domenic Denicola <d...@domenic.me> wrote:

From: Navid Zolghadr [mailto:nzol...@chromium.org]

> Right now there are two sets of developers concerning this issue. One that forgot to check the button value for click event and they mistakenly do whatever they do (like opening a link in the current page) for middle click as well. You can see they have expressed their opinions here in this bug: https://crbug.com/255 and it seems they are a lot more than the second group. The other set is using click event for middle button legitimately and do some stuff with it. Like closing a tab in Chrome devtools or gathering some metrics when user middle click on a link like the history page in Chrome. Changing the url of the link on mousedown or generating synthetic click event for middle button by listening to mousedown/up are both having some blind spots which will cause some problems for this second group to easily use auxclick event instead of click event.

This phrasing helps me understand that my concern is somewhat separable from the auxclick feature as a whole. In particular, auxclick seems likely to have good use cases: you point out closing a tab in Chrome devtools, and I could imagine this being useful for web authors as well writing similar tabbed UIs. I wish we had web developers expressing these needs that you could cite, instead of "No signals", because right now the use cases you've given can be solved with a privileged API that is not exposed to the web. But it makes sense that web developers at large would benefit from this.

Navid, weren't some of the bugs that got filed when we tried matching the spec from real-world website with legitimate use cases for customizing middle-click?  If we can point to some examples of developers legitimately wanting to do this (in a way that's not clearly just bad/abusive UX) then that counts as positive developer feedback.

In contrast, my concern is about the specific user gesture of middle clicking on a link. As in my earlier message, I think this is similar to Alt+F4ing a window, or Escing from fullscreen, and should not be cancelable. So I guess my concern would be addressed simply by making auxclick uncancelable when clicking on a link. This would allow auxclick to be used for cases like closing a tab or performing a specific action in a web-based game, but would prevent the overriding of user intent that I am concerned about.

I don't think there's value in worrying about sites who are intentionally trying to cause annoying/hostile UX here.  If the site really doesn't want you to open the link in the new window then they can much more easily do that by using a link with an empty href and doing whatever it is they want in response to raw mouseup/keyboard events.  Or (if there are really reasons to try to make the link appear legitimate) as PhistucK said, temporarily clearing the href in the mouseup handler.  Right?  What specifically are you worried about developers doing that would justify the need for uncancellable events or a privileged API?

[Domenic Denicola]

From: Rick Byers [mailto:rby...@chromium.org]

> I don't think there's value in worrying about sites who are intentionally trying to cause annoying/hostile UX here.  If the site really doesn't want you to open the link in the new window then they can much more easily do that by using a link with an empty href and doing whatever it is they want in response to raw mouseup/keyboard events.  Or (if there are really reasons to try to make the link appear legitimate) as PhistucK said, temporarily clearing the href in the mouseup handler.  Right?  What specifically are you worried about developers doing that would justify the need for uncancellable events or a privileged API?

I am worried more about poorly-coded sites than malicious ones. For example, it is semi-common practice to use `return false` to stop propagation, not realizing that it also cancels the event. Or sites like the aforementioned game which don't realize that they have an "About" link in their footer or help menu, so they preventDefault() all auxclicks as a matter of policy.

[Alex Russell]

I'm not sure we should be designing around specific browser affordances. We are very careful, in general, to avoid standardising UI. If the browser creates an uncancelable behavior, that's up to the browser. I'm not sure it needs any API change; as a result I'm inclined to support auxclick as-is.

Regards

[Jeffrey Yasskin]

I don't think special-casing <a> tags will help much here. Developers who actively want to prevent users from opening a link in a new tab will just use a <span onclick> in that case. 

Jeffrey

[Rick Byers]

Ok, thanks - that helps.  But do developers really do "return false" to try to "stop propagation"?  AFAIK "return false" has only ever canceled the event (without stopping it's propagation).

If "auxclick" really only fires in middle-click scenarios, it's going to be exceedingly rare that a developer bothers to listen to it or even knows about the event in the first place.  Maybe over time there's some risk they just start directing auxclick to their click listener but I have trouble imagining why they'd do that unless they really wanted to handle it differently somehow.

If we expect auxclick to be rare, and "return false" to be a problem, then perhaps we shouldn't define any "onauxclick" properties (since this isn't an issue when using addEventListener)? 

If there's still a problem with developers accidentally canceling events they shouldn't then don't we have a bigger issue?  Either they need the default action (in which case their UX will just be broken when it's canceled - eg. links don't navigate at all), or they don't (in which case NOT cancelling will result in double-handling - eg. opening the link in a new windows AND navigating the original page).  I'm not at all convinced that making the event uncancelable in some situations would be likely to result in a better overall user experience.

 

On Fri, Aug 26, 2016 at 1:43 PM, Alex Russell <sligh...@google.com> wrote:

I'm not sure we should be designing around specific browser affordances. We are very careful, in general, to avoid standardising UI. If the browser creates an uncancelable behavior, that's up to the browser. I'm not sure it needs any API change; as a result I'm inclined to support auxclick as-is.

Thanks Alex! 

Regards

On Friday, August 26, 2016, Domenic Denicola <d...@domenic.me> wrote:

From: Navid Zolghadr [mailto:nzol...@chromium.org]

> Right now there are two sets of developers concerning this issue. One that forgot to check the button value for click event and they mistakenly do whatever they do (like opening a link in the current page) for middle click as well. You can see they have expressed their opinions here in this bug: https://crbug.com/255 and it seems they are a lot more than the second group. The other set is using click event for middle button legitimately and do some stuff with it. Like closing a tab in Chrome devtools or gathering some metrics when user middle click on a link like the history page in Chrome. Changing the url of the link on mousedown or generating synthetic click event for middle button by listening to mousedown/up are both having some blind spots which will cause some problems for this second group to easily use auxclick event instead of click event.

This phrasing helps me understand that my concern is somewhat separable from the auxclick feature as a whole. In particular, auxclick seems likely to have good use cases: you point out closing a tab in Chrome devtools, and I could imagine this being useful for web authors as well writing similar tabbed UIs. I wish we had web developers expressing these needs that you could cite, instead of "No signals", because right now the use cases you've given can be solved with a privileged API that is not exposed to the web. But it makes sense that web developers at large would benefit from this.

In contrast, my concern is about the specific user gesture of middle clicking on a link. As in my earlier message, I think this is similar to Alt+F4ing a window, or Escing from fullscreen, and should not be cancelable. So I guess my concern would be addressed simply by making auxclick uncancelable when clicking on a link. This would allow auxclick to be used for cases like closing a tab or performing a specific action in a web-based game, but would prevent the overriding of user intent that I am concerned about.

What do you think?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

On Fri, Aug 26, 2016 at 8:40 PM, Domenic Denicola <d...@domenic.me> wrote:

For example, it is semi-common practice to use `return false` to stop propagation, not realizing that it also cancels the even

​t​

​Oops - you fell for the jQuery trap. Returning false only stops propagation in jQuery. Regular event listeners must explicitly call event.stopPropagation() (or set event.cancelBubble to true or something).

☆PhistucK

[PhistucK]

On Fri, Aug 26, 2016 at 9:20 PM, Rick Byers <rby...@chromium.org> wrote:

But do developers really do "return false" to try to "stop propagation"?  AFAIK "return false" has only ever canceled the event (without stopping it's propagation).

​The ​jQuery event listeners do that for some reason​ (return false equals stopping the propagation as well as preventing the default action).​

☆PhistucK

[Josh Matthews]

That's not true - the specification dictates that event propagation should be canceled return value of the event handler: https://html.spec.whatwg.org/multipage/webappapis.html#the-event-handler-processing-algorithm

Cheers,

Josh

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Josh Matthews]

Sorry, disregard that. I confused cancellation with propagation.

Cheers,

Josh

[Navid Zolghadr]

On Fri, Aug 26, 2016 at 2:20 PM Rick Byers <rby...@chromium.org> wrote:

On Fri, Aug 26, 2016 at 1:40 PM, Domenic Denicola <d...@domenic.me> wrote:

From: Rick Byers [mailto:rby...@chromium.org]

> I don't think there's value in worrying about sites who are intentionally trying to cause annoying/hostile UX here.  If the site really doesn't want you to open the link in the new window then they can much more easily do that by using a link with an empty href and doing whatever it is they want in response to raw mouseup/keyboard events.  Or (if there are really reasons to try to make the link appear legitimate) as PhistucK said, temporarily clearing the href in the mouseup handler.  Right?  What specifically are you worried about developers doing that would justify the need for uncancellable events or a privileged API?

I am worried more about poorly-coded sites than malicious ones. For example, it is semi-common practice to use `return false` to stop propagation, not realizing that it also cancels the event. Or sites like the aforementioned game which don't realize that they have an "About" link in their footer or help menu, so they preventDefault() all auxclicks as a matter of policy.

Ok, thanks - that helps.  But do developers really do "return false" to try to "stop propagation"?  AFAIK "return false" has only ever canceled the event (without stopping it's propagation).

If "auxclick" really only fires in middle-click scenarios, it's going to be exceedingly rare that a developer bothers to listen to it or even knows about the event in the first place.  Maybe over time there's some risk they just start directing auxclick to their click listener but I have trouble imagining why they'd do that unless they really wanted to handle it differently somehow.

If we expect auxclick to be rare, and "return false" to be a problem, then perhaps we shouldn't define any "onauxclick" properties (since this isn't an issue when using addEventListener)? 

If there's still a problem with developers accidentally canceling events they shouldn't then don't we have a bigger issue?  Either they need the default action (in which case their UX will just be broken when it's canceled - eg. links don't navigate at all), or they don't (in which case NOT cancelling will result in double-handling - eg. opening the link in a new windows AND navigating the original page).  I'm not at all convinced that making the event uncancelable in some situations would be likely to result in a better overall user experience.

Regarding the developer support in case them filing a bug counts towards that I found this one when I was trying to remove click event in my first try a few months back https://crbug.com/611972 which they asked for an alternative for middle button click. Particularly they did want to preventDefault behavior on that alternative way as well.

Regarding the poorly-written websites and "on |event|" handlers, I will gladly remove "onauxclick" from the current implementation. However, that would remove the way developer can do the feature detection for this event. Although they can always add "click" and "auxclick" listeners and do the handling in both but IMHO that doesn’t seem the best approach and keeping the "onauxclick" as is would be better. As for the malicious websites, there are already quite a lot of ways to make a link (or link-like text) not open a new tab I don’t think making it easy (or at least as easy as it was before with "click" event) would hurt the user experience. However, it does help the developers who want to write a clean code and legitimately use the preventDefault behavior of "auxclick". Domenic, does this address your concerns? 

 

On Fri, Aug 26, 2016 at 1:43 PM, Alex Russell <sligh...@google.com> wrote:

I'm not sure we should be designing around specific browser affordances. We are very careful, in general, to avoid standardising UI. If the browser creates an uncancelable behavior, that's up to the browser. I'm not sure it needs any API change; as a result I'm inclined to support auxclick as-is.

Thanks Alex! 

Regards

On Friday, August 26, 2016, Domenic Denicola <d...@domenic.me> wrote:

From: Navid Zolghadr [mailto:nzol...@chromium.org]

> Right now there are two sets of developers concerning this issue. One that forgot to check the button value for click event and they mistakenly do whatever they do (like opening a link in the current page) for middle click as well. You can see they have expressed their opinions here in this bug: https://crbug.com/255 and it seems they are a lot more than the second group. The other set is using click event for middle button legitimately and do some stuff with it. Like closing a tab in Chrome devtools or gathering some metrics when user middle click on a link like the history page in Chrome. Changing the url of the link on mousedown or generating synthetic click event for middle button by listening to mousedown/up are both having some blind spots which will cause some problems for this second group to easily use auxclick event instead of click event.

This phrasing helps me understand that my concern is somewhat separable from the auxclick feature as a whole. In particular, auxclick seems likely to have good use cases: you point out closing a tab in Chrome devtools, and I could imagine this being useful for web authors as well writing similar tabbed UIs. I wish we had web developers expressing these needs that you could cite, instead of "No signals", because right now the use cases you've given can be solved with a privileged API that is not exposed to the web. But it makes sense that web developers at large would benefit from this.

In contrast, my concern is about the specific user gesture of middle clicking on a link. As in my earlier message, I think this is similar to Alt+F4ing a window, or Escing from fullscreen, and should not be cancelable. So I guess my concern would be addressed simply by making auxclick uncancelable when clicking on a link. This would allow auxclick to be used for cases like closing a tab or performing a specific action in a web-based game, but would prevent the overriding of user intent that I am concerned about.

What do you think?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Domenic Denicola]

From: Navid Zolghadr [mailto:nzol...@chromium.org]

> Regarding the developer support in case them filing a bug counts towards that I found this one when I was trying to remove click event in my first try a few months back https://crbug.com/611972 which they asked for an alternative for middle button click. Particularly they did want to preventDefault behavior on that alternative way as well.
Regarding the poorly-written websites and "on |event|" handlers, I will gladly remove "onauxclick" from the current implementation. However, that would remove the way developer can do the feature detection for this event. Although they can always add "click" and "auxclick" listeners and do the handling in both but IMHO that doesn’t seem the best approach and keeping the "onauxclick" as is would be better. As for the malicious websites, there are already quite a lot of ways to make a link (or link-like text) not open a new tab I don’t think making it easy (or at least as easy as it was before with "click" event) would hurt the user experience. However, it does help the developers who want to write a clean code and legitimately use the preventDefault behavior of "auxclick". Domenic, does this address your concerns? 

No, I think consistency is more important, and we should keep onauxclick.

My concerns would be addressed if we treated middle-clicking on a link as a uncancelable gesture similar to Ctrl+Tab. This is further supported by https://crbug.com/611972 where the developer seems to be trying to override user intent. I disagree that making it easy has no impact; a determined developer can always find a way, but ensuring they realize they're hacking around user intent using ugly code usually makes a difference, in my experience. But it seems like I don't have a lot of support in that preference.

(FWIW I agree with Alex that that isn't something we should necessarily standardize, just like the uncancelability of Ctrl+Tab is not standardized. I'd still prefer we implement it though.)

[PhistucK]

Do you prefer that developers use auxclick on a <span> instead of on an <a> (the easiest solution to your restriction, I think)?

Yes, it might be considered "ugly" by you, but this "ugliness" also has accessibility consequences. Since accessibility is already in a bad shape in terms of developer support, I do not think you should exacerbate it using the likes of non-cancellable link behavior.

☆PhistucK

[Dimitri]

Have y'all settled down on something? If not, a VC might be easier to iron the remaining bits.

:DG<

[Domenic Denicola]

From: Dimitri [mailto:dgla...@chromium.org]

> Have y'all settled down on something? If not, a VC might be easier to iron the remaining bits.

I'm happy to do that if people think it would be helpful, but my impression is that people have kind of said their piece, and my position doesn't have a lot of support, so it's probably best to for me to just let it go. My objection is "on record" and I'm happy if Navid, Dave, Rick, and others (including the API owners) have taken it into consideration---even if they don't agree with me on the ultimate conclusion of what should be done :).

[Rick Byers]

Maybe we should ask a slightly different question: if we later learn that you're right (that the user experience would be improved by making auxclick uncancelable in some cases), would it be almost as good to launch an intervention at that time which changed the behavior as your suggest?

The compat risk of that change seems much lower to me than the risk of the compat change we're doing now, so I'm personally pretty comfortable just deferring this concern until such time that we have real world data (rather than trying to guess about what developers may or may not do).  WDYT?

[Chris Harrelson]

LGTM1 to ship. If we see enough abuse of middle click in the future, we could consider not allowing preventing default actions on it as an intervention.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dimitri Glazkov]

LGTM2.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

On Tue, Aug 30, 2016 at 2:55 PM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM1 to ship. If we see enough abuse of middle click in the future, we could consider not allowing preventing default actions on it as an intervention.

+1

[Philip Jägenstedt]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Domenic Denicola]

From: Rick Byers [mailto:rby...@chromium.org]

> Maybe we should ask a slightly different question: if we later learn that you're right (that the user experience would be improved by making auxclick uncancelable in some cases), would it be almost as good to launch an intervention at that time which changed the behavior as your suggest?
>
> The compat risk of that change seems much lower to me than the risk of the compat change we're doing now, so I'm personally pretty comfortable just deferring this concern until such time that we have real world data (rather than trying to guess about what developers may or may not do).  WDYT?

"Almost as good" sounds about right :). I think this is a good plan; thank you for taking the time to work through these things with me!

[Rick Byers]

Great, thank you for your feedback Domenic!   Big picture I think our goals are all exactly aligned here - improve the user experience (1st) while giving developers a more predictable and powerful platform (2nd).  So these issues are definitely worth debating...