Dispatch middle click manually by tracking mouse

chrome/browser/resources/ntp4/synthetic_middleclick.js

Index: chrome/browser/resources/ntp4/synthetic_middleclick.js
diff --git a/chrome/browser/resources/ntp4/synthetic_middleclick.js b/chrome/browser/resources/ntp4/synthetic_middleclick.js
new file mode 100644
index 0000000000000000000000000000000000000000..affb01ebe0cff9f0f492b105d3b97af0043565b1
--- /dev/null
+++ b/chrome/browser/resources/ntp4/synthetic_middleclick.js
@@ -0,0 +1,17 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+var middleButtonMouseDownTarget = null;

[Dan Beam, 2016/05/24 01:57:31]

wrap this in:

(function() {

... code ...

})();

[Navid Zolghadr, 2016/05/24 17:51:14]

Done.

+document.addEventListener('mousedown', function(e) {
+  if (e.button == 1) {

[Dan Beam, 2016/05/24 01:57:32]

no curlies

[Navid Zolghadr, 2016/05/24 17:51:14]

Done.

+    middleButtonMouseDownTarget = e.target;
+  }
+}, true);
+document.addEventListener('mouseup', function(e) {
+  if (e.button == 1) {
+    if (e.target == middleButtonMouseDownTarget)

[Dan Beam, 2016/05/24 01:57:32]

how does this work with shadow DOM?  should you be using e.path[0]?

[Navid Zolghadr, 2016/05/24 17:51:14]

I don't think there is any shadow DOM here in this page. But I changed it to
what you are suggesting anyway to make it more generic.

+      e.target.dispatchEvent(new MouseEvent('click', e));
+    middleButtonMouseDownTarget = null;
+  }
+}, true);

[Dan Beam, 2016/05/12 02:06:24]

both of our code has all kind of things wrong with it (shadow DOM, that events
can be simulated, etc.), but this looks mildly better

document.addEventListener('mousedown', function(e) {
  if (e.button != 1)
    return;

  var mousedownElement = e.target;

  document.addEventListener('mouseup', function f(e) {
    document.removeEventListener('mouseup', f);

    if (e.button == 1 && e.target == mousedownElement)
      e.target.dispatchEvent(new MouseEvent('click', e));
  }, true);
}, true);

[dtapuska, 2016/05/12 02:12:50]

Won't this dispatch two click events if the mouse up doesn't if the mouse leaves
the window and comes back in with the mouse button released; but a mouse down/up
occur on the same element at a later time?

[Navid Zolghadr, 2016/05/12 13:56:01]

Yes, I believe Dave is right. Dan, your solutions adds multiple listeners in
similar scenarios as well. Even if users doesn't leave the icon while pressed as
Dave said, if they only middle click the first time as the current tab doesn't
change they can go back to this tab and middle click again on the same icon and
that scenario also adds multiple listeners.

[Dan Beam, 2016/05/12 18:59:05]

mousing up outside of the window still dispatches a mouseup event for me on
Linux (tested before I sent this)

[Dan Beam, 2016/05/12 19:08:21]

obviously it's possible some other listener stops the immediate propagation and
handles this earlier.

and yes, I'm not totally sure you'll get a mouseup on all platforms (which is
why I added the "// Hope we get a mouse up..." to this similar sample here --
https://bugs.chromium.org/p/chromium/issues/detail?id=255#c123), but it's very
unlikely that a user:

a) middle mousedowns on an element
b) drags their mouse out of the window and mouseups
c) WITHOUT USING THE MOUSE ON ANYTHING ELSE, middle clicks the same element

that's the set of steps you'd need to do, afaik, to get a double-click.

other crazy things are possible with the proposed code in this CL as well:

1) mousedown on element
2) mouseup outside of window
3) mousedown outside of window
4) mouseup on element

ultimately it's fairly hard to polyfill this correctly, which is why we either
need to live with the weirdness or fix it from a lower level in the platform
(<-- my preference)

[Navid Zolghadr, 2016/05/12 20:53:59]

Dan, I totally agree that having a platform support is ideal for this case.
However, the click event doesn't seem fit anymore because of the reasons already
mentioned. We will be working maybe on a new platform event or something to
support that but until then we would like to find a remedy to fix these Chrome
internal pages.

Also I understand the proposed solution in this change has a lot of problems. It
doesn't work with different nodes or stopimmediatepropagation or stuff like
that. But this is only a fix for this new tap page and that seems enough.

Regarding your new solution, I don't see what scenario this new solution handles
that the proposed solution doesn't handle? However, I can see some scenarios
that your proposed solution doesn't behave as good as the proposed solution.
Here is one. With your solution, everytime I middle click in the document (not
necessary the icon) I will have a new mouseup handler. So there is no limit on
those and they can be added as many times as user middle click in that document.
I don't know if this seems bad or not. What do you think? Also there is this
another edge scenario which Chrome doesn't send mouse up events which caused
some issue in your solution and not in the one in this CL. Just middle press on
an app icon and while pressing, Alt+tab and release it on the other window. In
this scenario you don't get the mouse up event in Linux as I tested. Now if you
go back to Chrome and middle click on the same icon all of a sudden two tab with
the same app will open. That being said, do you want me to still use your
proposed solution instead of the one in the CL?