Closed Bug 51206 Opened 25 years ago Closed 15 years ago

Detect if user tries to visit an e-mail address

Categories

(SeaMonkey :: Location Bar, enhancement)

Product:
SeaMonkey
Component:
Location Bar
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mpt, Unassigned)

References

Details

(Whiteboard: [Halloween2011Bug])

To some users, the distinction between Web addresses and e-mail addresses is not clear. They may try to visit an e-mail address in Navigator, or send an e-mail message to an URL. I suggest that if the user enters an e-mail address into the location field in Navigator, Mozilla should pop up a dialog: The address `foo@bar.org' is an e-mail address, not an Internet location. Would you like to compose a new message to this address? ( Cancel ) (( New Message )) (The reverse case is probably not able to be handled by Mozilla because of auto-completion of addresses -- unless the user enters `http://' as part of the e-mail address, which is unlikely.)
warning user:pass@host:21 is probably a valid url for an authenticated ftp server
Yes, but can the pre-@ part of an e-mail address contain a colon, as such an FTP address would?
How can you distinguish between an email address and a message-id. If the user copies and pastes a partial {s}news: URI, you could have problems. It's a nice idea, though, as long as there is an advanced pref to disable it.
I suggest to use the address recognition implementation in our TXT->HTML converter, it does this type of "completion" already. It would have to be made a bit more generic (currently, it returns HTML), but that would be possible and not even too hard. (BTW: Does the current browser completion still live in webshell or how it is called today?)
BTW: I could do the tweaking mentioned above.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
test performed on Netscape 6 beta 3 mac, modern skin If I write an e-mail address with the @ in the URL field Netscape doesn't open a new Mail message with the e-mail address in the 'To:' field, like in Explorer 5 :( If I write a text without '.', 'www.', or 'http://' in the URL field Netscape can send directly a search to the default search engine when I press enter. Why not? Better if I can also use boolean operators +, -, ", etc.
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Status: ASSIGNED → NEW
*** Bug 86180 has been marked as a duplicate of this bug. ***
>I suggest that if the user enters an e-mail address into the location field in >Navigator, Mozilla should pop up a dialog: > >The address `foo@bar.org' is an e-mail address, not an Internet location. >Would you like to compose a new message to this address? >( Cancel ) (( New Message )) Is the dialog necessary? I think it would make more sense to just open a message composition window.
<http://Jan@example.com> is a valid HTTP address (user Jan at <http://example.com> (IIRC). If the user enters Jan@example.com in the urlbar, current browser extend to that URL. This is not only of theoretical nature: Here in Germany, one of the largest webhoster advertizes this URL format, claiming that it were cool to be able to surf to an "email address" or, in other words, to use the "same" address for both email and website. IMO, this is not very smart, but it exists. If you implement this bug, users will have to enter "http://Jan@example.com". Maybe the hoster deserves that, but you should consider that. But surely "user@ftp.example.com" is more common. These users will have to enter "ftp://ben@ftp.example.com".
Jesse's right, a dialog would be silly. We should just put up a composition window. --> URL Bar
Assignee: mpt → blakeross
Component: User Interface Design → URL Bar
QA Contact: zach → claudius
I'm not sure that this bug is a good idea, for the reasons given in my last comment.
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
IMHO this should be marked WONTFIX for the reason that user@example.com is a valid format for a HTTP URI. Here's an alternative suggestion: how about if when the user types an @ character into the Location bar a new entry appears at the bottom of the autocomplete drop-down (immediately above or below the search item) that says 'Send email to user@example.com' (or whatever address the user has typed). Clicking on this would launch the message composition window with the email address filled in the To field. That way the user can still visit http://user@example.com/ by pressing Enter or clicking 'Go' or send an email to user@example.com with the autocomplete thingy. What's everyone else think?
> IMHO this should be marked WONTFIX for the reason > that user@example.com is a valid format for a HTTP URI. Using this logic, typing in "ftp.mozilla.org" into the address bar should go to http://ftp.mozilla.org since "ftp.mozilla.org" is a valid HTTP address as well. I think that having "user@domain" default to MAILTO: is even better than having "ftp.domain" default to FTP://. Many people know an email address is "user@domain" (even bugzilla knows!) but not many beginning users know that they have to type "mailto:" By the way, typing in user:pass@host:21 should activate the application responsible for the "USER:" protocol on port 21 of domain "host", no? The HTTP:// or "FTP://" would be required for this case. So this change would only affect people who are trying to go to a HTTP site without typing in "HTTP://" who have an account on that server and who aren't supplying their password in the URL. I think that is what is called an "edge case". And if we are going to support this edge case why not support the edge case where I am user "mailto" with password "alexbishopuk" on the site "yahoo.com": mailto:alexbishopuk@yahoo.com Also, I'd rather not have it be a pref.
> Using this logic, typing in "ftp.mozilla.org" into the address bar should go to > http://ftp.mozilla.org since "ftp.mozilla.org" is a valid HTTP address as well. It should. Why doesn't it? Anything that forces users to explicitly specify that what they typed in a URL bar ("defn: 'bar for URLs') is actually a URL should be avoided. In the FTP case, we should at least check the machine's not running an HTTP server first by attempting to connect to port 80. If there's no evidence that users are typing email addresses into this bar (in _Mozilla_ or derivatives) then there is absolutely no need to do this. Even if there is evidence, we should discuss whether to educate the user in some way or to encourage the broken behaviour. Gerv Gerv
> If there's no evidence that users are typing email addresses into this bar There is. I've seen it just yesterday. > Even if there is evidence, we should discuss whether to educate the user in > some way or to encourage the broken behaviour. Agreed. <offtopic> > > Using this logic, typing in "ftp.mozilla.org" into the address bar should go > > to http://ftp.mozilla.org since "ftp.mozilla.org" is a valid HTTP address > > It should. Why doesn't it? ftp.mozilla.org is obviously an ftp server (because it starts with "ftp.", which is the conventional name for ftp servers and for exactly that reason does Mozilla try ftp there). It might also run a http server, but the main purpose is the ftp server and we should try that one first. > Anything that forces users to explicitly specify that what they typed in a URL > bar ("defn: 'bar for URLs') is actually a URL should be avoided. BTW: Your sentence strictly makes no sense: I know no case, where the user types a valid URL and we visit something else - apart from an autocomplete bug. What you mean is probably "the user should never have to type "http://"". </offtopic> I think, the ftp example is not really relevant here, because it misses one important fact: The urlbar is for a specific Navigator window, not all of Mozilla. We visit ftp servers in Navigator. But we don't compose emails in Navigator. Mailnews will handle email addresses just fine.
Status: NEW → ASSIGNED
Priority: P3 → P4
adding self to cc list
Product: Core → SeaMonkey
Assignee: hewitt → nobody
Status: ASSIGNED → NEW
Priority: P4 → --
QA Contact: claudius → location-bar
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
typing a_j_mechelynck@yahoo.co.uk into the URL bar: a dialog pops up: (?) You are about to log in to the site "yahoo.co.uk" with the username "a_j_mechelynck", but the website does not require authentication. This may be an attempt to trick you. Is "yahoo.co.uk" the site you want to visit? [ No ] [ Yes ] This (an "Are you sure?" dialog before visiting an HTTP address which could also be — and in fact is — an email address) is one possible solution. I'm setting this WFM for the time being but not sure it's the right solution. (NEW? WONT?) Christian: sorry for the bugspam, tried to reach you on IRC but no answer.
Resolution: EXPIRED → WORKSFORME
Whiteboard: [Halloween2011Bug]
Tony, we do not detect that the user tries to visit an email address, we still assume he means a http: website. So, no, this is not working as expected by the bug filer.
Resolution: WORKSFORME → WONTFIX
(However, by now, most of the computer-user population understands this and this "bug" hasn't been a major problem. So, WONTFIX.)
Whiteboard: [Halloween2011Bug]
The Whiteboard entry was added intentionally to track bug triaged during the latest Bug Event: please don't remove.
Whiteboard: [Halloween2011Bug]
Filed bug 1117747 for the same thing in Firefox
You need to log in before you can comment on or make changes to this bug.