Processing of URLs in the format protocol://uri where the protocol is not supported (i.e. https) is not correct or at least not as I would expect. If the URL is entered manually, a dialog appear with the error: Netscape is unable to locate the server: protocol: The server does not have a DNS entry. If the URL is referred from a page, the browser try to access to a URL formed from the base URL of that page and the "invalid" URL appended to it (i.e. a link from http://www.server.com/home/insecure.html to https://www.server.com/home/secure.html will be expanded into http://www.server.com/home/https://www.server.com/home/insecure.html) NOTE: the same happen with Netscape Communicator 4.04 for Linux/i386 IMHO this behavior generates confusion when dealing with invalid URL (i.e. mispelled http) but specially with a valid, but still unsopported, protocol like https. In this case an error dialog with a message like 'unsupported protocol' or 'protocol not yet supported' would be more appropriate and less confusing.

Setting all current Open/Normal to M4.

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

paulmac, is this Linux specific, or all platforms?

cross-platform

Marking till Necko lands...

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Pl. check with Necko.

No error messages yet, so leaving this bug open.

This is related to other webshell changes that Jud is making (bug 10848) so reassigning to him. This is not essential for m9.

determining when to throw a "protocol not supported" dialog is hard to do because one doesn't know whether the protocol itself isn't supported or if the url is malformed. perhaps we just throw a dialog indicating that the url was malformed? After a fix I just checked in, current behavior is that we do absolutely nothing.

ok. what should really happen here is we should kick what was typed into the url bar out to the keyword server. we need keyword server support first though.

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

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

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

Verified Dupe of bug 11869. Valeski determined that ssending URL to internet keyword server was a the solution to this issue. Internet keywords is hooked up.

Judson: sorry about commenting in really old bugs, but I need to get a clarification about what you intended here: For unrecognized schemes, did you want ONLY URL bar (in other words, ambiguous user input) or ALL URL entry ponts (HREF, SRC, etc.) to go to internet keywords? IMHO, you would want this feature to be in URL bar only. The reason I ask is because we STILL don't have error messages for unrecognized schemes, and I think this oversite began around here.

NOTE: second problem (URL mindlessly adding base to an unrecognized URL scheme) has worked for a long time...