Intent to remove: Non-primary button click event

[Navid Zolghadr‏]

Primary eng (and PM) emails

nzol...@chromium.org, dtap...@chromium.org

Summary

Remove dispatching the click and dblclick event to js for non-primary mouse buttons.

Motivation

It’s been some time since the spec (https://w3c.github.io/uievents/#event-type-click) was updated to make the click event a primary button event only. This was discussed in 2013 https://lists.w3.org/Archives/Public/www-dom/2013JulSep/0256.html and the desired behaviour was specified but no change was landed for Chromium.

Comments

Since a question was asked on blink-dev here; the specified behaviour removes non-primary button click event dispatched to js regardless of the target.

Compatibility Risk

FireFox does not dispatch click event for non-primary buttons.

Edge does still dispatch click event for middle button.

This action practically hides any action that was done in js as the result of listening to click event of non primary buttons (specially middle click). Particularly the functionality of preventDefault on click event for middle click on link which prevents opening a new tab is no longer possible.

OWP launch tracking bug

https://crbug.com/255

Requesting approval to remove too?

Yes, M52 is the suggested milestone. (This change prematurely got in and we are ready to revert it back if there was any objection)

[Chris Harrelson‏]

LGTM1

--
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.

[Dimitri Glazkov‏]

LGTM2

:DG<

[Jacob Rossi‏]

I opened up an issue to look at aligning Edge to this behavior as well:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7374816/

[PhistucK‏]

You forgot to mention that WebKit apparently behaves as old-Blink.

Have you tried reaching out to them? Can the Blink patch be easily ported to WebKit (that might help them get it prioritized)?

I think the risk should be measured somehow. How many pages have click events fired for non primary buttons?

Since you will be concealing functionality as a result of this change, this may have some usability effects.

The fact that Edge implemented it (but not Internet Explorer) tends to show it was needed (or maybe it simply made more sense to the Edge engineers all of a sudden). I realize Jacob itself filed an issue for Edge. If all of the browsers aligned on this at around the same time (Safari has somewhat more frequent releases nowadays), it would be a safer change to make.

☆PhistucK

[Domenic Denicola‏]

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

> This action practically hides any action that was done in js as the result of listening to click event of non primary buttons (specially middle click). Particularly the functionality of preventDefault on click event for middle click on link which prevents opening a new tab is no longer possible.

As a user, this makes me so happy. One of the most frustrating things about using Chrome instead of Firefox is that middle-clicking does not always work for opening in a new tab in Chrome. It's very exciting that this is being fixed.

[Rick Byers‏]

LGTM3

On Thu, Apr 28, 2016 at 2:19 PM, PhistucK <phis...@gmail.com> wrote:

You forgot to mention that WebKit apparently behaves as old-Blink.

Have you tried reaching out to them? Can the Blink patch be easily ported to WebKit (that might help them get it prioritized)?

Filing a bug on WebKit is a good idea.  Though I suspect they're unlikely to move until we've successfully shipped and shown that there isn't compat impact in practice.

I think the risk should be measured somehow. How many pages have click events fired for non primary buttons?

Since you will be concealing functionality as a result of this change, this may have some usability effects.

I think this is really hard to measure.  There will be lots of examples where such a click event is handled and even canceled (the exact frustration Domenic was expressing).  But I don't see any way to detect the cases where this might actually violate the developer's intent (instead of better match it).

The fact that Edge implemented it (but not Internet Explorer) tends to show it was needed (or maybe it simply made more sense to the Edge engineers all of a sudden). I realize Jacob itself filed an issue for Edge. If all of the browsers aligned on this at around the same time (Safari has somewhat more frequent releases nowadays), it would be a safer change to make.

I don't really buy the "safety" argument - unless we're talking about safer for our reputation.  But what I think we care most about is the overall web platform, and in that case it's really "safer" for one browser to go first and the others to learn from it.

Still the fact that Edge copied Chrome here is indeed significant.  Jacob, any chance you could did up data on why this was important for you guys?  At a minimum it would be good to have an idea of what might break, what level of outreach we should be doing, etc.

 

On Thu, Apr 28, 2016 at 11:58 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

LGTM2

:DG<

On Thu, Apr 28, 2016 at 8:57 AM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM1

On Thu, Apr 28, 2016 at 8:29 AM Navid Zolghadr <nzol...@chromium.org> wrote:

Primary eng (and PM) emails

nzol...@chromium.org, dtap...@chromium.org

Summary

Remove dispatching the click and dblclick event to js for non-primary mouse buttons.

Motivation

It’s been some time since the spec (https://w3c.github.io/uievents/#event-type-click) was updated to make the click event a primary button event only. This was discussed in 2013 https://lists.w3.org/Archives/Public/www-dom/2013JulSep/0256.html and the desired behaviour was specified but no change was landed for Chromium.

Comments

Since a question was asked on blink-dev here; the specified behaviour removes non-primary button click event dispatched to js regardless of the target.

Compatibility Risk

FireFox does not dispatch click event for non-primary buttons.

Edge does still dispatch click event for middle button.

IE also doesn't, right?

This action practically hides any action that was done in js as the result of listening to click event of non primary buttons (specially middle click). Particularly the functionality of preventDefault on click event for middle click on link which prevents opening a new tab is no longer possible.

OWP launch tracking bug

https://crbug.com/255

I've changed this to an OWP tracking bug so people looking for removals in M52 will find it.  Can you also please file a chromestatus.com entry?  I think it's possible some developer somewhere will want to know about this, so we should ensure this is visible (and makes it into the M52 blog post, etc.).

[Peter Kasting‏]

On Thu, Apr 28, 2016 at 11:58 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Apr 28, 2016 at 2:19 PM, PhistucK <phis...@gmail.com> wrote:

You forgot to mention that WebKit apparently behaves as old-Blink.

Have you tried reaching out to them? Can the Blink patch be easily ported to WebKit (that might help them get it prioritized)?

Filing a bug on WebKit is a good idea.  Though I suspect they're unlikely to move until we've successfully shipped and shown that there isn't compat impact in practice.

https://bugs.webkit.org/show_bug.cgi?id=22382 has been open there for many years now and is probably the right place to push on this.

PK 

[Navid Zolghadr‏]

No. IE (11 I believe it was I tested with) also does fire click event for middle button.

 

This action practically hides any action that was done in js as the result of listening to click event of non primary buttons (specially middle click). Particularly the functionality of preventDefault on click event for middle click on link which prevents opening a new tab is no longer possible.

OWP launch tracking bug

https://crbug.com/255

I've changed this to an OWP tracking bug so people looking for removals in M52 will find it.  Can you also please file a chromestatus.com entry?  I think it's possible some developer somewhere will want to know about this, so we should ensure this is visible (and makes it into the M52 blog post, etc.).

Sure. 

[PhistucK‏]

That WebKit bug has an interesting comment -

"Just to complicate things, it seems that Gecko actually fires click for all click types on listeners attached to document or window."

Does the specification say that it should? Is it a Gecko quirk? Should everyone align to that?

☆PhistucK

[Navid Zolghadr‏]

I haven't seen such a thing in the spec. At least it didn't catch my eyes.

In the case of document, FF not only sends the click event to the document for middle button but also for right click. Not sure how they got this behavior though.

[Rick Byers‏]

Hey Olli, can you help us understand the motivation for Gecko's click event behavior on the document for middle button?  We're trying to finally be spec compliant on middle-click behavior, but a little nervous about compat.

[smaug‏]

Motivation is historical.
Documented in the relevant w3c bugs... trying to find it.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23240#c13
https://bugzilla.mozilla.org/show_bug.cgi?id=71705#c50

The comment in mozilla bugzilla is old and wrong, since there is contextmenu event for right click at least (though, one can trigger contextmenu also
using keyboard)


It is clear that click can't be dispatched to links and such, I guess elements in general, but Gecko's behavior hasn't been causing tons of issues
otherwise. Perhaps, I'm not really even proposing this, just thinking, the spec could define Gecko's behavior if people thing middle/right clicks are
important? Or do we need middleclick and rightclick events? Separate events would be safer.



-Olli

On 04/29/2016 11:10 AM, Rick Byers wrote:
> Hey Olli, can you help us understand the motivation for Gecko's click event behavior on the document for middle button? We're trying to finally be
> spec compliant on middle-click behavior, but a little nervous about compat.
>

> On Apr 28, 2016 10:30 PM, "Navid Zolghadr" <nzol...@chromium.org <mailto:nzol...@chromium.org>> wrote:
>
> I haven't seen such a thing in the spec. At least it didn't catch my eyes.
> In the case of document, FF not only sends the click event to the document for middle button but also for right click. Not sure how they got this
> behavior though.
>

> On Thu, Apr 28, 2016 at 5:57 PM PhistucK <phis...@gmail.com <mailto:phis...@gmail.com>> wrote:
>
> That WebKit bug has an interesting comment <https://bugs.webkit.org/show_bug.cgi?id=22382#c89> -

> "Just to complicate things, it seems that Gecko actually fires click for all click types on listeners attached to document or window."
> Does the specification say that it should? Is it a Gecko quirk? Should everyone align to that?
>
>

> ☆*PhistucK*
>
> On Thu, Apr 28, 2016 at 10:35 PM, Navid Zolghadr <nzol...@chromium.org <mailto:nzol...@chromium.org>> wrote:

>
>
>
> On Thu, Apr 28, 2016 at 2:59 PM Rick Byers <rby...@chromium.org <mailto:rby...@chromium.org>> wrote:
>
> LGTM3
>

> On Thu, Apr 28, 2016 at 2:19 PM, PhistucK <phis...@gmail.com <mailto:phis...@gmail.com>> wrote:
>
> You forgot to mention that WebKit apparently behaves as old-Blink.
> Have you tried reaching out to them? Can the Blink patch be easily ported to WebKit (that might help them get it prioritized)?
>
>
> Filing a bug on WebKit is a good idea. Though I suspect they're unlikely to move until we've successfully shipped and shown that
> there isn't compat impact in practice.
>
> I think the risk should be measured somehow. How many pages have click events fired for non primary buttons?
> Since you will be concealing functionality as a result of this change, this may have some usability effects.
>
>
> I think this is really hard to measure. There will be lots of examples where such a click event is handled and even canceled (the
> exact frustration Domenic was expressing). But I don't see any way to detect the cases where this might actually violate the
> developer's intent (instead of better match it).
>
> The fact that Edge implemented it (but not Internet Explorer) tends to show it was needed (or maybe it simply made more sense to
> the Edge engineers all of a sudden). I realize Jacob itself filed an issue for Edge. If all of the browsers aligned on this at
> around the same time (Safari has somewhat more frequent releases nowadays), it would be a safer change to make.
>
>
> I don't really buy the "safety" argument - unless we're talking about safer for our reputation. But what I think we care most about
> is the overall web platform, and in that case it's really "safer" for one browser to go first and the others to learn from it.
>

> Still the fact that Edge copied Chrome here is indeed significant. *Jacob*, any chance you could did up data on why this was important

> for you guys? At a minimum it would be good to have an idea of what might break, what level of outreach we should be doing, etc.

> On Thu, Apr 28, 2016 at 11:58 AM, Dimitri Glazkov <dgla...@chromium.org <mailto:dgla...@chromium.org>> wrote:
>
> LGTM2
>
> :DG<
>

> On Thu, Apr 28, 2016 at 8:57 AM, Chris Harrelson <chri...@chromium.org <mailto:chri...@chromium.org>> wrote:
>
> LGTM1
>

> On Thu, Apr 28, 2016 at 8:29 AM Navid Zolghadr <nzol...@chromium.org <mailto:nzol...@chromium.org>> wrote:
>
> Primary eng (and PM) emails
>

> nzol...@chromium.org <mailto:nzol...@chromium.org>, dtap...@chromium.org <mailto:dtap...@chromium.org>

>
>
> Summary
>
> Remove dispatching the click and dblclick event to js for non-primary mouse buttons.
>
>
> Motivation
>
> It’s been some time since the spec (https://w3c.github.io/uievents/#event-type-click) was updated to make the click event
> a primary button event only. This was discussed in 2013

> https://lists.w3.org/Archives/Public/www-dom/2013JulSep/0256.htmland the desired behaviour was specified but no change was

> landed for Chromium.
>
>
> Comments
>
> Since a question was asked on blink-dev here

> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/U6rYZLUYFmA/FGIym_sTAQAJ>; the specified behaviour removes

> non-primary button click event dispatched to js regardless of the target.
>
>
> Compatibility Risk
>
> FireFox does not dispatch click event for non-primary buttons.
>
> Edge does still dispatch click event for middle button.
>
>
> IE also doesn't, right?
>
>

> No. IE (11 I believe it was I tested with) also *does* fire click event for middle button.

>
>
> This action practically hides any action that was done in js as the result of listening to click event of non primary
> buttons (specially middle click). Particularly the functionality of preventDefault on click event for middle click on link
> which prevents opening a new tab is no longer possible.
>
>
> OWP launch tracking bug
>
> https://crbug.com/255
>
>
> I've changed this to an OWP tracking bug so people looking for removals in M52 will find it. Can you also please file a

> chromestatus.com <http://chromestatus.com> entry? I think it's possible some developer somewhere will want to know about this, so we

> should ensure this is visible (and makes it into the M52 blog post, etc.).
>
>
> Sure.
>
>
>
> Requesting approval to remove too?
>
> Yes, M52 is the suggested milestone. (This change prematurely got in and we are ready to revert it back if there was any
> objection)
>
>
>
> --
> 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

> <mailto: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

> <mailto:blink-dev+...@chromium.org>.
>
>

[Rick Byers‏]

Thanks Olli.

Most of the concerns in that w3c thread don't seem to apply to at least blink's current implementation:

• Determining when to consider a mouseup a 'click': we fire 'click' on basically every 'mouseup' so there's no system-defined behavior here that you need to emulate.
• Determining when to consider a mouseup a 'dblclick': as required by UI Events, we include the current 'click count' in the 'detail' field, so you can still just watch for 'mouseup detail=2'

Anyway it sounds like this is likely safe enough these days (with most users using laptops without any middle-click mechanism) that we should just proceed with giving this a try and seeing if anything breaks.  The input team does a great job with incoming bug triage, so I'm sure they'll hear of any complaints and can follow up here.

[thecm...@gmail.com‏]

I couldn't find bugs that made us make this change to match Chrome. We really prefer the only primary-button approach. Our change to only fire for primary is currently in code review and   I expect we'll see this in preview builds in the coming weeks, so we'll see if there's any alarming fall out.

[PhistucK‏]

This is apparently breaking internal usages (middle click to close a tab within the Sources panel in the Developer Tools feature, middle click to open a Chrome application in chrome://apps). Obviously, this is not important because this can (and should) be fixed internally and definitely not block shipping this.

But - this does make me wonder whether this is used in the wild, but simply in enterprise applications (which usually do not enable UseCounters) or any other application that uses closable tabs using that middle click shortcut.

Perhaps this needs a use counter (again, it will not be super helpful without enterprise applications, but it will give some initial results to evaluate some risk).

☆PhistucK

[PhistucK‏]

Extensions are also affected and are easier to notify. Can you search the web store internally for possibly affected code (here is a basic regular expression - button\s*===?\s*1) and notify extension authors?

☆PhistucK

[Navid Zolghadr‏]

As I mentioned it is not only about the event itself. It is also about removing the functionality of preventing a new tab to open.

It seems that Gecko does send the click event to the document but to none of the elements inside. I believe that way js can prevent opening a new tab if they prevent default on that. Although this is not quite matching what spec outlines. Olli can you elaborate on that? Was firing click event for document intentional for this purpose or is it just a bug?

Having the prevent default behavior in mind, does it make sense to maybe create a non-primary click (maybe alternateclick or something) event as well to fire for all non-primary keys? Note that the contextmenu event does not only belong to the right click. It can be fired also as the result of the keyboard menu option. So in that sense this alternateclick does not quite interfere with that one.

[smaug‏]

On 05/16/2016 11:16 PM, Navid Zolghadr wrote:
> As I mentioned it is not only about the event itself. It is also about removing the functionality of preventing a new tab to open.
> It seems that Gecko does send the click event to the document but to none of the elements inside. I believe that way js can prevent opening a new tab
> if they prevent default on that. Although this is not quite matching what spec outlines. Olli can you elaborate on that? Was firing click event for
> document intentional for this purpose or is it just a bug?

As the link I gave earlier in this thread indicates, the behavior is intentional, but ancient.
The idea was, as far as I see, that clicking links using middle/right buttons wouldn't trigger the link, but page could still access also those click
events if it had listener on window/document level.
(The behavior was implemented before Netscape or Mozilla Suite even had tabs.)

And preventing tabs to open... well that wouldn't be any different to prevent ctrl+click to open a new tab.

>
> Having the prevent default behavior in mind, does it make sense to maybe create a non-primary click (maybe alternateclick or something) event as well
> to fire for all non-primary keys? Note that the contextmenu event does not only belong to the right click. It can be fired also as the result of the
> keyboard menu option. So in that sense this alternateclick does not quite interfere with that one.
>

> On Mon, May 16, 2016 at 2:09 AM PhistucK <phis...@gmail.com <mailto:phis...@gmail.com>> wrote:
>
> Extensions are also affected <http://crbug.com/611972> and are easier to notify. Can you search the web store internally for possibly affected

> code (here is a basic regular expression - button\s*===?\s*1) and notify extension authors?
>
>

> ☆*PhistucK*

>
> On Sat, May 7, 2016 at 10:15 AM, PhistucK <phis...@gmail.com <mailto:phis...@gmail.com>> wrote:
>
> This is apparently breaking internal usages (middle click to close a tab within the Sources panel in the Developer Tools feature, middle click
> to open a Chrome application in chrome://apps). Obviously, this is not important because this can (and should) be fixed internally and
> definitely not block shipping this.
>
> But - this does make me wonder whether this is used in the wild, but simply in enterprise applications (which usually do not enable
> UseCounters) or any other application that uses closable tabs using that middle click shortcut.
>
> Perhaps this needs a use counter (again, it will not be super helpful without enterprise applications, but it will give some initial results
> to evaluate some risk).
>
>

> ☆*PhistucK*

>
> On Wed, May 4, 2016 at 9:09 PM, <thecm...@gmail.com <mailto:thecm...@gmail.com>> wrote:
>
>
>
> On Tuesday, May 3, 2016 at 12:21:57 PM UTC-7, Rick Byers wrote:
>
> Thanks Olli.
>
> Most of the concerns in that w3c thread don't seem to apply to at least blink's current implementation:
>

> * Determining when to consider a mouseup a 'click': we fire 'click' on basically every 'mouseup' so there's no system-defined

> behavior here that you need to emulate.

> * Determining when to consider a mouseup a 'dblclick': as required by UI Events, we include the current 'click count' in the

> chromestatus.com <http://chromestatus.com> <http://chromestatus.com> entry? I think it's possible some developer somewhere