Issue is reproducible on the latest canary(52.0.2723.0) on Mac OS 10.11.4,Win 7 and Ubuntu 14.04.

I don't think reverting the change for not sending middle click event is the right approach. We are now just following the spec in Chrome. Is this something that can be fixed in chrome://apps page?

Since this app is doing an explicit check for the middle button on the other side of the chrome.send('launchApp'...) is it not possible to track the mouse down and see if the mouse up target is the same and then do this action there?

This  is the first report of something we've seen that is explicitly testing for middle button click and doing something explicitly (as opposed to something unexpectedly as we were trying to address in removing the click on the non-primary buttons as per the spec)

Can someone from the NTP weigh in on this?

Able to see this issue on windows 7 using chrome latest version 52.0.2730.0.
could any one please look into this issue.

Thanks,

I have started looking at this and uploaded a patch. I just forgot to update the status here. Sorry about that.

just to update, able to reproduce the issue on Win7, Mac OSX 10.11.4, Ubuntu 14.04 using Chrome Canary #52.0.239.0

Thanks for the update. Hope the fix will be available soon as we are planning to promote M52 to Beta to during the last week of May.

I'm hoping the same. dbeam@ is reviewing the change.

Still able to reproduce the issue on Windows 7, Mac 10.11.5, Ubuntu 14.04 using 52.0.2743.3.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/88eb1110baafcba070e750866a343e81b6bcc524

commit 88eb1110baafcba070e750866a343e81b6bcc524
Author: nzolghadr <nzolghadr@chromium.org>
Date: Tue May 24 21:55:53 2016

Dispatch middle click manually by tracking mouse

Tracking targets for middle button mousedown event
and fire click event for it on mouse up if necessary.

Note: The click is not finding the common parent of
mousedown and up targets for simplicty and only sends
the click to the target if both down and up happened
on the same node.

BUG= 608697 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/1963823002
Cr-Commit-Position: refs/heads/master@{#395707}

[modify] https://crrev.com/88eb1110baafcba070e750866a343e81b6bcc524/chrome/browser/resources/ntp4/new_tab.html
[add] https://crrev.com/88eb1110baafcba070e750866a343e81b6bcc524/chrome/browser/resources/ntp4/synthetic_middleclick.js

This change just landed. Let me know if you see this problem again.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Tested this issue on Windows 7, Ubuntu 14.04 and Mac OS 10.11.4 using chrome latest canary M53-53.0.2751.0 and observed middle clicking on the app page is able to open it in a new tab as expected. Hence adding TE-Verified label.

Deleted: MouseMiddleClick.mp4 686 KB

MouseMiddleClick.mp4 686 KB Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d43781be25ba16cb8a8be67a64a32d6991bb53d

commit 4d43781be25ba16cb8a8be67a64a32d6991bb53d
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Mon May 30 15:55:42 2016

Dispatch middle click manually by tracking mouse

Tracking targets for middle button mousedown event
and fire click event for it on mouse up if necessary.

Note: The click is not finding the common parent of
mousedown and up targets for simplicty and only sends
the click to the target if both down and up happened
on the same node.

BUG= 608697 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/1963823002
Cr-Commit-Position: refs/heads/master@{#395707}
(cherry picked from commit 88eb1110baafcba070e750866a343e81b6bcc524)

Review URL: https://codereview.chromium.org/2027453002 .

Cr-Commit-Position: refs/branch-heads/2743@{#126}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/4d43781be25ba16cb8a8be67a64a32d6991bb53d/chrome/browser/resources/ntp4/new_tab.html
[add] https://crrev.com/4d43781be25ba16cb8a8be67a64a32d6991bb53d/chrome/browser/resources/ntp4/synthetic_middleclick.js

Merged in 52.

Verified the issue on Windows 7, Ubuntu 14.04 and Mac OS 10.11.4 using chrome latest Dev M52-52.0.2743.19 and observed the fix is working fine as expected on M52 as well. Hence adding TE-Verified label.

The "click" event is no longer dispatched for non-primary buttons as per UI events spec. This will ensure the pages that don't check the buttons attribute on their click handlers don't show unexpected behaviors when middle clicking for example.
Instead there will be new event "auxclick" event for non-primary buttons that will be useful for some apps that truly care about click action for non-primary buttons. For example in case someone wants to prevent opening a new tab when middle clicking a link or adobt any other actions on click behavior of any non-primary button. Here is the spec for the event and some examples:
https://navidz.github.io/auxclick/