492544 - Add 'Paste and Go' + 'Paste and Search' to context menu on location field + search field

Status: VERIFIED FIXED

(Firefox :: Address Bar, enhancement)

Description

[mind_readerz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

This has become such a problem for my work, that I am filing it under a bug report...

In my work I need to paste many websites into the location bar, but I am constantly slowed down and irritated by there not being a 'paste and go' option, only a 'paste' option is there. I have already contacted Mozilla many times using the 'suggestions' page but its been months and still no reply or an implementation of this feature in Firefox.

Before you start, I know that there is a addon to 'provide' this feature, but it doesn't provide this feature...because it adds the 'paste and go' option to the right-click menu of the tab, not the location bar, so its useless and still frustrating...So why not take 30 minutes to add this feature to Firefox and save many people out there like me the slowdown and constant irritation of this feature being missing?

It's great that you are working on TraceMonkey and other high end features, but the fact that small features such as 'paste and go' have been overlooked by the many Firefox versions up to now is rather disappointing...

So please add this features:

1. Add 'Paste and Go' to the location bar.
2. Add 'Clear history button' to the 'Toolbar' or in 'Customize Toolbar'. 
3. Add 'Undo Last Tab button' to the 'Toolbar' or in 'Customize Toolbar'
4. Add 'Load Homepage' option when opening a new tab in 'Tools' > 'Options'

Note: For number 3, the creator of the Addon 'Undo Closed Tabs Button' has stopped developing this addon, I have received a reply from the creator confirming this. Thanks for adding these features if you do...

Reproducible: Always

Steps to Reproduce:
1.copy a URL 
2.right-click on the location bar
3.note the missing 'Paste and Go' option and become very frustrated...
Actual Results:  
no feature

Expected Results:  
there should be a feature there to 'Paste and Go' to make my life and that of many other users a lot easier

Opera has this feature, Internet Explorer has this feature, everyone except Firefox has this feature!

Comment 1

[mind_readerz]

I apologise if this 'bug report' has annoyed anyone but having waited months for these features to be implemented, waiting for a reply to these suggestions(in a previous attempt to contact Mozilla), I have switched to Opera 9 for the time being...The addons to implement these features are out of date or don't do the job as described in the original post

Comment 2

[Steve England [:stevee]]

Dupe of bug 216667 although this bug wants paste&go in more locations.

Comment 3

[Steve England [:stevee]]

http://pasteandgo2.mozdev.org/ and https://addons.mozilla.org/en-US/firefox/addon/9133 also add this feature

Comment 4

[Kevin Brosnan]

The main issue here is that you reported more than one request for enhancement. As such this makes correctly dealing with the bug hard. All the items you have requested are available as extensions at https://addons.mozilla.org

Comment 5

[mind_readerz]

The extensions do not cover at least one feature that is a must have for me. This includes the following from the original post:

1. Add 'Paste and Go' to the location bar.
3. Add 'Undo Last Tab button' to the 'Toolbar' or in 'Customize Toolbar'

For the paste and go, the only extensions available are in development and you have to have 'accounts' to log-in and then install it, its been like this for months...How hard is it to add a 'Paste and Go' function to the right-click menu? I would guess it takes 1 hour max to implement it! I use it all the time with Opera 9, and also with Google Chrome, most people I know use this feature, also in an external website I posted this question and most people agreed that it should be in the Firefox 3.5 final release. Why don't you listen to your consumers? This request was posted in about 2006 on this Bugzilla website, and Mike Beltzner responded and gave a silly reason for why its not included, he said that it is hardly used and there all alternatives by using some complex command! Do the millions of users of Firefox users sound like developers to you? and you really think 'hardly anyone uses it' then why have Opera, Google Chrome, and now with Internet Explorer 8 Microsoft have included this feature?, It just doesn't make sense why Mike Beltzner doesn't use some common sense rather than his 'developer' ideology!

Now to my second point, 'Undo Last Tab button'.

The developer of this extension Kurt Schultz has told me in an e-mail that he has stopped supporting this extension. That means there no way to use it for the forthcoming Firefox 3.5 

This is what he said to to in an e-mail sent 13 April 13:53:09.

'I've abandoned the extension and no one has been willing to pick it up yet.  Hopefully someone will soon though!'

So please Mozilla, take a little time to listen to your consumers, don't simply suggest that there are extensions out there, because the extensions for these two particular features have either been in development for months, or the support for the extensions has been stopped (as explained above). Lastly, don't have this developer ideology 'well there are commands you can do to solve the problem, or there is no need because there are other ways to accomplish the same thing...' 

Do the right thing, these features have been in demand for years (as explained above), I am a big supporter of the Mozilla projects, and even use the default Google homepage because I think you must earn some revenue from all the Google ads, so please listen to people like me...thanks

Comment 6

[Alex Limi (:limi) — Firefox UX Team]

This issue is conflating two separate features, but I agree that we should add:

- Paste and Go (location field)
- Paste and Search (search field)

…to the context menu when you try to paste in these areas of the UI.

Officially adding this to the papercut project.

(file separate tickets for the button issues if you still want to suggest them, please :)

Comment 7

[Kevin Brosnan]

Paste and go for the address bar is bug 216667. Not sure what you want to do here, could dupe forward or reopen the older bug.

Comment 8

[Justin Lebar (not reading bugmail)]

bug 216667 was WONTFIX'ed.  Maybe we should dupe this one and reopen that one.

Also, a suggestion: Chrome only shows paste-and-go when the clipboard's contents look like a URL.  I think this works well, and may mitigate some people's concerns about adding cruft to the context menu.

Comment 9

[Tiago Sá]

Wouldn't we need a "paste and search" too? Chrome's hardly an example for this kind of stuff...

Besides, "paste and go" in the location bar should also work for keywords, I find.

Comment 10

[Frank Yan (:fryn)]

Attachment: patch v1 (paste and go & paste and search)

I tried using the controller like this:

        isCommandEnabled: function(aCommand) {
          if (aCommand == "cmd_pasteandsearch")
            return !document.getElementById("cmd_paste").disabled;

but I couldn't figure out how to get the enabled/disabled state of the 'Paste and Go/Search' menu item to sync up with the cmd_paste state using that.

So, I'm using <menuitem cmd="cmd_paste" onclick="..."/>.

Comment 11

[imradyurrad]

(In reply to comment #10)
> Created attachment 457118 [details] [diff] [review]
> patch v1 (paste and go & paste and search)
> 
> I tried using the controller like this:
> 
>         isCommandEnabled: function(aCommand) {
>           if (aCommand == "cmd_pasteandsearch")
>             return !document.getElementById("cmd_paste").disabled;
> 
> but I couldn't figure out how to get the enabled/disabled state of the 'Paste
> and Go/Search' menu item to sync up with the cmd_paste state using that.
> 
> So, I'm using <menuitem cmd="cmd_paste" onclick="..."/>.

Disabled state? If it's disabled shouldn't it just disappear from the context menu?

Comment 12

[Frank Yan (:fryn)]

Attachment: patch v2 (paste and go & paste and search)

Comment 13

[Frank Yan (:fryn)]

patch v2 solves the attribute forwarding problems that v1 had.

(In reply to comment #11)
> Disabled state? If it's disabled shouldn't it just disappear from the context
> menu?

This is do-able, but it requires additional code like this:
observer.setAttribute("onbroadcast", "this.parentNode.hidden = document.getElementById('cmd_paste').getAttribute('disabled') == 'true';");

Let me ask some UX people.

Comment 14

[Frank Yan (:fryn)]

I talked to UX people, and they agree with my approach of just disabling it to avoid changing the list of menu items unnecessarily.

Comment 15

[imradyurrad]

(In reply to comment #14)
> I talked to UX people, and they agree with my approach of just disabling it to
> avoid changing the list of menu items unnecessarily.

Nice. Will this make it into beta2 and if so, should it be on the release notes?

Comment 16

[Paul [pwd]]

(In reply to comment #14)
> I talked to UX people, and they agree with my approach of just disabling it to
> avoid changing the list of menu items unnecessarily.

I don't understand that. Why would you have an item greyed out when it doesn't need to be there most of the time? The only time you'll have the option to "paste and go" is in cases where by you have a URL in the clipboard, so what's the point in showing it the rest of the time? It's more confusing to a user to show something that's greyed out 90% of the time than it is to only show it when it's available. Not to mention it keeps the menu's looking cleaner. I really hope this decision will be re-reviewed.

Comment 17

[Tiago Sá]

I disagree with Paul comment #14

It will only confuse people with bricks for brains and it adds to discoverability. And that's a good thing.

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 458168 [details] [diff] [review]
patch v2 (paste and go & paste and search)

The current patch doesn't meet the design spec that Limi asked for, which was to have the menuItems added when the copybuffer includes a URL (for Paste and Go) or when the copybuffer contains some text (for Paste and Search).

Comment 19

[Justin Lebar (not reading bugmail)]

It's probably worth looking at Chromium's source to see how they recognize a URL-like thing for the purposes of paste-and-go.

Comment 20

[Paul [pwd]]

(In reply to comment #19)
> It's probably worth looking at Chromium's source to see how they recognize a
> URL-like thing for the purposes of paste-and-go.

Firefox already distinguishes between links and normal text. Highlight a plain-text URL and you'll see "open link" in the context menu. Also, you can see extensions like FlashGot to only show it's options in the context menu for links.

Comment 21

[Justin Lebar (not reading bugmail)]

(In reply to comment #20)
> Firefox already distinguishes between links and normal text. Highlight a
> plain-text URL and you'll see "open link" in the context menu.

Huh.  Indeed, that works with both well-formed URLs (e.g. http://mozilla.com) and abbreviated URLs (e.g. mozilla.com).

FWIW, FF hides the "open link" options when the selected text isn't a URL-like thing.

Comment 22

[Paul [pwd]]

(In reply to comment #21)
> (In reply to comment #20)
> > Firefox already distinguishes between links and normal text. Highlight a
> > plain-text URL and you'll see "open link" in the context menu.
> 
> Huh.  Indeed, that works with both well-formed URLs (e.g. http://mozilla.com)
> and abbreviated URLs (e.g. mozilla.com).
> 
> FWIW, FF hides the "open link" options when the selected text isn't a URL-like
> thing.

Indeed. Which raises the question, why isn't that disabled rather than hidden? There should most certainly be a uniform approach.

Comment 23

[imradyurrad]

(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #20)
> > > Firefox already distinguishes between links and normal text. Highlight a
> > > plain-text URL and you'll see "open link" in the context menu.
> > 
> > Huh.  Indeed, that works with both well-formed URLs (e.g. http://mozilla.com)
> > and abbreviated URLs (e.g. mozilla.com).
> > 
> > FWIW, FF hides the "open link" options when the selected text isn't a URL-like
> > thing.
> 
> Indeed. Which raises the question, why isn't that disabled rather than hidden?
> There should most certainly be a uniform approach.

Why should it be disabled? If you're not going to perform the said actions, it'd just be clutter in the context menu.

Comment 24

[Frank Yan (:fryn)]

Attachment: patch v3 (using oncommand since controller was unreliable)

Comment 25

[Frank Yan (:fryn)]

Attachment: patch v4 (updated to tip of tree)

Comment 26

[Dão Gottwald [:dao]]

(In reply to comment #24)
> Created attachment 459331 [details] [diff] [review]
> patch v3 (using oncommand since controller was unreliable)

Why was it unreliable? Is it unreliable for cmd_clearhistory and cmd_togglesuggest too?

Comment 27

[Dão Gottwald [:dao]]

Comment on attachment 460071 [details] [diff] [review]
patch v4 (updated to tip of tree)

>diff --git a/browser/base/content/urlbarBindings.xml b/browser/base/content/urlbarBindings.xml
>--- a/browser/base/content/urlbarBindings.xml
>+++ b/browser/base/content/urlbarBindings.xml
>@@ -59,16 +59,41 @@
>         this._urlTooltip = document.getElementById("urlTooltip");
> 
>         this.inputField.controllers.insertControllerAt(0, this._copyCutController);
>         this.inputField.addEventListener("mousedown", this, false);
>         this.inputField.addEventListener("mousemove", this, false);
>         this.inputField.addEventListener("mouseout", this, false);
>         this.inputField.addEventListener("overflow", this, false);
>         this.inputField.addEventListener("underflow", this, false);
>+
>+        const kXULNS = "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul";
>+        var textBox = document.getAnonymousElementByAttribute(this,
>+                                                "anonid", "textbox-input-box");
>+        var cxmenu = document.getAnonymousElementByAttribute(textBox,
>+                                            "anonid", "input-box-contextmenu");
>+        var element, label, observer;
>+        var insertLocation = cxmenu.firstChild;
>+        while (insertLocation.nextSibling &&
>+               insertLocation.getAttribute("cmd") != "cmd_paste")
>+          insertLocation = insertLocation.nextSibling;
>+        if (insertLocation) {
>+          element = document.createElementNS(kXULNS, "menuitem");

let element = document.createElement("menuitem");

>+          label = Components.classes["@mozilla.org/intl/stringbundle;1"].
>+                             getService(Components.interfaces.nsIStringBundleService).
>+                             createBundle("chrome://browser/locale/browser.properties").
>+                             GetStringFromName("pasteAndGo.label");

let label = Services.strings.createBundle...

>+          element.setAttribute("label", label);
>+          observer = document.createElementNS(kXULNS, "observes");

let observer = document.createElement("observes");

>+          observer.setAttribute("element", "cmd_paste");
>+          observer.setAttribute("attribute", "disabled");
>+          element.appendChild(observer);

Maybe I'm missing something... Where does this discriminate between URLs and random text?

>+          element.setAttribute("oncommand", "goDoCommand('cmd_paste'); document.getElementById('urlbar').handleCommand();");

gURLBar.handleCommand();

Comment 28

[Dão Gottwald [:dao]]

Comment on attachment 460071 [details] [diff] [review]
patch v4 (updated to tip of tree)

I just got into a state where "Paste and Go" would always be disabled. Unfortunately I have no idea how to reproduce...

The menu items lack access keys, by the way.

Comment 29

[Frank Yan (:fryn)]

Attachment: patch v5 (updated as per Dão's comments)

Comment 30

[Frank Yan (:fryn)]

(In reply to comment #26)
> Why was it unreliable? Is it unreliable for cmd_clearhistory and
> cmd_togglesuggest too?

I don't know why it was unreliable, but the code in patch v2 never updated the disabled state of the menuitem properly. It works for cmd_clearhistory and cmd_togglesuggest. If you can find a way to get controllers to work in a more elegant way that the observer, let me know.

(In reply to comment #27)
> Maybe I'm missing something... Where does this discriminate between URLs and
> random text?

See https://bugzilla.mozilla.org/show_bug.cgi?id=492544#c6 . I have talked to Limi, and he says that this is what he meant.

Also, this follows the UX principle of consistency, since we do not change the Go button or its tooltip when you type a non-url.

(In reply to comment #28)
> I just got into a state where "Paste and Go" would always be disabled.
> Unfortunately I have no idea how to reproduce...

I have never run into this state. :\

> The menu items lack access keys, by the way.

Access keys are not required for this, because this feature is specifically being included for mouse-driven users.

Comment 31

[Frank Yan (:fryn)]

Attachment: the real patch v5 (updated as per Dão's comments)

my bad; uploaded the wrong file.

Comment 32

[Dão Gottwald [:dao]]

Comment on attachment 460445 [details] [diff] [review]
the real patch v5 (updated as per Dão's comments)

(In reply to comment #30)
> (In reply to comment #27)
> > Maybe I'm missing something... Where does this discriminate between URLs and
> > random text?
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=492544#c6 . I have talked to
> Limi, and he says that this is what he meant.

Apparently beltzner denied the ui-review for this. See comment 18.

Comment 33

[imradyurrad]

Doesn't ff already do that?
Highlight a url, right click on it, and you'll have three options to open it.

Comment 34

[Frank Yan (:fryn)]

(In reply to comment #33)
> Doesn't ff already do that?
> Highlight a url, right click on it, and you'll have three options to open it.

That uses entirely different logic.
Example:
Type w.mozilla.com in the url bar, and Firefox will try to open it as a url.
Select w.mozilla.com on a page, and you won't get 'Open Link' in the context menu.

Comment 35

[imradyurrad]

I'm not getting what you mean. 
http://img844.imageshack.us/img844/4681/clipboard01y.png

Comment 36

[Paul [pwd]]

(In reply to comment #35)
> I'm not getting what you mean. 
> http://img844.imageshack.us/img844/4681/clipboard01y.png

Confirmed, w.mozilla.com is treated as a URL in both plain text and location bar.

Comment 37

[Frank Yan (:fryn)]

I gave a bad testcase.

I selected the w.mozilla.com of the string www.mozilla.com, which doesn't not bring up 'Open Link'. This is intended behavior, since highlighting part of a string (but not ending at whitespace) does not often imply that the user wishes to open it as a url.

Here's a working testcase:

Type ｐｉｋａ．ｊｐ in the url bar, and Firefox will open it as a url.
You can confirm that it is not performing a Google search by toggling keyword.enabled to false in about:config.
It also does not bring up the alert that appears when you enter something that cannot be interpreted as a url.
Open a blank tab and enter javascript:void(document.body.innerHTML='ｐｉｋａ．ｊｐ') into the url bar to create a block of text. Select that text and observe that 'Open Link' is not in the context menu.

Comment 38

[Vlado Valastiak [:wladow]]

(In reply to comment #30)
> > The menu items lack access keys, by the way.
> 
> Access keys are not required for this, because this feature is specifically
> being included for mouse-driven users.
As you can invoke both context menus without even touching a mouse and every single item in those menus is already using an accesskey I strongly disagree with this. Either add accesskeys for the new items or we should remove accesskeys for our all context menus. Having a context menu consisted of both items with and without accesskeys is highly non-standard here and breaking the product in terms of consistency at least.

You're saying that this feature is for being included for mouse-driven users. I agree but it could be used by keyboard preferring users as an equivalent to currently used keys combination - right now you need to focus the location bar (CTRL+L), paste link (CTRL+V) and hit Enter. With this new feature you need to focus the location bar (CTRL+L), invoke the context menu item (Menu key+ accesskey and hit Enter. That's perfectly equivalent and thus may be preferred. 

Voting for adding accesskeys here.

Comment 39

[Shawn Wilsher :sdwilsh]

While this certainly would be nice to have, I don't think it blocks the release of Firefox 4.0.

Comment 42

[Justin Dolske [:Dolske]]

Comment on attachment 460445 [details] [diff] [review]
the real patch v5 (updated as per Dão's comments)

So the patch looks fine, but no r+ because I'm also getting the sporadic mixed-enabling of Paste And Go. Not sure how that's happening (since it _should_ always be having the same state as Paste), but sometime it's not.

Reproducible for me, usually, on Windows 7 debug build:

1) Right click on, say, an app shortcut on the desktop.
2) Select copy
3) Right click on URL bar
4) Note that "Paste" is disabled, but "Paste and Go" is not.

Would be good to do some debugging to what's happening...

Comment 43

[Justin Dolske [:Dolske]]

Still not sure _exactly_ what's failing here, but I'm suspicious of the mix of command-observers/observers and onpopupshowing stuff that various menus are using.

I seem to have been able to fix the problem with a quick hack, buy having this patch add |cmd="cmd_paste"| to the menuitems it's adding... This is enough to make the code in textbox.xml [_doPopupItemEnabling()] enable/disable the Paste And Go entries along with the other edit menus.

Comment 44

[Vlado Valastiak [:wladow]]

As this is almost complete and the patch involves string changes, nominating for blocking beta6 per Beltzner's comment in dev.planning.

Comment 45

[Axel Hecht [:Pike]]

Comment on attachment 460445 [details] [diff] [review]
the real patch v5 (updated as per Dão's comments)

FWIW, I'd love to see a localization note that clarifies that Search is an action, not a noun.

Comment 46

[Dietrich Ayala (:dietrich)]

(In reply to comment #44)
> As this is almost complete and the patch involves string changes, nominating
> for blocking beta6 per Beltzner's comment in dev.planning.

What was Beltzner's comment? While I think we'd approve a safe and well-tested patch, I still don't think that we'd hold the entire release back for this, so blocking-.

Comment 47

[Frank Yan (:fryn)]

Attachment: patch v6 (fix using suggestion from comment 43)

Comment 48

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 474456 [details] [diff] [review]
patch v6 (fix using suggestion from comment 43)

Looks good to me. Minor nit, I think "Paste & Go" / "Paste & Search" looks and reads better, but don't let that stop the patch from landing. :)

Comment 49

[Frank Yan (:fryn)]

(In reply to comment #45)
> FWIW, I'd love to see a localization note that clarifies that Search is an
> action, not a noun.

Oh right. I forgot about this. Dolske, if this patch is good to go, feel free to add in a comment about that when checking it in.

(In reply to comment #48)
> Looks good to me. Minor nit, I think "Paste & Go" / "Paste & Search" looks and
> reads better, but don't let that stop the patch from landing. :)

I also prefer the ampersand visually. Axel, would that affect localization?

Comment 50

[Frank Yan (:fryn)]

Dolske, just to clarify. Two minor changes to the patch for check-in:

1. Replace 'and' with '&' in both strings. (Limi recommended this.)

2. Add a comment in the dtd for 'Paste & Search' explaining that 'search' is an action verb, not a noun. (Axel recommended this.)

Thanks :)

Comment 51

[David Regev]

You can already paste and go by middle-clicking on the favicon (though not the entire Identity button, oddly), if middlemouse.paste is true. It doesn’t (yet) work for pasting and searching. Perhaps this should be made more discoverable somehow, since it’s faster than using the context menu. It can be added to the Identity button’s menu, for example, with ‘middle-click’ displayed as a shortcut.

Comment 52

[Justin Dolske [:Dolske]]

Attachment: Patch v.7

Frank's Patch v.6 + Comment 50 string tweak.

Comment 53

[Justin Dolske [:Dolske]]

Pushed http://hg.mozilla.org/mozilla-central/rev/3e1b3d58309f

Comment 54

[u88484]

Verified fixed.  Paste & Go and Paste & Search work great!

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100916
Firefox/4.0b7pre

Comment 55

[ithinc]

"Paste & Go" is also needed in google search field. Maybe it can be made as a standard item in Edit context menu? We just do cmd_paste and send enter key, no need to "gURLBar.handleCommand" or "document.getElementById('searchbar').handleSearchCommand".

Comment 56

[IU]

(In reply to comment #55)
> "Paste & Go" is also needed in google search field...

There's an extension for that: https://addons.mozilla.org/en-US/firefox/addon/204931/