718177 - Search & Go does not append clipboard to pre-paste search input value

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[rickycornell]

Attachment: mozilla/release/browser/components/search/content/search.xml:609 selects input lazily

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111220165912

Steps to reproduce:

Clicked Paste & Go and Search & Go from the location and search input context menus. Input value was replaced instead of appended to as expected


Actual results:

Input value was replaced


Expected results:

Input value should have been concatenated with the clipboard value

Comment 1

[Dave Webber]

Similarly, if one right-clicks selected text in the location or search box and clicks "Paste & Go", the entire URI or search string is replaced instead of the selected part. So if, for example, one copies an added Blocks or Depends bug number from an email, then selects the bug number in the URI of the previous bug one was looking at (as by double-clicking the bug number in the address bar), then the right-clicks the selected bug number and clicks "Paste & Go", then Fx will attempt to navigate to, say <718177>, instead of <https://bugzilla.mozilla.org/show_bug.cgi?id=718177>.

Comment 2

[Matthew N. [:MattN]]

The current behaviour was decided in bug 599793 and I don't think this bug adds any new information to change the decision.  One thing to note is that bug 601695 has since been reverted (bug 611590) which would have made this less of a problem for Paste & Go.

Comment 3

[rickycornell]

(In reply to Matthew N. [:MattN] from comment #2)
> The current behaviour was decided in bug 599793 and I don't think this bug
> adds any new information to change the decision.  One thing to note is that
> bug 601695 has since been reverted (bug 611590) which would have made this
> less of a problem for Paste & Go.

While I sympathize with the source of the confusion, the result of that conversation is wrong. The verb "Paste" has a very well and pre-defined meaning and expectation for OS users and this would be the first time in any popular software that it means "replace something unselected". Clearly there are users, myself and David among them, that expect Paste on the alternate menu to cause the same behavior it does everywhere else.

If the feature is envisioned as something like "Go To Clipboard URL" then it should say that. Or, if you don't have the contents of the input selected, maybe the option can be disabled. In any case, having a URL with a number at the end like these Bugzilla reports and trying to paste a new number to the end of the URL and go afterward is very confusing as is.

Anecdotally, sometimes someone wants to paste something in their clipboard and go, like changing Bugzilla numbers, and sometimes someone wants to go to the URL on their clipboard. Both cases will arise, maybe even with frequency. If the feature only does one or the other and the language doesn't change it's always going to be a source of confusion for new users.

Comment 4

[Matthew N. [:MattN]]

I agree that both use cases are valid but I don't know that we would want to have two different menu options.

Can you come up with a proposal to address both use cases?

Comment 5

[Dave Webber]

In my experience, the "first" click in either the location box or the search box, with the left or right button, selects the entire URI. Correct me if I'm wrong, but isn't that the default behaviour for Fx on all platforms? (If not, I'd suggest it should be, unless users of other platforms object.) Consider the use cases: 

  (1) If I right-click an unfocused non-empty location box or search box, then its entire contents gets selected, and a contextual menu opens. At this point: clicking "Paste" replaces the (automatically selected) contents of the box with the contents of the clipboard. (In the case of the location box, this works the same regardless of whether the box contained the URI of the page or something else.); alternatively, clicking "Paste & "{Go,Search} replaces the (automatically selected) contents of the box with the contents of the clipboard and {goes to,searches for} the new contents. 

  (2) If I left-click an unfocused non-empty location or search box, then its entire contents gets selected; if afterwards I right-click the automatically selected text in the now-focused box, a contextual menu opens. At this point: clicking either "Paste" or "Paste & "{Go,Search} has exactly the same effect as above. 

  (3) If I left-click an unfocused non-empty location or search box, and then left-click it again after moving the pointer off the coordinates of the previous click or hesitating for at least the double-click time, then the contents of the box is first selected, and then deselected. AFAIK, this is the only way, using only the mouse, to have a non-empty location or search box focused and its contents not selected. Further, the only immediate purpose to click in the box a second time, like said, is to deselect its contents, so as to edit them in place rather than replacing them entirely. If I then right-click in the box, a contextual menu opens. At this point, clicking "Paste" inserts the contents of the clipboard at the insertion point; but, clicking "Paste & "{Go,Search} replaces the entire contents of the box, which I just made that extra click to deselect, as if I had not clicked again but rather kept the contents selected, and {goes to,searches for} the contents from clipboard. 

  (4) If I (left-)single-click twice (as opposed to double-clicking), as in the third case, to focus the box and deselect its contents, then half-click (mouse-down) and drag in the box, then release (mouse-up) once I've highlighted part of its contents, thereby selecting part of the contents, and then I right-click the text I just selected, a contextual menu opens. At this point, clicking "Paste" replaces the selection with the contents of the clipboard; but, clicking "Paste & "{Go,Search} replaces the entire contents of the box with the contents of clipboard, and {goes to,searches for} the contents from the clipboard. 

  (5) If, on a platform where double-clicking in text selects a word while triple-clicking selects a paragraph or line, I double-click part of a location or search query (such as the bug id or one term of a multi-term query), regardless of the focus or selection state of the box, the double-clicked part of the location or query gets selected. If I then right-click the text I just selected, a contextual menu opens. At this point, clicking either "Paste" or "Paste & "{Go,Search} has the same effect as in all other cases. 

  (6) If, on a platform as in the fifth case, I triple-click in the location or search box, regardless of its original focus or selection state, the resultant behaviour follow identically to that in cases 1 and 2.

The behaviours of "Paste & …" in cases 1, 2, and 6 all replace the contents of the box with the contents of the clipboard and go to or search for the newly replaced contents. In those cases, the behaviour of "Paste & …" is consistent with the selection and analogous to the behaviour the other four co-grouped options ("Cut", "Copy", "Paste", and "Delete") in the contextual menu: all of them act on the entire contents. 

The behaviours of "Paste & …" in cases 3 through 5, which (AFAICT) complement 1, 2, and 6 to exhaust the two-button mouse-only use cases (for which there is a conventional behaviour established, at least), also all have the same effect as in cases 1 and 2. In these three cases, the behaviour of "Paste & …" is inconsistent with the selection. It is also contrary to the behaviour of "Paste" in case 3 (where the selection is empty, and hence "Cut", "Copy", and "Delete" are unavailable): "Paste" applies to the empty selection at the insertion point, whereas "Paste & …" applies to the entire contents of the box. Likewise, the behaviour of "Paste & …" is contrary to that of the other four co-grouped options in the contextual menu in cases 4 and 5: "Cut", "Copy", and "Paste", which precede "Paste & …", and "Delete", which follows it, apply to the selection, whereas "Paste & …" applies, as always, to the entire contents. In these cases, four of five grouped options in a contextual menu apply to a different context than the fifth member of their group. 

There are currently no means by which one can use "Paste & …" to address the insert the contents of the clipboard at a specific point, and then go to or search for the thus-edited location or query. Similarly, there are no means by which one can apply this option to replace a selected subset of the characters in the location or search box with the contents of the clipboard, and then go to or search for the thus-edited location or query. This is despite the fact that the behaviours for right-clicking an unfocused location or search box, and for right-clicking a focused box with entirely selected contents (as one has, by default, after a single-click on an unfocused box, or a triple-click in a box regardless of its prior focus state), all equally address the only use cases currently addressed.

Comment 6

[Dave Webber]

Correction: 

(5) …. At this point, clicking either "Paste" has the same effect as in the fourth case, whereas clicking "Paste & "{Go,Search} has the same effect as in all other cases.

I'm sorry to double-comment; I should've proof-read more carefully.

Comment 7

[Dave Webber]

(In reply to Matthew N. [:MattN] from comment #4)
> Can you come up with a proposal to address both use cases?

I took a look at the behaviour on Linux, and noticed that Fx doesn't default to the same behaviour on Linux as on Mac OS X and Windows. I then found (and toggled) browser.urlbar.clickSelectsAll and browser.urlbar.doubleClickSelectsAll in Linux Fx. 

So, to answer your question shortly and directly, my proposal to address both use cases is these two steps:
  1. either solve bug 453255, or solve bug 570123 and default the requested new preference to the same as browser.urlbar.clickSelectsAll .
  2. change the behaviour of "Paste & "{Go,Search} to replace the selection (even if empty) if browser.urlbar.clickSelectsAll .

Comment 9

[pawright]

I believe that there should be a "Paste and Go" function which would GO after replacing any currently-selected portion of the address from the clipboard or inserting it at the cursor if there is no current selection. This would seem to be the accepted meaning of "Paste."

There should ALSO be a "Replace and GO" facility which simply enters the current clipboard as the target address. Now whether this should be called "Replace and Go" or "Go from clipboard" or "Go to <address resolved from clipboard>" I'd leave for discussion and the ingenuity of whoever takes on the task.

There should be CONFIG: facilities to individually control whether or not "Paste and Go" or "Replace and Go" is available, to suit all predelictions; default being both facilities available. A further config: should control whether "Replace and Go" should be smart ("GO to <address>") or not - if that functionality can be arranged.

Comment 10

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.