628008 - 'Paste and Go' should also be "Replace selected and Go" and "Append and Go"

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, enhancement)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre ID:20110121153543

(see bug 492544)

example 1 (replace and go):
1. select the following number (doubleclick): 123456
2. go to the locationbar and doubleclick on the bugnumber
3. rightclick and select [paste and go] from the menu

result:
the whole url is replaced and just the number 123456 is in the locationbar

expected:
the bugnumber been replaced by 123456 and that bug been loaded

example 2 (append and go):
1. select the following number (doubleclick): 123456
2. go to the locationbar and doubleclick on the bugnumber and delete it
3. rightclick and select [paste and go] from the menu

result:
the whole url is replaced and just the number 123456 is in the locationbar

expected:
the number 123456 appended to the url and that bug been loaded

Comment 1

[Gustavo]

I came here to enter a new bug reporting exactly this same issue.
Very useful to enter directly in 'edition' or 'history' status in a list of pages, changing only the titles.

Vote.

Comment 3

[Patrick Storz]

I totally agree. "Paste & Go" should have the exact same functionality as "Paste" (except for the "Go"). Everything else is just unintuitive.

Comment 4

[Johan C]

Attachment: Patch v1

I think this makes sense, so here's a patch.

I've made the change to both the location bar and search field.

This patch:
* Only selected text is replaced with the text in the clipboard.
* If nothing is selected, everything is replaced.

Comment 5

[Patrick Storz]

Thanks for the patch Johan!

However I'd say the second bullet point ("If nothing is selected, everything is replaced.") should be changed:
- It differs from the normal "paste" functionality, therefore still unintuitive.
- It's unnecessary since by default everything is selected anyway as soon as the address bar / search box gains focus (so this case shouldn't arise normally).
- Therefore if really nothing is selected the user probably purposely deselected the text before to *not* replace everything.

One usage scenario: Consider you are on "http;//example.com" and want to add the parameter "?param=value" to essentially visit "http;//example.com?param=value". This is still not possible with the implementation you propose.

Comment 6

[Johan C]

