This issue appears to be universal. I tested on Fedora 20, Mac OSX 10.12, and Windows 10 Anniversary all x64 and all running Chrome 54. Mac OSX and Windows actually failed to open any additional tabs besides the first instance without moving the cursor. Whereas Fedora appears to be demonstrating the behaviour as described here -- opening multiple tabs, but not as many as expected.

All three were tested with rapid cursor movement as well, and all produced a multitude of tabs.

Unable to reproduce the issue on Windows 7 using chrome canary M54 #54.0.2840.71 , chrome beta M55 #55.0.2883.21.

Attached screencast for reference.

@bobchao -- could you please try reset chrome from chrome-> settings and try again. If you still face the issue , please write us with observations.

Thanks !

Deleted: 658904.mp4 611 KB

	658904.mp4 611 KB View Download

Resetting my chrome settings back to default made no change, even tried a new profile afterwards.

@hdodda, When you were on the yellow grid you didn't click fast enough for it to trigger, but that doesn't matter because you clearly don't have this issue as apparent of your second tab's test.

Something to note, is this only applies to webpages, it does not apply to, for example, the refresh button, or bookmarks.

I've been having this issue ever since the update to Chrome 53 as well. Using the website that hdodda used for the new windows (well, tabs), I did not suffer the issue either. I believe that's because it was a button and not a link. If they instead tried to open a new tab with the facebook link in the top right corner of that page, they would most likely have had the same issue as we've been having.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue on chrome canary M57 #57.0.2965.0 and chrome stable M55 #55.0.2883.87 . 

@jonathanarnold10-- Could you please check in latest chrome versions and provide us the screencast , so that it would be helpful for us to triage the issue better.

Thanks!

Issue is still present in "56.0.2924.28 beta" and in "57.0.2965.0 canary".

I have not provided a new video as requested because there is no change from the video evidence I provided originally. Unless you have a specific request?

I'd like to add, that I did format and reinstall Windows 7. Before even installing Windows Updates I installed Chrome (and signed in, because this slipped my mind), created a new profile and the issue existed still.

Tested in chrome stable #55.0.2883.87 and canary #57.0.2969.0 on Win 10.0 able to reproduce the issue.
Below are the Bisect Details:

Bisect Info:
=============
Good Build: 53.0.2749.0(Revision - 396053)
Bad Build: 53.0.2750.0(Revision - 396337)

Bisect URL:
=========== 
You are probably looking for a change made after 396107 (known good), but no later than 396117 (first known bad).
CHANGELOG URL:
--------------
https://chromium.googlesource.com/chromium/src/+log/5955bea3251e74af30f43bc3833edaf93960ee93..2f51b95ab526d0bac7b08ed525ec51e27850c119

From the CL above, assigning the issue to the concern owner

@ dtapuska : 
------------------
Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/2011653003.

Note: Able to reproduce the issue in Ubuntu 14.04 and Mac 10.12.2.

This was actually done on purpose because we saw a lot of people actually double clicking links which leads to double the network requests; see  issue 614467 . We could make a special exception for control click but I'm not sure that warrants it. Do you have a specific use case here?

+tkent@ for additional comments

No special case for Ctrl + Click, that was just a better visual demonstration of the issue than clicking the same spot. This issue as far as I can limitedly imagine, is exclusive to browser games. The game I noticed the issue on was HoboWars.com, when I click the link to buy something or repeatedly do something, the page will refresh and I will click that link again to repeat the action. Another case would be my attached image, you explore around a grid, and you do it quickly and this would limit this as well (it supports arrow keys but this is an example of something it affects). And of course the site I listed I used for testing is affected, http://www.miketyndall.com/hobowars/unisolver/.

