Middle Click Navigation is Broken
Reported by
asmoor...@gmail.com,
May 30 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: 1. Find any webpage with a mixture of regular links and javascript event links. 2. Middle-clicking the regular links still behaves normally (opens link in new tab in the background). 3. Middle-clicking javascript event links does nothing. What is the expected behavior? Consistency! Some folks somewhere decided (after 15+ years) that a raw middle-click shouldn't throw a click event. Well that's all well and good and technically true. But the problem is that there is an expected behavior for middle-click in all modern browsers and for all practical purposes there is no such thing as a true "raw" middle-click action. If the browser itself is deciding to have a feature where for all regular links the middle-click should be exactly as a regular click but open a new tab then this should remain consistent with the javascript click event. If the end user wishes to turn off the "middle-click to open new tab" feature then by all means consider it a "raw" middle-click and throw no click event. As it stands right now my browser is completely broken as I look across a sea of links and have to guesstimate which ones will middle-click and which ones won't *even on the same page*. What went wrong? Inconsistency. It's one thing to ask what event should a middle-click throw? It's an entirely different conversation to ask how does our browser itself interpret the middle-click before the event is even handed off to javascript? Yes, I am aware that control+click does the action that I prefer. But I shouldn't need to resort to a 2 handed keyboard and mouse operation to simply do what *still* works on plain links! But now follow that control+click logic through. If the original "problem" that this change solves is that some javascript somewhere was mis-interpreting the middle-click, how long until some javascript somewhere is mis-interpreting the control+click? Has any real problem been solved here? Did this work before? Yes 54? Chrome version: 58.0.3029.110 Channel: stable OS Version: Ubuntu 14.04 Flash Version: Firefox has done the same thing with the same insane results - links *within the same page* behave differently depending on regular or javascript. To an end user links are all the same!
,
May 31 2017
Another noteworthy fact about these javascript links that you might want to direct to a new tab is that you cannot right-click them and open in a new tab from there. Maybe a possible feature enhancement could be to detect things that have a click event handler and add "open in a new tab" to their context menu.
,
May 31 2017
asmoore82@ Thanks for the issue. Could you please provide us any sample test file or URL to triage the issue from test team end. Thanks,
,
May 31 2017
I made this to show the simplest case of inconsistency: https://jsfiddle.net/rm6tbv93/7/
,
May 31 2017
Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 1 2017
Able to reproduce the issue on Windows 10, mac 10.12.4 and Ubuntu 14.04 using chrome reported version #58.0.3029.110 and latest canary #61.0.3116.0. Bisect Information: ===================== Good build: 55.0.2853.0 Revision(416812) Bad Build : 55.0.2855.0 Revision(417475) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/3eda8caca348d8c2c2f72d28af48e0757f83d1f2..7be81ca9b22fe6abb5a96d200f77167cae987b5f From the above change log suspecting below change Review url: https://codereview.chromium.org/2302513002 nzolghadr @ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Jun 1 2017
I understand your frustration and the troubles that this change might have caused. However we also had a lot of people complaining about the other way (which was sending click event for middle button issue 255 ). Either way some set of developers were unhappy and some websites were broken. But from our analysis at the time we realized the portion of people that don't expect click for the middle button was much more the other group. So we had to make a decision that makes the life of most developers/users/websites easier at the cost of a smaller portion of codes on the web needing to fix to use auxclick. We tried our best to reach the developers before the feature launch including github issues, blog posts (https://developers.google.com/web/updates/2016/10/auxclick) and comments on the reported bugs. Also we had this feature behind the flag for quite sometime before 55. But we are hoping to get better at our outreach in the future.
,
Jun 1 2017
The core of this issue doesn't really have anything to do with external web developers, their complaints, or outreach. At its core the browser's internal behavior is now simply inconsistent. Is it intended for control+click and middle-click *links* behavior to be the same or no? If you are set on removing/breaking common features that have been in web browsers for 15+ years, at least be consistent.
,
Jun 1 2017
Regarding ctrl+click maybe this issue is related: https://github.com/WICG/auxclick/issues/13 and we do have that in mind to send auxclick for any click action that is accompanied by something else (like control in this case). |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ligim...@chromium.org
, May 30 2017Labels: Needs-Triage-M58 Needs-Bisect