Issue metadata
Sign in to add a comment
|
Regression: Right-clicking selected text resets selection start if left button is pressed |
||||||||||||||||||||
Issue descriptionChrome Version: 61.0.3163.49 and 62 OS: Windows 10 (and at least Linux, IIRC) 1. Mouse over some text (cursor will normally become the "text" cursor to show text is selectable) 2. Press and hold the left mouse button to start a selection. 3. Drag the mouse rightward to highlight some text. 4. Keep holding down the left mouse button, and right-click to show the context menu. Expected: Selection remains the same, so the context menu item "Search Google for [selection]" includes all the text you had selected. Actual: Selection is reset. This is annoying because I used to hold down the LMB, drag to select text, then click the RMB, hover over the "Search Google for [x]" entry, and release the LMB to activate that item. (I didn't even realize I used this "shortcut" until it stopped working.) Now I have to make sure I release the LMB before I click the RMB, which means I have to click the LMB a second time to activate the desired context menu item. It also in effect means I have to pause a few milliseconds after releasing the LMB to ensure the RMB is clicked after the LMB is released. The specific behavior seems to be that the right mouse button's mouse down event begins a new selection starting from that location. So continuing to move the mouse after mousing down with the right button, but before releasing the right button, starts selecting text beginning from the location where the right mouse button was pressed. That description isn't entirely accurate because the behavior is different when doing word-based highlighting: 1. Double-click a word and keep the left mouse button pressed 2. Drag 3. Right-click in the middle of a word. The text from the *end* of that word to the current mouse position is now highlighted.
,
Aug 18 2017
I could not reproduce this. Could you attach video or the URL for the page if this happens on specific page?
,
Aug 18 2017
Turns out it doesn't reproduce on Linux in 60.0.3112.90 or 62. Did you try it on Windows?
,
Aug 21 2017
>Did you try it on Windows? Yes, I can't reproduce on Windows.
,
Sep 3 2017
I just discovered that this doesn't repro on every page. Compare the steps given in #1 on crbug.com (does repro) and on https://www.chromium.org/ (doesn't repro). yosin@: Did you try on this page, e.g. on this comment itself? If so, and you still can't repro, I'll figure out how to take a screencast that includes my mouse activity. The issue is still present in 63.0.3203.0.
,
Sep 3 2017
Seems like the bug happens if the text is inside a scrolling container, and doesn't happen otherwise. https://jsfiddle.net/e993nzj3/ Although it's still not consistent inside <textarea>s.
,
Sep 4 2017
I could reproduce with #c6 on Win10.
It seems pressing left and right buttons same time makes
|extend_selection| is false
310 if (LocalFrameView* view = frame_->View()) {
311 const LayoutPoint v_point = view->RootFrameToContents(
312 FlooredIntPoint(event.Event().PositionInRootFrame()));
313 if (!extend_selection && this->Selection().Contains(v_point)) {
314 mouse_down_was_single_click_in_selection_ = true;
,
Sep 5 2017
Able to reproduce the issue on windows 7 & 10 using chrome M61 #61.0.3163.49 and M63 #63.0.3205.0 . This is a regression issue broken in M61 and is seen only in windows . Using the per-revision bisect providing the bisect results, Good build: 61.0.3132.0 (Revision: 479900). Bad build: 61.0.3133.0 (Revision: 480259). You are probably looking for a change made after 479930 (known good), but no later than 479931 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/9ede2cde5727eecdb377b57b32c5226d1d41c8ce..5971e47dc08dbb773f58fd6fb13b1df7917fd295 From the CL above, assigning the issue to the concern owner @ aelias- 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. Review-Url: https://codereview.chromium.org/2918053002 Thanks!
,
Sep 5 2017
Hmm, I can't repro on Linux even with --enable-blink-features=MiddleClickAutoscroll, which would make this annoying to debug. I'm not yet set up to develop on Windows (I have a machine, but no non-corp network port after moving to 900). I recall that on several platforms, the "button" field on the mouse event is set to the leftmost of the buttons currently pressed, a pretty sketchy heuristic which perhaps might be the root cause here: https://cs.chromium.org/chromium/src/ui/events/blink/web_input_event_builders_win.cc?q=web_input_event_builders_win.cc&sq=package:chromium&l=104 . It's possible my patch removed some behavior that coincidentally had worked around the problem in the past.
,
Sep 5 2017
OK, I figured out the Windows-specific nature comes from ShowContextMenuOnMouseUp setting. By hacking it to true in render_view_impl.cc, I'm able to repro the problem on Linux.
,
Sep 6 2017
,
Sep 22 2017
This has been in stable channel for a while now fwiw, and is run into pretty regularly during normal usage.
,
Sep 28 2017
Additional information: It does occur even if the top container has scroll-bars visible. It only happens when right clicking, doesn't happen with the menu key.
,
Oct 27 2017
,
Apr 10 2018
This issue is being reported as "normal behavior" in product forums (See: https://productforums.google.com/forum/#!topic/chrome/RL9YUTnxWvM) Is this going to be a nofix?
,
Aug 19
Sorry if here is not the place for this, but until this gets fixed, here's an ugly userscript workaround for those who are annoyed by this: https://gist.github.com/nampud/57c6c56a1ca27a55d0f2356d93c81e15
,
Oct 1
This is incredibly annoying for some users, can it be prioritized higher? Please? Also, thanks for the workaround. It works most of the time but fails if the page reacts to right click too (like displaying a dialog or other user-hostile stuff). I really miss the correct and native behavior. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by michae...@chromium.org
, Aug 18 2017Owner: yosin@chromium.org