100176 - URL: Schemes should error if they are not registered.

Status: VERIFIED DUPLICATE of bug 86486

(Core :: DOM: Navigation, defect, P3)

Description

[benc]

STEPS:

click on a link that is not "registered". No error is returned.

Only "location" field reports URL scheme errors.

Paste wais://something.com/searching?forthis into the field and hit return.

severity=major, as the number of mozilla-based products and users grow, the will
find this painful for daily use.

Comment 1

[Tom Everingham]

-> docshell

Comment 2

[neeti]

When I type wais://something.com/searching?forthis in the url bar, I get a
dialog with "wais is not a registered protocol"

Comment 3

[Tom Everingham]

the problem shows up only when you click on the link, typing it or pasting to
the url bar results in the proper error message.

Comment 4

[benc]

This error messages also has a separate problem. It only shows up if the URL
scheme is "://" terminated, not just ":", which is all that is required.

I thought there was another bug for this, but I can't find it. Should I create a
new one?

Comment 5

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 6

[benc]

qa to me.
Can someone tell me where mozilla stores the list of URL schemes?

Comment 7

[Adam Lock]

Attachment: Patch

Simple patch, URI fixup returns immediately if NS_NewURI returns
NS_ERROR_UNKNOWN_PROTOCOL.

Reviews please.

Comment 8

[Adam Lock]

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

Comment 9

[Andrew Hagen]

Blocks 61999, URI parsing tracking bug.

Naive question: does this also fix bug 86486 or bug 110880? 

Thanks for working on this important nuts and bolts bug. 

Comment 10

[Adam Lock]

Ben can you review the patch? It's nice and simple.

Andrew, I'll test to see if it fixes the other bugs too.

Comment 11

[Adam Lock]

Ben, can I have a review on the patch please?

Comment 12

[Adam Lock]

Darin, could you review the small patch to URI fixup for this problem? Thanks

Comment 13

[Darin Fisher]

Comment on attachment 87096 [details] [diff] [review]
Patch

sr=darin

Comment 14

[Kathleen :Brade]

Comment on attachment 87096 [details] [diff] [review]
Patch

r=brade

Comment 15

[Adam Lock]

Fix checked in

Comment 16

[Andrew Hagen]

Has the fix been checked into the trunk?

Comment 17

[Adam Lock]

Into the trunk, not into the branch

Comment 18

[Andrew Hagen]

I'm not sure how these things work. Are there plans to check it into the trunk? 

Comment 19

[Mark Bitterling]

Looks like this patch blocks a user's ability to specify a port number (ie
http://foo.bar:81 ).

Comment 20

[Andrew Hagen]

Wrong. This patch does block a typed in URL like  yahoo.com:80  but does not
block http://yahoo.com:80 .

Comment 21

[Tim Powell]

Anything typed into the URL bar without a protocol should be treated as http.
URIs including a port but with no protocol identifier should be treated as http.
So mozilla.org:80 and 207.200.81.215:80 should work. This worked in Netscape 4.x
and Mozilla 1.0.

Mozilla is a web browser. That it might support other than http protocols should
not introduce usability problems. It should never be required to type http://.
HTTP should be assumed. Reopening since this patch broke basic functionality.

Comment 22

[Andrew Hagen]

Before the fix, Mozilla would not produce any error message when a bad protocol
was called. That was bad.

A lot of users want to go to specific IP ports at HTTP URL's they type in,
however, without the hassle of prepending "http://". So maybe we should not
throw that error message when a user types in something like
"ethernetswitch:779" or similar. We could decide that if the string after the
colon is a number, then assume it's a web address with a protocol. If the number
has dots in it, like 127.0.0.1, then we would still treat it like the IP address.

One further problem. Doesn't Mozilla honor IP addresses in the form of
hexidecimal and decimal? Such as the addresses on the following linked page?

http://www.livinginternet.com/?i/iw_dns_alias.htm

Yet, maybe support for those kinds of IP addresses is going away. See bug 67730
and bug 150966.

The allowable range for IP ports is 1-65535.

http://www.iana.org/assignments/port-numbers

Thus, if the number following the comma is a decimal number within that range
and without dots, we should treat it as an IP port and try to open it as a web
page. Otherwise, we'd treat the string in front of the colon as the protocol. 

I suggest that this bug be closed and a new bug opened to add on the additional
functionality.

Comment 23

[benc]

URL bar has it's own logic and should becaus it is they entry point of end-user
input (ironic huh, b/c nobody actually likes typing full URLs).

If there is specific user input that is breaking, create a bug, put it under URL
bar, and mark it keyword==regression if it worked before.

re: IP addresses, URL formating allows only dotted quads in decimal. Single
decimal and dotted quads in hex might be allowable formats in other situations
(ifconfig + hex is the best example I can think off...), but not here, even
though this is somewhat broken in bug 67730, as you mentioned above.

Comment 24

[benc]

Adam: based on your checkin date, this should work in Mozilla 1.1b.

I'm clicking on the URL link for this bug, but I don't get an error. 

Comment 25

[Adam Lock]

Marking fixed again, since it checkin appears to work in Mozilla 1.1

Comment 26

[benc]

What happens if you click on the link in the label of the "URL" field for this bug?

I'm running 1.1 on Win 98, and I don't get any feedback.

Comment 27

[Adam Lock]

Ah, reopening. I was cut and pasting into the url bar where it does display an
error.

Comment 28

[Juan José Mata]

Changing target milestone to 'Future' since these seem to have missed the 1.2
alpha.  If you are still considering a fix for 1.2 please re-target accordingly.

Comment 29

[benc]

bz: is this a bug of 86486?

adam, based on the checkin you make have some behavioral change that I probably
did not understand? The patch looks like it would affect URL bar only?

Comment 30

[Boris Zbarsky [:bzbarsky]]

Yes, this is a dup.  Yes, Adam's checkin only affected the URL bar behavior (or
more to the point we stopped using URI fixup for non-url-bar uris sometime).

*** This bug has been marked as a duplicate of 86486 ***

Comment 31

[benc]

V/dupe.