608111 - Paste-and-go should appear when the clipboard's contents might reasonably be construed to be a URL

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[Justin Lebar (not reading bugmail)]

Following up on bug 601695.

Currently Paste & Go shows up only if the clipboard's contents start with "http://" or "https://".

Strings that don't start with "http" but look like URLs should also trigger paste-and-go.

Here's a regex for detecting URL-like things which is probably wrong:

  ^.*\.[a-zA-Z]{2}

i.e. some characters followed by '.', followed by at least two letters.

This would allow us to show paste-and-go for the strings "mozilla.co.uk" and "www.mozilla.com".

Comment 1

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

We should just use nsIURIFixup::createFixupURI rather than newURI().

Comment 2

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

Though that goes too far and turns "foo" into "http://foo/", which isn't quite what we want!

Comment 3

[Frank Yan (:fryn)]

(In reply to comment #2)
> Though that goes too far and turns "foo" into "http://foo/", which isn't quite
> what we want!

Yeah, which is why I did not object to using newURI(). Sigh.

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

Not that i know anything about Coding, but what about using the Method of how Text-URLs are recognized on Selection & the Contextmenu Handling (open in new Tab etc.)?

Comment 5

[Frank Yan (:fryn)]

(In reply to comment #4)

I'll investigate what that 'Open Link' code does exactly.

(In reply to bug 601695 comment #25)
> I'd prefer disabling the menu item rather than hiding it.  Hiding it made me
> think Firefox didn't have the feature.

(In reply to bug 601695 comment #26)
> It's tricky, since if you disable it, it's not clear *why* it's disabled.  That
> is, people who interpret "Paste & Go" as "paste the clipboard's contents and
> then go" could be disappointed when they select some part of what's in their
> location bar, right-click it, and "Paste & Go" is mysteriously disabled.
> 
> Anyway, I can see it going either way, personally.

Limi, I think you had some thoughts about this.

Comment 6

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

The open link code does something crazy that I don't quite understand:
http://hg.mozilla.org/mozilla-central/rev/c0dbbcfdb583

Comment 7

[ithinc]

We could interpret "Paste & Go" wider to "Paste & Enter". Really unnecessary to analyze whether it's an url. We can just do "Paste" and "Send enter key", so it may be attached to any textbox.

Comment 8

[Justin Lebar (not reading bugmail)]

(In reply to comment 7)
We decided that this was the wrong thing to do, in bug 599793.

Comment 9

[ithinc]

(In reply to comment #8)
> We decided that this was the wrong thing to do, in bug 599793.

Seems unrelated to comment 7. I meant no need to distinguish an url or not, unnecessarily making it too complicated. People can type any text than an url in the location bar.

Comment 10

[Justin Lebar (not reading bugmail)]

The crux of bug 599793 was that we interpreted "paste & go" as "paste & enter", just as was suggested in comment 7.  We decided that this was the wrong thing to do.  See bug 599793 comment 9.

Comment 11

[ithinc]

To clarify, I meant "Select all, Paste and Enter", whether an url or not.

Comment 12

[Frank Yan (:fryn)]

Unassigning myself, since I think bug 611590 should have been a WONTFIX in the first place.

I made the patch for bug 611590, since it was a blocker and assigned to me, but I really think we should be consistent in our menus. We should strictly adhere to the concept of a context menu being the menu that appears upon right-clicking a type of UI control. For example, to the user, the context menu of an image and that of a link are different menus. The menu items of a context menu should not appear and disappear depending on the contents of the clipboard. Items should be enabled or disabled depending on they are available for the current state of the control.

By this rule, in the case of the url bar, the context menu should always contain Paste & Go. The question becomes: when should it be enabled? Always; the menu item will always 'go' as in navigate to an address that is predictable, because pressing the 'Go' button would do the exact same thing (having pasted the clipboard contents).

Limi, as a member of the UX team, your input would be appreciated.

Comment 13

[Frank Yan (:fryn)]

Er, I mean I think bug 601695 should be been a WONTFIX in the first place.

Comment 14

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

(In reply to comment #12)
> Unassigning myself, since I think bug 611590 should have been a WONTFIX in the
> first place.

So do I. I have reopened it. Handling all these edge cases when we have a simple, predictable behavior baffles me. :)

> Limi, as a member of the UX team, your input would be appreciated.

The URL bar is also a search bar in Firefox 4. Thus, it should accept any input as Paste & Go.