build id: 1999051708 platform: windows nt ok, this is a really lame bug, and it's probably due to something not being hooked up yet - but if you have access to the netscape internal network, try going to http://aka using apprunner. result: the DOS window fills up with crud, viz.: s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http s://https://https://https://https://https://https://https://https://https://http any idea what's wrong?

Yes, it's a case of stuff not being hooked up yet. But getting attention to ugly stuff like this seems good to me. What's happening is this. Browser is given http://aka, which redirects to the secure https://aka (not just secure, but client certificate requesting server) At this point, control should be given over the the crypto module, but the crypto module isn't present yet, so the browser is barfing. Now, the thing is.. barfing is bad. Instead, there should be some manner of error-handling in the browser when it is given a url/protocol type (in this case https://) that it doesn't know how to handle. That might be the bug to enter on this, and it would probably be assigned to the netlib crew or whoever is handling the 'pluggable protocol' stuff, which I think is the same guys. Gagan is probably a good source.

Well, we're still barfing on this one as of the 1999061409 build under NT. The URL control is filled with crud, the DOS window is filled with crud, &c.

Necko landing...

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. ;-)

Fixed with Necko.

http://aka is now crashing badly - but if I remember correctly, this problem has now been fixed. Verifying.

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