10080 - add "open link" to menu of selected text containing link (go to uri url in highlighted text context menu)

Status: NEW

(SeaMonkey :: UI Design, enhancement, P3)

Description

[Crysgem]

Implemented, this would function as follow:
Highlight a block of text with the primary mouse button, open the context menu
("right-click menu"), and, selecting an option from that menu, access the URL
represented by the highlighted text.

This enables a swift (no keyboard/mouse transition, itself a grievous matter
beyond this suggestion's scope) three-click leap to a URL... and why, prithee
tell you, would the text selected not be recognized as a hyperlink? Why, there
are divers causes. Perhaps the selected text is presented in a plain text
document.

Comment 1

[Chris Booton]

In other words to put it simply: to eliminate the hassle of copying url's people
type (without the http:// so it does not auto become a hyperlink ) you could
select it and right click in the selected and an option to 'go to this URL'
would appear. I guess it would base recognition of it being a URL b the format
(such as www.mozilla.org or www.netscape.com ) but if the text was not in valid
url format then the 'go to selected url' would be greyed out.

Comment 2

[don]

Yep, there are times when I need this behavior ...

Comment 3

[alstrup]

It's almost already possible to do this without the keyboard:
Select your link, right click, select "copy", go to the location box, right
click and select "paste".  All that is needed is a "go!" button to make it
complete.

If such is added, this problem is solved.

However, to make it easier, I suggest that such a "go" button would be made
more intelligent: It should be possible to just select the text, right click
on the go button, and select "Go to selected URL".
On Unix, I suggest that this behaviour would be bound to the middle mouse
button.

Comment 4

[Dawn Endico]

This is like a unix 4.x feature
- Highlight a URL or URL fragment such as 'slashdot.org'
- paste into some dead area in the document window.

The act of pasting a url works as if you had typed something into the location
bar and hit enter. On unix this is easy because the middle mouse button means
'paste'. I'm not sure if this makes sense on other platforms.

Comment 5

[leger]

mjudge, what do ya think?

Comment 6

[rubydoo123]

moving this out to a later milestone

Comment 7

[Ben Bucksch (:BenB)]

For plain text, see bug 39042.

In other cases, it's the fault of the page writer. I'd argue, that copy/paste
and go button would be sufficient.

If this bug will be fixed nevertheless, for the implementation, take a look at
mozTXTToHTMLConv. I could tweak it to give you a function, which returns the
first URL in an arbitary string (so the user doesn't have to select the URL
exactly in most of the cases, but can select a bit too much).

Comment 8

[Kathleen :Brade]

I don't understand why this is a "selection" bug; sounds like a feature request 
for the browser.  Selection (proper) shouldn't try to look at what is selected.  
Reassign to [e-mail] since he is implementing the context menus for the 
browser.

Bill--do you think this belongs on your plate or to someone else on your team?

Comment 9

[Bill Law]

Yes, seems like I've heard similar suggestions in the past (or maybe this bug 
went by me previously).

I think this should be implemented in the browser context menu code.  Not sure 
when we'll get to it, though...

Comment 10

[Ben Ruppel]

I agree, I was kicking around this idea a while back and it would be useful.
Another way is to drag and drop the selected text to the location bar, there is
a bug filed on that since right now it only pastes the text into the current url.

Comment 11

[Gervase Markham [:gerv]]

law said "I think this should be implemented in the browser context menu code."

This isn't really possible; the relevant file, nsContextMenu.js, doesn't have 
any code for detecting or getting a selection. I quote from the "Copy" part:

        // Enabling this context menu item is now done through the global
        // command updating system

<shrug> If we can't get the selection, we can't test it for beginning with 
http:// or www., and then open a new browser window with it.

Gerv

Comment 12

[rbs]

What about "Browse to" (bug 75173) -- to match with the overall concept of 15176

Comment 13

[Boris Zbarsky [:bzbarsky]]

*** Bug 97432 has been marked as a duplicate of this bug. ***

Comment 14

[Jesse Ruderman]

Implementing the feature described here would make the selection context menu 
grow by 5 items whenever the selected text looks like it could possibly be a 
link, and would encourage authors of HTML pages to leave out hyperlinks.  I 
think it would be better to fix bug 39042, "Display text/plain and *.txt using 
stream converters", since plain-text documents are the most common source of 
non-hyperlinked URLs except for paper magazines.

Comment 15

[Brian Smith]

I think that highlighted text, if it is a valid URI, should just display the
same context menu as if it was actually a link.

Comment 16

[Ben Bucksch (:BenB)]

Jesse, I think, you misunderstood this bug. It does not automatically linkify
URLs in HTML docs, which are not linkified by the author. (That's what bug 39042
could do.) IMO, that would be a bad idea, for several reasons.
Instead, the user had to manually highlight text including the URL and then
select a context menu item. (We could discuss, if left-clicking on that selected
URL should also load the URL, but I guess that's a bad idea, too.)
Removing dep to bug 39042.

Comment 17

[Jesse Ruderman]

BenB: I added 39042 to the dependency list because I think we should fix bug
39042 first and then decide whether this is still necessary.  (My guess is that
it won't be.)

Comment 18

[Kathleen :Brade]

add dependency per Jesse's comment above

Comment 19

[Jesse Ruderman]

*** Bug 134924 has been marked as a duplicate of this bug. ***

Comment 20

[Jesse Ruderman]

*** Bug 83460 has been marked as a duplicate of this bug. ***

Comment 21

[Michael Lefevre]

*** Bug 151470 has been marked as a duplicate of this bug. ***

Comment 22

[Jesse Ruderman]

*** Bug 165886 has been marked as a duplicate of this bug. ***

Comment 23

[(not currently active) Ted Mielczarek]

I created an extension to do this.  I haven't tested it in Mozilla, only in
Phoenix, so YMMV.  It's fairly useful.

http://ted.mielczarek.org/code/mozilla/textlink.xpi

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 182892 has been marked as a duplicate of this bug. ***

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 172071 has been marked as a duplicate of this bug. ***

Comment 26

[Sander]

*** Bug 186053 has been marked as a duplicate of this bug. ***

Comment 27

[Alfonso Martinez]

*** Bug 186922 has been marked as a duplicate of this bug. ***

Comment 28

[Gino A. Melone]

The plugin provided by Ted Mielczarek above seems to work great in Mozilla
1.2.1.  Perhaps an effort could be made to distribute this by default.  Or at
least publicize it.  Judging by the number of duplicate bugs registered (mine
included), this is a very desirable feature.

Comment 29

[Sander]

*** Bug 178390 has been marked as a duplicate of this bug. ***

Comment 30

[Sander]

*** Bug 191776 has been marked as a duplicate of this bug. ***

Comment 31

[Jo Hermans]

*** Bug 199634 has been marked as a duplicate of this bug. ***

Comment 32

[Jo Hermans]

*** Bug 199769 has been marked as a duplicate of this bug. ***

Comment 33

[Norbert Wienholz]

Ted Mielczarek's extention (http://ted.mielczarek.org/code/mozilla/textlink.xpi)
also works fine in Mozilla 1.4a under Win32.

Comment 34

[Ken Harris]

FWIW, Apple's Safari has this feature now: if you right-click
on something that looks like an address (like http://www.mozilla.org),
it adds "Go To Address" to the top of the context menu.

The textlink.xpi is pretty neat, but I like Safari's better:
Safari shows 1 extra menuitem when a URL is selected, and no extra
menuitems if a non-URL (or nothing) is selected.  Textlink shows 2
extra menuitems all the time (and I don't use tabbed browsing,
so I'll always ignore one of them).

Could it be made selective about when it appears?
It doesn't need to appear when I right-click an image, for example,
just as "View Image" doesn't appear when I've selected some text.

Comment 35

[Jo Hermans]

*** Bug 203889 has been marked as a duplicate of this bug. ***

Comment 36

[Hixie (not reading bugmail)]

.

Comment 37

[Gilles Durys]

*** Bug 195987 has been marked as a duplicate of this bug. ***

Comment 38

[ralph]

See also bug #212629.

Comment 39

[WD]

*** Bug 225573 has been marked as a duplicate of this bug. ***

Comment 40

[cooperg]

For those of you on Firebird, this feature is available as an easily-installable
and very much needed extension called Text / Plain. Read about it here:
http://extensionroom.mozdev.org/more-info.php/textplain

Thanks Gilles!

Comment 41

[Jesse Ruderman]

See also bug 227922, same bug for Firebird.

Comment 42

[Caliga (Daniel St.)]

Could someone backport this Safari feature (comment #34) and / or include
textlink.xpi to the main mozilla tree?
(I don't like to install douzens of very little features, that should be common,
every time i install mozilla.

The ability to recognize textlinks by just right-clicking on them (not marked)
would be even cooler.

Comment 43

[Mats Palmgren (inactive)]

*** Bug 257056 has been marked as a duplicate of this bug. ***

Comment 44

[Frédéric Buclin]

(In reply to comment #40)
> For those of you on Firebird, this feature is available as an easily-installable
> and very much needed extension called Text / Plain. Read about it here:
> http://extensionroom.mozdev.org/more-info.php/textplain

It also works perfectly using Mozilla 1.7.2, not only Firefox. It can recognize
links such as http://mozilla.org and even mozilla.org alone (well, any string of
the form anytext.anytext(.anytext...), i.e. any string which could be a valid URL).

That's exactly what this bug asks for!

Comment 45

[Stephan Slabihoud (:slabbi)]

*** Bug 262148 has been marked as a duplicate of this bug. ***

Comment 46

[Stephan Slabihoud (:slabbi)]

Any change to get this implemented as core functionality of Mozilla/Firefox? 

Extensions are really nice but I really dislike the idea to install hundreds of
extensions for such simple functions.

Comment 47

[Ben Ruppel]

Firefox has really accomplished something over mozilla in keeping the interface
tight and clean.  I was an original heavy proponenet of adding this as a context
menu item, but I think it is specialized enough to leave as an extension.  Did
you know that, in Firefox, drag and dropping a selection to the location bar now
replaces the contents of the bar with the selection?  Hit the Go button and
you've got the same effect that this bug calls for.

Comment 48

[Jesse Ruderman]

Bug 236336 is the corresponding bug for Firefox.

Comment 50

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 51

[:Hb]

All extensions below provide the wanted feature and exceed it in functionality. WONTFIX 


*text/plain* by Gilles Durys

Treats selected plain text urls, and email addresses as links and adds options
to the context menu on how to use ...
http://mozilla.durys.net/textplain/ or
https://addons.mozilla.org/de/seamonkey/addon/1864


*Plain Text Links* by Ted Mielczarek

With any text that can be treated as a URL, using this extension you can right
click on the text and select "Open this URL".
https://addons.mozilla.org/de/firefox/addon/78


*Plain Text to Link* by Tommaso Beniero

Plain text to link is able to select plain text in a page and save it in a text
file. Besides, with PTTL you can open links written in plain text (not clickable
links): you select a link and open it with the right click PTTL menu. At last, ...
https://addons.mozilla.org/de/firefox/addon/623


*Copy and Go* by ofer affias
Copy marked text, paste it and Go to the URL on a new tab immediately
https://addons.mozilla.org/de/firefox/addon/6876


*Go to Selection* by Till Wiebke
Öffnet nicht verlinkte URLs in neuen Tabs oder Fenstern.
https://addons.mozilla.org/de/firefox/addon/2348

Comment 52

[Ben Bucksch (:BenB)]

Hb, it's nice that we have so many extensions providing that. Thanks for the pointers.
The mere fact that an extension can do it doesn't negate that FF core should implement it, though. In fact, that we have so many extensions hints that it's an often-requested and important feature for all users.

If you see how often there are URL on websites - esp. in web forums - which are not linked, you can see that it's a feature needed by most users.

Comment 53

[Charles]

Needing an extension for every basic feature is not even laughable, it's pathetic...

Comment 54

[Paul [pwd]]

Is this not fixed? I'd assume the fix got taken from Firefox?

Comment 55

[Philip Chee]

We haven't ported the functionality from Firefox (yet).

The following Firefox bug/patch (and followup bugs) would need to be adapted for SeaMonkey:

[Bug 454518] allow opening URLs that are not linked from the context menu (if selected).
  [Bug 515512] Text urls that don't have the leading protocol should have the link context menu options when selected.
  [Bug 526952] Context menu while right-clicking a link should open the link, not link-like text that happens to be selected.
  [Bug 242852] I wish that "Copy link text" were a hyperlink contextual menu option,
  [Bug 591953] Show the "Open Link" context menu item for URLs with hyphens.
  [Bug 720023] Context menus for selected URLs should be the identical as for links.
  Bug 263433 - 'text-link' XUL widget should open tabs rather than windows.