TestEmbed, Mozilla 1.2b 20020922 build. Build instructions for testEmbed located at: http://lxr.mozilla.org/seamonkey/source/embedding/qa/testembed/README.TXT#170 1. Enter a uri string with lead space(s) into NS_NewURI. Use one of these protocols: about, js, mailto, or data. Example: about:plugins. (In TestEmbed, select Tests > NSNewChannel. Enter url in the urlDialog). 2. NS_NewURI() return value succeeds. 3. Pass the nsIURI object into NS_NewChannel(). 4. Check return value. (In TestEmbed, screen dialog appears. Or you can check in logfile in C:/temp/TestOutput.txt) Result: Return value fails. Note that for urls passing through StandardUrlParser (http, ftp, file), lead white spaces before the url won't matter; NS_NewChannel() succeeds. In nsURLParsers.cpp, nsBaseURLParser::ParseURL(), lead white space is skipped. (http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsURLParsers.cpp#98). But that isn't happening in nsSimpleURI.cpp, nsSimpleURI::SetSpec() (http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsSimpleURI.cpp#139)
depstein: how critical is this bug? are there any reports of it impacting websites or mozilla embedders?
Darin, I don't know of any reports about this, but will pass on anything I hear about it. Similar urls passed into nsIWebNav->LoadURI() are loading ok, so users probably won't see it for page loading. It's happening at NS_NewChannel().
One other thing is that because NS_NewChannel fails for these cases, nsIUriLoader->OpenURI(), which accepts channel input, fails as well.
QA Contact: benc → depstein
-> default owner
Assignee: darin → nobody
QA Contact: carosendahl → networking
is this fixed?
I ran a small test with " about:plugins" - NS_NewChannel returns NS_OK and a non-null channel.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.