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.

-> docshell

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

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.

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?

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 adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

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

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

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

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.

Ben can you review the patch? It's nice and simple. Andrew, I'll test to see if it fixes the other bugs too.

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

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

Comment on attachment 87096 [details] [diff] [review] Patch sr=darin

Comment on attachment 87096 [details] [diff] [review] Patch r=brade

Fix checked in

Has the fix been checked into the trunk?

Into the trunk, not into the branch

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

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

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

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.

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.

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.

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.

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

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.

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

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.

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?

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 ***

V/dupe.