721204 - Search function compels users to send selected text accidentally to google

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, defect)

Description

[Ralf Bartzke]

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:9.0.1) Gecko/20111221 Firefox/9.0.1 SeaMonkey/2.6.1
Build ID: 20111221001913

Steps to reproduce:

Go to any website, highlight some text, press the right mouse button instead and catch as "Copy" intends to next line "Look with xxx".

This certainly is not inadvertently placed under the "Copy" menu item seems simple, effective and cheeky. He sends to the default search engine (Google) sufficiently frequent Internet user interest text, without asking for permission.


Actual results:

Seamonkey sends the selected text to to the default search engine (Google) immediately, without being interested in possibly conflicting intentions of the user.


Expected results:

Under no circumstances should be user data without further inquiry or general consent to Internet addresses forwarded, either openly or in secret.

Comment 1

[Philip Chee]

In the context menu I see:
1. Copy
2. Select All
3. A menu separator line
4. Search Google for "something".

There is enough separation to avoid accidentally selecting the search menu item.

Comment 2

[Ralf Bartzke]

I disagree. A visual separation is there, but the distance between the mouse-sensitive areas is only 6 pixels. In a conventional 600 dpi mouse is only 0.254 mm. The probability of an accidental mouse movement caught by the wrong button is therefore relatively high.

Comment 3

[Philip Chee]

On my system each menu item is 17px high so there are 34 pixels of separation. If you see only 6 pixels this means each menu item is only 3 pixels high. I find this highly unlikely. Please attach a screenshot of your contextmenu. Thanks.

Comment 4

[Ralf Bartzke]

This is probably a misunderstanding. The distance between the center of the two menu items on my system is larger than 6 pixels. But moving the mouse, which is necessary to switch from a button on the next, is only 6 pixels. This distance can be bridged easily by a small accidental mouse movement at the moment of pressing the mouse button.

In addition, then you can do not assume that the user an accurate feedback on the operating system has reported current absolute mouse position, because the shape of the mouse cursor can be changed. In addition, there are (touchpad or trackpoint mouse on notebooks, trackball) alternative input devices, which give only accurate feedback at the moment about the exact mouse position, in which the mouse has already been fired.

If the user has opened at that moment a password list from its local hard disk or the website of his bank, all the highlighted information is transmitted immediately to the search engine without asking. This is definitely unacceptable and must therefore be solved in principle.

Comment 5

[Justin Wood (:Callek)]

(In reply to Ralf Bartzke from comment #2)
> I disagree. A visual separation is there, but the distance between the
> mouse-sensitive areas is only 6 pixels. In a conventional 600 dpi mouse is
> only 0.254 mm. The probability of an accidental mouse movement caught by the
> wrong button is therefore relatively high.

Yea, Sorry, but I don't share your concerns with accidentally clicking here. We should not make it HARDER to do what the menu item is intended for, and it does involve a few steps to invoke.

Also you CAN change system settings as to mouse sensitivity where a 600 dpi mouse could need to move much more than 0.254 mm to hit the spot, if you encounter frequent mistakes like that, you should change those settings.

Also you can change your default search engine, or write (or use if someone else writes) a new search engine that points nowhere, or even an extension that disables that context menu function entirely.

Comment 6

[Ralf Bartzke]

I think this design violates general Design Standards of graphical interfaces in Windows. These dictate my knowledge for good reasons that menus should never directly invoke actions, but only to make adjustments or open dialogues must. It is true that it is possible to select a different search engine. But it is impossible to select no search engine.

Comment 7

[Justin Wood (:Callek)]

(In reply to Ralf Bartzke from comment #6)
> I think this design violates general Design Standards of graphical
> interfaces in Windows. 

Maybe, maybe not. This general feature (search from right click) exists in IE, Firefox and SeaMonkey. Still a WONTFIX, please do not reopen.

Comment 8

[Ralf Bartzke]

You can read the Design Standards for graphical interfaces in Windows here:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511258.aspx

"Page 65 of 882"
-> "Use command buttons for ... Destructive or irreversible actions."

-> "Use links for navigation to another page, window, or Help topic; display definitions; and command menus"

Especially for safety-relevant input options, the program needs to keep the user expected and required standards.