Disable navigation on link double-clicks |
||||||
Issue descriptionIf you double click a (slightly) slow loading link, it can issue two navigation requests, where the latter one aborts the former one. This is a bad user experience, and can delay user-perceived page load times by x, where x is the double click speed. Additionally, this causes needless aborts coming into the network stack, spoiling metrics like Net.ErrorCodesForMainFrame3. It looks like roughly 10% of the <100ms aborts coming into ResourceDispatcher come from fast clicks. Could the UI be improved here?
,
May 24 2016
tkent@ does it make sense to check the detail() == 1 (this field on MouseEvent represents the number of clicks) Specifically in this line of code: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp&sq=package:chromium&type=cs&l=376&q=isLinkCLick This would avoid the double invocation.
,
May 24 2016
It sounds a good idea.
,
May 25 2016
,
May 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e46f8fbfd5d2d3408d09d4262fb0f4f99c93a98f commit e46f8fbfd5d2d3408d09d4262fb0f4f99c93a98f Author: dtapuska <dtapuska@chromium.org> Date: Thu May 26 04:10:53 2016 Only allow link clicks on single click. When double clicking a link it would cause a double load. Ensure link click only occurs on when the detail is 1. BUG= 614467 Review-Url: https://codereview.chromium.org/2011653003 Cr-Commit-Position: refs/heads/master@{#396116} [add] https://crrev.com/e46f8fbfd5d2d3408d09d4262fb0f4f99c93a98f/third_party/WebKit/LayoutTests/fast/html/a-click.html [modify] https://crrev.com/e46f8fbfd5d2d3408d09d4262fb0f4f99c93a98f/third_party/WebKit/LayoutTests/fast/loader/repeat-same-document-navigation.html [modify] https://crrev.com/e46f8fbfd5d2d3408d09d4262fb0f4f99c93a98f/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp
,
May 26 2016
,
May 26 2016
Thanks for the prompt fix!!
,
May 26 2016
If you can post what metrics you were querying specifically; like how did you determine 100ms timeout were caused by this.
,
May 26 2016
The metrics were not gathered in UMA. ResourceDispatcher::Cancel was instrumented to dump without crashing whenever it asks the ResourceDispatcherHost to cancel a requet that had only lived < 100ms. The logs were aggregated to find most used code paths in the wild. A lot came from click handlers on anchor elements, which I guessed to be either from these double clicks, or "enter clicks" where you hold enter and click a link. See crbug.com/607361 .
,
Jan 3 2017
,
Feb 24 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dtapu...@chromium.org
, May 24 2016