89118 - No error message for bad URL

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[jlarsen]

for bad url's like http:/// or http::// ns4.x gives and error message while
mozilla just sits there and ignores it. This is important when manually entering
a URL as if you make such a typo it appears that mozilla is ignoring the enter
key and not responding, which makes mozilla appear to be broken. Anyways error
messages are good things, even if it is the "no server found" error that
netscape gives. Should a more descriptive error message be created?

Comment 1

[James Paige]

This sounds like it might be a dup of bug 86133 , but that was fixed on June
26th. What build ID number are you using? Always mention your build number when
posting a new bug.

Comment 2

[R.K.Aa.]

naw.. i see this with a current cvs build on linux as well:
http:://something.com or http:///something.com doesn't do anything.

Throbber doesn't even bother to move, so moz somehow knows it isn't worth trying
- but it doesn't tell the user that something went wrong.
This isn't really a dns resolve/connection issue. It probably ought to spawn an
alert about invalid protocol..or plain wrong usage.

NC4.* error message says "Netscape: Error" on the alertbox titlebar, and reads:
"Netscape is unable to locate the server (no name specified).
Please check the server name and try again."

Comment 3

[[e-mail]]

Clicking on the URL link given by the bug has no visible effect (Build 2001080304)

Comment 4

[benc]

Probably because of bug 19073, Necko doesn't return errors for non-existent files.

Comment 5

[Alec Flett]

reassign url bar bugs to new owner..

Comment 6

[Bradley Baetz (:bbaetz)]

No, this is because its an invalid url format. -> docshell, but this could be
layout generating the url for the link.

Comment 7

[Adam Lock]

Docshell is not displaying a message in response to NS_ERROR_MALFORMED_URI 
errors after trying to build a URI object from the text. There be a message for 
such occasions.

This is the code for the existing NS_ERROR_UNKNOWN_PROTOCOL error message

http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#2198

Comment 8

[Adam Lock]

Attachment: Patch displays an error message for malformed URLs

Comment 9

[Adam Lock]

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

Comment 10

[Conrad Carlen (not reading bugmail)]

Comment on attachment 56722 [details] [diff] [review]
Patch displays an error message for malformed URLs

r=ccarlen

Comment 11

[Alec Flett]

Comment on attachment 56722 [details] [diff] [review]
Patch displays an error message for malformed URLs

actually, can you use NS_LITERAL_STRING("malformedURI") instead?

Comment 12

[Adam Lock]

Attachment: Patch uses literal strings

Comment 13

[rpotts (gone)]

Comment on attachment 57596 [details] [diff] [review]
Patch uses literal strings

sr=[e-mail]

Comment 14

[Adam Lock]

Fix checked in

Comment 15

[[not reading bugmail]]

could this have created the alert boxes about not a valid url.  that popup on
adding bookmarks? see n.p.m.builds in 11-14 and 11-15 for bookmarks horkage.

-dennis

Comment 16

[Adam Lock]

Yes, it probably is. Bug 110081 is what you're referring to.

I suspect that this checkin has just exposed a bug in bookmarks that has lain
hidden while nsDocShell::LoadURI silently ignored malformed URIs.

Comment 17

[Judson Valeski]

hmm, I just entered "http::/sdfsdf" and didn't get a dialog; should I have?

Comment 18

[Adam Lock]

I stepped the code and the scheme parser itself is fixing this up into
http:///sdfsdf so it's valid as far as the docshell is concerned.

Comment 19

[Andreas Otte]

I wouldn't call that a vaild fixup since http needs a host, the (new!) parser
should error on this.

Comment 20

[Adam Lock]

This one is a bit fiddly to explain, but here goes...

1. The http channel is delegating parsing to nsStandardURL which uses the auth
parser.  It calls ParserURL on it...

2. The base method nsBaseURLParser::ParseURL gets called. This cuts off the
"http:" part and passes the rest (":/sdfsdf") to nsAuthURLParser::ParseAfterScheme. 

3. The ParseAfterScheme method counts the number of consecutive forward slashes
and assumes that the path part is the offset from the start of the string by
that amount, i.e. it thinks the path bit of the spec is "/sdfsdf" when it's
really "sdfsdf".

4. When the URL is reconstructed into a spec, it adds all the bits together as
scheme + "://" + auth + rest, which in this case is "http" + "://" + "/sdfsdf",
or "http:///sdfsdf"

Therefore the bustage in ParseAfterScheme for not checking calculating the
offset properly. It shouldn't assume that the string always starts with a number
of consecutive slashes.

Probably this needs to be a new bug for whoever is most familiar with these classes.

Comment 21

[Andreas Otte]

cc-ing darin who did the urlparser rewrite

Comment 22

[Darin Fisher]

i just filed bug 110880 to cover generating a NS_ERROR_MALFORMED_URI error for
http::/blah

Comment 23

[amutch]

Still not getting anything with MFCEmbed: build 11/20/2001 Nightly.

1. Enter http::/sdfsdf
2. Nothing happens

Comment 24

[Adam Lock]

See the previous comments. The http:/// form is reported as an error.

Comment 25

[amutch]

Adam,

Oops. Missed that it had been moved to another bug.  Thanks for getting this one
fixed!

Andrew

Comment 26

[amutch]

What is the expected behavior for this fix? 

Entering: http://www.something.com/

takes the user to "http://www.something.com/"

in current MFCEMbed nightly 1/7/2002 build.

I thought it was going to generate an error message. I guess this behavior is OK
but it's almost IE-like. "Don't know what you are doing? Don't worry, we'll
decide for you!"

Comment 27

[benc]

Adam, are you going to QA-verify this?

Comment 28

[amutch]

CLARIFICATION: 

The report should have included the "bad" http:///

What is the expected behavior for this fix? 

Entering: http:///www.something.com/

takes the user to "http://www.something.com/"

in current MFCEMbed nightly 1/7/2002 build.

I thought it was going to generate an error message. I guess this behavior is OK
but it's almost IE-like. "Don't know what you are doing? Don't worry, we'll
decide for you!"

Comment 29

[benc]

From looking at the code, it looks like a error message was added.

However, the two examples mentioned are still broken:

http:///www.something.com/ -> http://www.something.com/

http:://www.mozilla.org -> http://www.w3.org/Protocols/