mozTXTtoHTML:<chrome://> is reconized as a URL (also <gopher://> <telnet://>)

RESOLVED WONTFIX

Status

()

Core
Networking
P3
enhancement
RESOLVED WONTFIX
18 years ago
2 years ago

People

(Reporter: Henrik Gemal, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
If you have a mail that consist of the following lines:
http://
ftp://
chrome://
file://
killer://

both chrome:// and file:// are reconized as a URL's and are hyperlinked. The 
other ones aren't!

Pressing the <file://> and <chrome://> links with my Mozilla does absolutly 
nuthing!

Build 2000052020 on Win2K

Comment 1

18 years ago
isn't this a duplicate of bug 40028

Comment 2

18 years ago
gemal, please create a test web page (HTML) with a <chrome://> link for andreas
Blocks: 19313
(Reporter)

Comment 3

18 years ago
Not sure I understand.. Since I'm having the problem with URL's in a mail, not 
in a webpage.

Comment 4

18 years ago
I've send myself a very similar message and started to investigate. ftp:// and
http:// are not hyperlinked because they are not valid URLs, the host is
missing. file:// and chrome:// are valid, so they are hyperlinked as described
by Ben in bug 40028. I assume they don't work because they are caught by the
scriptsecuritymanager as not allowed. I will try to confirm this assumption
soon. Maybe Ben's code can incorporate the ScriptManager too and only highlight
URLs if they pass it.

Comment 5

18 years ago
Yes, file:// and chrome:// are caught by nsScriptSecurityManager::CheckLoadURI.
I suggest to call it in Ben's code in addition to create the URL and based on
the result hyperlink the URI or not. Moving to Ben Bucksch.
Assignee: andreas.otte → mozilla

Comment 6

18 years ago
Removing bug 19313 as dependency. Severity enhancement.

Over to mscott.

(I'm not in the mood to implement this. I'd mark it LATER.)
Assignee: mozilla → mscott
No longer blocks: 19313
Severity: normal → enhancement

Updated

18 years ago
Target Milestone: --- → M19

Comment 7

18 years ago
also, I see that layout (or mail?) is recognizing:
 ftp:// urls (but clicking them doesn't work?)
 gopher:// urls
 telnet:// urls
OS: Windows 2000 → All
Hardware: PC → All
Summary: chrome:// is reconized as a URL → chrome:// is reconized as a URL (also gopher:// telnet://)

Comment 8

18 years ago
Adding brakets in summary, since the URL is supported to end after "//".
Summary: chrome:// is reconized as a URL (also gopher:// telnet://) → <chrome://> is reconized as a URL (also <gopher://> <telnet://>)

Comment 9

17 years ago
40028 says this is a duplicate of it, and it is verified/invalid?!

It sounds like this is still and issue, but what needs to be fixed?

Is there any point in these scheme-only URLs being linkified? what is the 
behavior when you click on them?

Comment 10

17 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Comment 11

14 years ago
ok, i tried this with mozilla 1.7, and i didn't see the chrome:// URL get
highlighted.  http://, ftp://, and file:// were highlighted.

Comment 12

14 years ago
Darin: I'm assuming you are talking about the way this works in text email?
Summary: <chrome://> is reconized as a URL (also <gopher://> <telnet://>) → mozTXTtoHTML:<chrome://> is reconized as a URL (also <gopher://> <telnet://>)

Updated

10 years ago
Assignee: mscott → nobody
This isn't on anyone's work list and realistically is an abandoned idea. I will close as wontfix - if someone has a patch or is actively going to work on it please reopen. (but please, only then.)
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.