743029 - Composition: Be more helpful for Insert > Link (with or without selected text), similar to message reader auto-linkification of text which looks like URL

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, enhancement)

Description

[mihai]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

I'm using Thunderbird 11. I've tested the following on TB 10 & 11, in Win7, Ubuntu 11.10, and Mac OS X 10.7.

I added links into emails using the Insert|Link... option. Sequentially, I created separate links, each containing the following, respectively:
• "byu.edu"
• "www.byu.edu"
• "http://byu.edu"
• "http://www.byu.edu"

*I made sure that all htm/html/hyperlink handling registries were associated to Firefox and IE, respectively (on separate tests).


Actual results:

"byu.edu" and "www.byu.edu" didn't open in my Internet browser. They were treated as local links on the computer. This is because in the Location field of Insert|Link... I didn't type "http://" at the beginning of the web address.

"http://byu.edu" and "http://www.byu.edu" did open in the Internet browser, due to the present "http://"


Expected results:

All of these ("byu.edu", "www.byu.edu", "http://byu.edu", "http://www.byu.edu") should automatically open in an Internet browser. If instead of using Insert|Link... you just type "mozilla.com" in an email, TB will automatically add the "http://" to the automatically created link. I assume that Insert|Link.. should use the same web address recognition algorithm.

I work in a business environment and not having to type the "http://" prefix would be of great help - not to me, but to less IT savvy users.

Thank you.

Comment 1

[Hashem Masoud]

(In reply to mihai from comment #0)
In my opinion, this is not a bug. You might want to specify another URI scheme (like FTP).

Comment 2

[Ludovic Hirlimann [:Usul]]

For now we don't really want to assume that links will be http, you can also give path links to file. WONTIFX

Comment 3

[mihai]

(In reply to Ludovic Hirlimann [:Usul] from comment #2)
> For now we don't really want to assume that links will be http, you can also
> give path links to file. WONTIFX


Well this poses a problem to users who aren't as knowledgeable in computer stuff. Other email clients manage the issue without any problems. 

We don't need to assume all links are http, Ludovic. If TB manages this fine with links that one types in the email body, why wouldn't it do the same with links inserted via Insert|Link...? And mind you, it doesn't even recognize addresses like "www.address.com". This is a problem, as one migrating from Outlook to TB will disregard the "http" insertion, which will result in dead links. There should at least be an option for web/local/network etc. links (i.e., Insert|Web Link...).

If TB is made for everyone to use, then one would expect it to also function as such. Being user-friendly should matter, even if the product is a free one.

Thank you.

Comment 4

[Pedro Garcia Rodriguez]

Hi:

I agree that being user-friendly shoud matter, even if the product is a free one but I don't find a reason to assume by default that the user wants to use http protocol. 

And believe I have done tons of test to make Thunderbird a more usable and user friendly product but I can't find this behavior as a bug.

So I only can say +1 to Ludovic and Hashem comments.

Thank you.
Best regards!

Comment 5

[Wayne Mery (:wsmwk)]

+1 to comment 4

Comment 6

[mihai]

I agree it's not a bug......... I reported this as a suggestion, on the TB website, and I was asked to report it as a bug. Could you tell me where to send suggestions?

Thanks.

Comment 7

[Jim Porter (:squib)]

(In reply to mihai from comment #6)
> I agree it's not a bug......... I reported this as a suggestion, on the TB
> website, and I was asked to report it as a bug. Could you tell me where to
> send suggestions?

This is where you'd send suggestions, but not all suggestions will be accepted. CCing bwinton though, since he might have some input.

Comment 8

[Thomas D. (:thomas8)]

I agree with Ludovic that we cannot simply assume a protocol and change the link location after user closes the Insert Link dialogue.

However, I also think reporter didn't phrase this RFE very well, and there might be some nice ideas here.
As reporter said (albeit with wrong details), we already use a limited link recognition in message reader. Surely we could suggest the same when editing links during composition.

STR

1 compose msg with Options > Format > Auto-detect (which is default format)
2 type the following lines into body (*without* adding any hyperlinks!):
a) mozilla.com
b) ftp.mozilla.com
c) www.mozilla.com
d) http://www.mozilla.com
3 send to yourself
4 receive msg in TB msg reader
5 Ctrl+U to check source text

Actual Result (URL auto-recognition in message reader)

a) mozilla.com is rendered as plain text (because there's no reliable hint about the protocol, or that this is intended as a link at all)

b), c) and d) are automatically linkified in msg reader (although there are no actual links in the source, it's all plain text)

b)        ftp.mozilla.com is rendered as link to
    ftp://ftp.mozilla.com
   (because in 99% of cases, ftp.something.com is URL with ftp protocol)

c)        www.mozilla.com is rendered as link to
   http://www.mozilla.com
   (because 99% of cases, www.something.com is URL with http protocol)

d) http://www.mozilla.com is rendered as link to (guess what)
   http://www.mozilla.com
   (because this is a full URL including protocol)

So in *message reader*, for the most common cases, we have smart link recognition which automatically appends an appropriate protocol to obvious strings that look like typical URLs.

Reporter is requesting that we should use similar / same recognition strategies for *message composition* when adding hyperlinks.

There are 2 scenarios of adding links:
1) Ctrl+L to Insert > Link (from scratch, no text selected)
2) Select text in msg body, then Ctrl+L to Insert > Link

I have several ideas how we could be more helpful in these 2 scenarios without making wrong assumptions or breaking the link dialogue, but I don't have time for the details right now.

As a caveat, and in partial agreement with Ludovic & others who recommended wontfix, we *cannot* change link locations *after the fact*, i.e. after closing the link dialogue. But we *can* come up with some more intelligent suggestions in the dialogue for obvious cases as long as either of link text or link location are empty, to reduce the amount of typing or copy and paste required.

Comment 9

[Thomas D. (:thomas8)]

And FTR, I don't know how many times I have cursed in this scenario (similar to reporter's scenario):

1 type www.mozilla.com (and forget how nitpicking TB is)
2 hit Ctrl+L
Actual result: Get mad that you have to
- either type the same URL all over again in the link location field, and that you can't even copy the link text from inside the dialogue while it's right in front of you!
- or close the dialogue, append http:// in msg body text, then Ctrl+L again (it is here especially where we can be more helpful with incomplete URLs, as in message reader).

Comment 10

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #9)

Sorry, I missed the important step here:

> 1 type www.mozilla.com (and forget how nitpicking TB is)

1b select text www.mozilla.com, then

> 2 hit Ctrl+L

Comment 11

[Thomas D. (:thomas8)]

More unfortunate things in this corner (needs new bug if there isn't one yet):
Local links, e.g. with link location "www.mozilla.com" (without http), are not indicated in any way in the message body, they come out as undecorated black text (albeit fully functional). Happy guessing where your links are...
Do we have a bug for that?

Comment 12

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #11)
> More unfortunate things in this corner (needs new bug if there isn't one
> yet):
> Local links, e.g. with link location "www.mozilla.com" (without http), are
> not indicated in any way in the message body, they come out as undecorated
> black text (albeit fully functional). Happy guessing where your links are...
> Do we have a bug for that?

I chose bug 777073 for that sake.