Would putting this as a toggle in that large page that has little tweaks in it be viable? (Don't recall the page address)

Deleted: ebd5924422eb2f10448ee1f368b11456.png 19.4 KB

	ebd5924422eb2f10448ee1f368b11456.png 19.4 KB View Download

I think your use case is certainly competing against what we were trying to fix which was the undesired loads of pages via rapid clicks.

rbyers@ any opinion?

Having an option to revert the change in chrome://flags/ would be nice and would work for me. Honestly this issue has driven me nuts ever since it was changed. If I want to click again in the same spot, I have to jiggle my mouse over the hyperlink. I should be able to simply keep on clicking. 

Clarifying that this impacts only clicking on <a> elements that get their default handling.  The most common cases for scenarios like these involve a 'click' listeners in JavaScript which will still work completely fine AFAIK.  

I don't think we want to go back to double-loading when you double-click on a normal link to a new page.

But is there perhaps a reasonable middle-ground here?  In the example above the links aren't normal cross-page links but javascript: URLs.  It does seem odd that <a href=javascript:foo> is treated differently from <a onclick=foo>.  Maybe javascript URLs (and even fragment URLs) should be treated differently from URLs that cause navigation since there's little downside to permitting double-click to activate them multiple times?  Eg. maybe instead of handling this in HTMLAnchorElement we should pass the clickCount down to the navigation code and it can decide to ignore double-clicks for real cross-page navigations?

In the reported site; hobowars they are actual hrefs...

here is the element...

<a href="game.php?sr=0&amp;cmd=explore&amp;do=move&amp;dir=r&amp;x=51&amp;y=50"><img src="..." border="0" pagespeed_url_hash="2950540405" onload="pagespeed.CriticalImages.checkImageForCriticality(this);"></a>

Opt-out ctrl+click sounds reasonable.

The last paragraph of #16 is a good idea. However I don't think we need to do so now because it won't fix hobowars.

We may show a console warning on ignoring double-clicks.

I don't think this warrants special casing ctrl-click. The reporter wasn't doing ctrl click but was using that as a demonstration that the click event fires but the default action only occurs on a single click and not a double click. 

I think what we have right now fixes what we were seeing in the histogram reports that a number of people end up double clicking links which caused double network traffic and they only really meant to click once. I think the correct fix for this is to be that hobowars should really listen to clicks and not really be implemented via page navigation. 

To be clear though this affects every single webpage viewed through Chrome. Hobowars simply has the use of clicking the same spot on a page more than once.

None of you replied on having an opt-out for this specifically, I wont pretend to know how much work goes into that considering this is admittedly small, but what's your stance? If I could give another go at persuading you I'd add that no other browser that I know of has this "fix" in it, I don't know how revenue works for a browser, but this could potentially drive people away from Chrome if they have this issue.

Also, I could argue that the issue of double network traffic was preventable by the user in the first place without hindering their speed; I mean, I don't double click links. Where was my issue is not something I can personally speed up besides waiting the given amount of time. So you've taken something that is a user error, by holding their hand, and instead punished my, what I imagine is an encouraged habit (fast clicking). (Sorry if that was inappropriate)

@Reporter,Thanks for the information.

dtapuska@,

friendly ping!!

Could you please look into this issue as per comment#20 & update the thread.

Thank you.

The issue has been annoying me for months, so I'm glad I finally found this ticket.

Here are my two use cases.

1) Scrolling through a calendar. Imagine a calendar widget that gets included on another page, and shows all appts for one day. The top of the widget looks like this:

   [<-] Sunday, Jan 1 [->]

If you want to go forward 3 days, you just click [->] 3 times, and the calendar scrolls through those days.

On every other browser, this works. On chrome, it goes forward one day, then the button appears to stop working.

The [->] buttons are links like href=calendar#day/1/1/2017, href=calendar#day/1/2/2017, etc

2) This same widget has one line for every open time in the day. It looks something like this:

 2pm      Meet with Bob
 2:30pm   Available        [delete]
 3:00     Available        [delete]
 3:30     Available        [delete]

If you want to clear your afternoon, you want to press those 3 delete links. This is fast (in other browsers) because deleting each row makes the rows below it move up, so you just put your mouse over the first [delete] link, then press 3 times without needing to mouse your mouse.

On other browser, this works perfectly. Again, on Chrome, the first delete works, and the rest fail.

These delete links look like href="javascript:myFunction(<uniqueID>)"

* I understand the motivation of reducing double clicks, but note that in my two cases, _every link is different_. Either I'm calling a function with different args, or there are different arguments after the #.

It seems like Chrome isn't allowing _any_ click in the same location, even on different content! This seems to be... not ideal.

So I don't think this comes down to the question "Is double-click protection worth this cost?" Instead, it looks like the implementation was too broad, and broke good functionality.

