Closed Bug 599793 Opened 14 years ago Closed 14 years ago

Paste & Go and Paste & Search should always replace the entire contents of the textbox

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- final+

People

(Reporter: justin.lebar+bug, Assigned: fryn)

References

Details

Attachments

(1 file)

STR:

* Copy "http://mozilla.org" onto the clipboard
* Navigate to http://google.com
* Click the location bar, and place the cursor before the "g" in "google".
* Right-click and select "Paste & Go"

Expected results:

* Browser navigates to http://mozilla.org

Actual results:

* Browser attempts to navigate to http://www.http://mozilla.orggoogle.com/
This should block because it's entirely the wrong behavior for this new feature.
blocking2.0: --- → ?
I suppose, we'll need to fix this for Paste & Search too.
Summary: Paste & Go should always replace the entire contents of the URI bar → Paste & Go and Paste & Search should always replace the entire contents of the textbox
Version: unspecified → Trunk
(In reply to comment #2)
> I suppose, we'll need to fix this for Paste & Search too.

You suppose correct!
Blocks: 492544
>  Paste & Go and Paste & Search should always replace the entire contents of the textbox

Always?

1. You're at https://bugzilla.mozilla.org/show_bug.cgi?id=599793
2. In the clipboard you have 492544
3. You select 599793 in the location bar -- which only takes a double-click -- then right click and choose Paste & Go.
4. You end up at https://bugzilla.mozilla.org/show_bug.cgi?id=492544

Quick and easy.
(In reply to comment #4)

This is true. By always replacing its entire contents, paste & go/search would have a different paste behavior than paste. While I don't think it makes sense to implement what is proposed in this bug, 'paste & go' and 'paste & search' certainly become more confusing and less compelling of a feature when the selection does not contain the entire contents. (FWIW, Chromium maintains a consistent paste behavior, like we do currently.)

lebar, limi, dolske: thoughts?
I suppose fixing this bug would break existing ux-consistency.
Keywords: ux-consistency
(In reply to comment #4)
> >  Paste & Go and Paste & Search should always replace the entire contents of the textbox
> 
> Always?

Yes.  :)

I think Chrome does this entirely right.  If you don't have URL on the clipboard, Paste & Go doesn't even show up.

Modifying a URL in place in the address bar via copy/paste is far and away an edge case, so I don't see why it needs to be streamlined beyond "paste the new bug number and press enter".
Maybe another way of saying it is that "paste & go" means "go to the URL that's on the clipboard".  I don't think it means "paste the clipboard and press the go button".
(In reply to comment #8)
> Maybe another way of saying it is that "paste & go" means "go to the URL that's
> on the clipboard".  I don't think it means "paste the clipboard and press the
> go button".

Well stated. Unfortunately, it isn't at all clear from the shortened phrase which of the two probable actions the menuitem will perform, but I don't have any strong objection to this being changed.

(Also, I was incorrect about Chrome's behavior. Chrome does exactly what Justin is proposing.)
* Opera has had the feature for nearly eight years now. It replaces the address bar selection.
http://www.opera.com/docs/changelogs/windows/700/
http://www.opera.com/docs/history/
http://arc.opera.com/pub/opera/win/702/en/std/

* The feature has been available in Firefox in the form of the "Paste and Go" extension for at least five years.
http://tecwizards.de/mozilla/pasteandgo/
The "Paste and Go 2" extension (and presumably, its predecessor and successor as well) has a preference which offers a choice between replacing the whole address or replacing the selection. I have it set to the latter; since a single left-click or right-click in the location bar selects the whole address, it has never been an issue.

* Iron (and presumably Chrome) offers only "Paste" and "Paste and search" if the clipboard doesn't contain a URL. If the clipboard does contain a URL, then "Paste and go" is available and it replaces the whole address regardless of what's selected.
I believe that comment 11 is agreeing with the other voices in this bug who are stating that Paste & Go should only show up when there is a URL on the clipboard. That's the design as I understood it, and I always thought that we showed Paste & Go at all times now to be a bug.

That would be an epic morph from this bug, though. I think this bug should be WONTFIX and we should file another blocking bug on restricting Paste & Go to only showing when the clipboard contains a URL.
I'd be OK filing a new bug, but there's still an issue here, which is that paste & go first pastes the clipboard and then clicks go.  Even if we didn't show paste & go unless there was a URL on the clipboard, the STR in comment 1 would still illustrate a bug.
You're right. Filed bug 	601695 to make Paste & Go only appear when there's a URL. If that's the case, then I agree that it should always replace the full contents of the location bar when pasting and going.
Assignee: nobody → fryn
Status: NEW → ASSIGNED
Attached patch patchSplinter Review
Attachment #486149 - Flags: review?(dao)
Attachment #486149 - Flags: review?(dao) → review+
http://hg.mozilla.org/mozilla-central/rev/44f99aaec11f

forgot to do ui-review! will do in the future. a retroactive one would be appreciated.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Attachment #486149 - Flags: ui-review?(beltzner)
Depends on: 607518
No longer depends on: 607518
Depends on: 607518
Target Milestone: --- → Firefox 4.0b8
Comment on attachment 486149 [details] [diff] [review]
patch

retroactive uir+ with thanks!
Attachment #486149 - Flags: ui-review?(beltzner) → ui-review+
Target Milestone: Firefox 4.0b8 → Firefox 4.0b7
Depends on: 616678
Keywords: ux-consistency
another use case for the old behavior is bookmark keywords
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: