This object is in archive! 

Search highlight text drag and release causes accidental mouse clicks.

SysZer@ shared this bug 6 months ago
Reported – Awaiting fix

When highlighting any Text in any search window on the UI such as inventory items.

If you highlight search text at inventory screen and keep dragging to an icon and let go it counts as a primary mouse click at depressed location on the UI.

Same happens in the assembler queue window also.


i think this issue is such that a mouse button depress is also counted as a click.

Replies (2)

photo
1

Hello, SysZer!

I have had a look at this and can see what you mean. Could I ask under what circumstance you would want to drag text? I could understand this if it was being dragged to copy or put somewhere else but as I cannot think of a reason to drag text, I can't quite understand at this time how it would cause an issue. Please provide any further information :)

Kind Regards

Laura, QA Department

photo
1

Highlighting parts or the whole of a bit of text to replace it with something else is one case where this happens.

This is aggravated by SE not supporting commonly used text field UX. Specifically, double-clicking or triple-clicking to select the word under the mouse pointer or the entire text, respectively. As such, the user is forced to switch to click-and-drag to select. Next, click-dragging to select a bit of text with the notion of "select everything from here to the end" is typically not done precisely to the last letter but to anywhere beyond that letter. This causes the mouse-up event of text selection to easily happen way outside the text field. Again, this is typical, regular, muscle-memory-ingrained UX.


For example, take the Block Group field. Suppose a block, any block, is selected in the terminal, and the user wants to create a group from the selection. They type a name, then they decide for a different name, so they click a spot past the name and drag all the way (and then some) to the left to type the new name. (Because that's what practically every other text box out there has trained them to get away with.) But when they release LMB and they happen to hover over an On/Off switch, for example, that switch is accidentally toggled. See attached video.


In short, a click-and-drag that started in a textbox and that started a new text selection (rather than started on an existing text selection) should never allow its respective mouse-up event to affect anything outside the box. (If anything, only when it started on an existing selection, it should allow a drag-and-drop of the selected text from one textbox to another.)

I say again, this behaviour is de-facto standard mouse-and-textbox UX. SE is the exception here, and an exception that, in combination with existing muscle memory, only serves to needlessly confuse the user and diminish the smoothness of gameplay experience.

photo
photo
1

Hello, andersenman!

I really appreciate the examples given, that makes complete sense. I also appreciate the video example. With such great examples and information, I have reproduced the issue and reported it internally :)

Kind Regards

Laura, QA Department

Leave a Comment
 
Attach a file