(In reply to Eduard Braun from comment #5)
> Thanks for the patch Johan!
> 
> However I'd say the second bullet point ("If nothing is selected, everything
> is replaced.") should be changed:
> - It differs from the normal "paste" functionality, therefore still
> unintuitive.
> - It's unnecessary since by default everything is selected anyway as soon as
> the address bar / search box gains focus (so this case shouldn't arise
> normally).
> - Therefore if really nothing is selected the user probably purposely
> deselected the text before to *not* replace everything.
> 
> One usage scenario: Consider you are on "http;//example.com" and want to add
> the parameter "?param=value" to essentially visit
> "http;//example.com?param=value". This is still not possible with the
> implementation you propose.

I admit I did not read the entire bug description as I meant to file a new bug for the first example, and found this bug.

Your make a good point; however, the pref 'browser.urlbar.clickSelectsAll' could become a problem.
With this pref set to 'false' we would essentially break 'Paste & Go[/Search]' in the following scenario:
1. Right click the location bar.
2. Click 'Paste & Go[/Search]'.

Comment 7

[Mardeg]

> With this pref set to 'false' we would essentially break 'Paste &
> Go[/Search]' in the following scenario:
> 1. Right click the location bar.
> 2. Click 'Paste & Go[/Search]'.
As someone with browser.urlbar.clickSelectsAll set to false I can tell you that scenario is what will actually *work*, not break. When my intention is to replace the text in the bar I intuitively *always manually select* all the text before Step 1, knowing that I set the pref and that this is indeed the less common behaviour. 

The example of the proposed change working: I could have many youtube tabs open when Flash crashes, then knowing it's unstable I go through each to right-click -> Paste & Go the &html5=1&webm=1 in my clipboard to force the non-flash version in each tab.

As it currently stands that'd get me however many tabs I did it in with search results of the string "&html5=1&webm=1" regardless of the value of browser.urlbar.clickSelectsAll

Comment 8

[Patrick Storz]

>Your make a good point; however, the pref 'browser.urlbar.clickSelectsAll' could become a problem.
I also think, that this is exactly one of the downsides one is willing to accept by setting this preference to "false" as Mardeg is confirming.

Basically replacing everything on "paste and go" would even be a way of disregarding this setting since it is more or less a way of selecting all.

Comment 9

[Mardeg]

Added "dataloss" keyword because the unselected part of the URL on paste (which includes the entire URL if it's unselected) can contain important parameters that would be lost.
Essentially, a paste action that replaces unselected text goes so far against accepted conventions it should never be considered a valid use case.

Comment 10

[Gustavo]

I agree to comment 5 and comment 7
IMHO the second bullet point should be changed to:

"If nothing is selected, the text in the clipboard should be inserted in the position where the cursor is placed."

Comment 11

[Johan C]

(In reply to Mardeg from comment #7)
and
(In reply to Eduard Braun from comment #8)
and
(In reply to Mardeg from comment #9)
and
(In reply to Gustavo from comment #10)

I'm not opposed to the suggested changes, but I am worried that making too many changes to 'Paste & Go[/Search]' is going to confuse/irritate users who have already gotten used to the current behaviour.

If the text is the location bar is not selected when the user clicks 'Paste & Go', will they realise they are not taken to the URL in their clipboard, and instead presented with a 'Server not found' page or similar?

It should be less likely that this problem will arise with a part of the URL/search-text selected.

On the other hand, how many users know about 'Paste & Go[/Search]' and use it regularly? Could we make this change without breaking the feature for too many users?

I'd prefer some input from UX or a reviewer before uploading a new patch.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Apologies for the lack of a timely response here.

"dataloss" is a stretch - the URL in the location bar is usually not important data, and if it is you can retrieve it in session or global history.

What do other browser that offer similar functionality do?

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 771850 [details] [diff] [review]
Patch v1

The code looks fine, but the question here is just determining what the behavior should be. Do you want to raise this on firefox-dev (https://wiki.mozilla.org/Firefox/firefox-dev)?

Comment 15

[Johan C]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #13)
> Comment on attachment 771850 [details] [diff] [review]
> Patch v1
> 
> The code looks fine, but the question here is just determining what the
> behavior should be. Do you want to raise this on firefox-dev
> (https://wiki.mozilla.org/Firefox/firefox-dev)?

Done.

Sorry, I had completely forgotten about this.

Comment 16

[David Regev]

As an alternative to this bug, I filed bug 666799. Instead of changing the behaviour of ‘Paste & Go’, I think the wording should be changed so as to match the behaviour. My proposal there is that the menu item should say something like ‘Go to example.com…’. This would be more informative and would avoid the ambiguity that led to this bug.

I believe that the current behaviour is better than the one proposed here because it’s more likely to lead to unintended consequences if the final URL is different from the one copied. If you want to paste  over selected text in the location bar, then it’s not a big deal to have to use the standard Paste command followed by Enter, since this is not a common use case.

Comment 18

[Gingerbread Man]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #13)
> the question here is just determining what the behavior should be.

Firefox actually used to replace only the selection, but then a report was filed (and fixed) so that the whole URL is replaced. I even brought up the example in this bug's description in one of the comments.
Bug 599793

And then you have this bug that complains about the same thing; it was marked WONTFIX.
Bug 652356

Comment 19

[John Kitz]

My 5 cents worth: There clearly is a subtle yet distinct difference between 'Select' followed by 'Paste & Go' and 'Position' followed by 'Paste & Go'. The latter to me seems to have been the basis for bug 599793, which seems to have lead to a fix resulting a counter intuitive behavior.

My suggestions (in no particular order):

1. If they don't already exist consider one or more product management functions that have the final say in matters like this. After all there is a difference too between fixing existing agreed and designed functionality that is broken, fixing functionality that doesn't behave in accordance with the wrong or false end-user expectations and adding new functionality as per end-user requests.
2. Fix some end-users understanding and related expectations resulting from the use of cursor positioning and screen content selection.
3. Fix the pbm. so that any selected content is replaced and follows 'normal' intuitively expected behavior as described in this and duplicates with similar content.

Comment 20

[Johan C]

Not currently working on this.

Comment 21

[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.