I'm using a Logitech Performance MX mouse and since upgrading to Sierra I'm having difficulty when using my scroll wheel to select large amounts of text. Usually, I scroll while holding left mouse and this has always worked. Now when I scroll, it deselects the text that I have selected.
Could this be a driver issue?
Best Answer
TL;DR
Not really a final answer, but as a workaround, to select long texts, you can
Just sharing my findings, since I'm also annoyed with this issue: as Dolan Antenucci commented, uninstalling LCC will normalize the behavior of hold-mouse-left-button combined with scrolling, but at the cost of losing mouse customization. Not an option for me.
Curiously, I've been searching and searching for hours, and seems no one else here is complaining about this. The closest I could find was a report of a bug in a UI framework written in Python, but so close in behavior that for a second (or a couple, or more ;-)) I had to question myself if it's really a coincidence (I now, I now..).
See https://github.com/kivy/kivy/issues/5058
There they describe (almost?) exactly what I believe is happening here: Scrolling generates a mouse up event for previously pressed button.
To verify, you can try this: on a browser, press and hold the right button. Then move the mouse over an option of the pop-up menu (say, "back"), then scroll the wheel. The option is selected, as if you had released the button.
The same is occurring with text selection. Do this: with mouse left-click-and-hold, select some text, "freeze any mouse movements" (explain later), then scroll down (but not too much, keep the already selected text visible). The text that remains selected is only the one who was selected just before the scroll movement (as if you had released the button just before start scrolling). Then stop scrolling, hold shift, and do some mouse movement. In response to the smallest move, the text between is automatically added to the selection, and after this you can even release the shift, no matter anymore, go keep moving the mouse (provided that you don't move the scroll) to continue tuning selection. This is exactly what should have happened if you had released the button just before start scrolling (aka mouse up event), do some scroll, then pressed/hold shift, and next clicked/hold again the mouse button, to do the final mouse selection movements.
The only catch is that, if while holding the button and after some scrolling (who "wrongly" generated a mouse button up event), you do any mouse movement, in response to this move, (maybe in an attempt) to honor the fact that the you are still holding the button, the system immediately generates a mouse button down event.
That's why you think the scroll de-selects the text: normally, when someone do some scroll to add selection, do without moving the mouse, but tends to make some final mouse movements after the scroll, tu adjust the end of the selection. Try holding the button, make some selection thru moving, freeze mouse movement, scroll (keep freezing), release button, move mouse (note, the selection don't go away), then shift + click/hold, when the mouse reach the destination point. Since you released the button just before restarting mouse movements, when you do the new moves, the system will not generate a mouse button down event, once there is no need to "honor" this state (after all, the button is already up).
It's not the scroll who de-selects the text: it's the mouse movement, after scrolling, while keeping the mouse button down.
I think it's an attempt to maintain/regain system consistency, since the last info passed thru was, essentially, wrong: the mouse button up event, as a consequence of a scroll movement, should never been occurred.
I'm going to report this to logitech, maybe if presented with some more tech explanation they will fix the problem. (God, is so painful to use they site send a simple message, anyone knows a easier way?)