In the case of real hrefs (not just fragment or JS URLs), double-clicking is already unreliable, right?  I.e. if there's a real "next" link - double clicking it will only go one page forward (since the user isn't waiting for the new page to load before requesting 'next' again).

So perhaps we can still eliminate most of the disadvantage here by moving the limitation down to the loading code so that it applies only to true loads?

Absent that I tend to agree that the interop difference in behavior around double-clicking on anchors which are reliably fast (fragment/javascript) is severe enough that I'd personally rather just revert the "speed improvement" then leave things as-is.

I think this could be fixed if a frame sees a click event with clickCount > 1 and hasn't seen a corresponding click event it could generate a few synthetic events.

Reverting sounds okay to me. Unfortunately I imagine moving this logic into the loader will complicate things a bit but I could look into it.

Possibly related discussion here: https://twitter.com/DasSurma/status/835155193838858241

Note this was introduced in M53, so there shouldn't be anything new in 56/57 as far as I know.

Charles, would it perhaps make sense to plumb some "within-page-only" flag down the loading path?  We'd set that flag when click-count > 1.  Then when you realize you're trying to do an actual navigation you can bail out?

Or maybe there's a possible better fix in the loader. Eg. if we get a request to load a URL which matches an in-progress load we just cancel the 2nd request rather than replace the first?  Eg. what should happen if a user double-clicks a link which changes it's href between the first and 2nd click? Kinda seems like we should cancel the first load and load the 2nd URL instead, right?  It's just the "we're already loading that URL, don't start over for no good reason" debouncing we really want here...

Your second suggestion sounds reasonable to me, but I'm not sure if there are greater ramifications to doing this in loader code. E.g. then we are dealing with all sorts of navigations, including JS induced navs and other non user-initiated things. It could have a greater impact to the platform.

I'm also not sure if I would have time to implement this, as I am transitioning off the loading team right now.

Let me cc japhet/dcheng to see if they see any problems here. I know site isolation team is doing lots of refactoring of navigation policy moving to browser process.

Thanks. The urgent question I think is whether we should revert this DOM-level change while we explore other possible improvements.  Personally I don't think we really considered the impact of the DOM change on javascript: and fragment URLs, and so we should revert it.  But I'd defer to tkent and dtapuska.

Don't we already pass some information down from blink about the load being user-initiated (eg. to determine whether it's allowed to open a pop-up)?  Perhaps we could use that (or pass down a new "from user action" bit) to mitigate the risk of any debouncing change in the loader?

Yeah gating on user input sounds reasonable. I'm also fine with moving forward with a revert while we  formulate a better plan.

Let's revert on Monday. Then this should hit m58

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

commit 917d0b3de410cd7efc197b275ffb5d1f3ddba5b5
Author: dtapuska <dtapuska@chromium.org>
Date: Mon Feb 27 21:53:25 2017

Allow clicks > 1 to navigate.

Due to a few breakages revert change
crrev.com/e46f8fbfd5d2d3408d09d4262fb0f4f99c93a98f

Invert the layout test to ensure we have consistent behaviour.

BUG= 658904 

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

[modify] https://crrev.com/917d0b3de410cd7efc197b275ffb5d1f3ddba5b5/third_party/WebKit/LayoutTests/html/text-level-semantics/a-click.html
[modify] https://crrev.com/917d0b3de410cd7efc197b275ffb5d1f3ddba5b5/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp

 Issue 649519  has been merged into this issue.

This is still an issue for me. I am on Windows 10 Version 58.0.3029.81 (64-bit) and i don't have the issue for links, but i am trying to play a game that requires multiple clicks to change the status of a cell, and only the first click registers, i have to move the mouse to get subsequent clicks to work. 

Works fine in Edge.

ddo...@ Please feel free to open a new issue with details. (network trace, reproduction URI, etc) as this sounds like a different issue.

This is not fixed for me.  In device emulation mode with chrome dev tools open, a long press on a button (button element) causes the browser context menu to appear and then the mousedown event is fired some time after (milliseconds).

The effect of this is that we cannot e.preventDefault() in the mousedown handler to prevent this behavior.

It's a big deal.  I want to implement a button that repeats click logic if the button is held down.  Like the +/- buttons on a number field.

^^^ 

I want to add that I'm using touchstart, touchmove, and touchend, not mouse events.

Have this error a few weeks. macOS 10.13, Chrome 61.0.3163.100