User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a4) Gecko/20040923 Camino/0.8+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a4) Gecko/20040923 Camino/0.8+ go to the url. it does nothing. no error. no response. no nothing. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: imho, it should display an error saying that the url was not formed correctly. or it should just transparently remove the space???
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Camino1.0
hey, in osx firefox pr1, it causes the page to go to google! "The "I'm Feeling LuckyTM" button automatically takes you to the first web page returned for your query. An "I'm Feeling Lucky" search means less time searching for web pages and more time looking at them."
Confirmed. Page shows Document: Done in lower left corner of window but nothing has happened. No error message or even action taken in trying to load anything (no progress bar loads in the lower right corner). Should either auto correct or throw an error dialog requesting action. I am not a big fan of browsers that redirect on these kinds of errors. That ends up leaving people more confused as to what the did and/or what is going on. 10.2.8/Build 2004082512 (v0.8.1)
(In reply to comment #3) > Confirmed. Page shows Document: Done in lower left corner of window but nothing > has happened. No error message or even action taken in trying to load anything > (no progress bar loads in the lower right corner). > > Should either auto correct or throw an error dialog requesting action. I am not > a big fan of browsers that redirect on these kinds of errors. That ends up > leaving people more confused as to what the did and/or what is going on. > > 10.2.8/Build 2004082512 (v0.8.1) Also, as an addendum that may be covered under another bug... When I tried this (in another tab), as I look now my Tab title is stuck on Loading...
This still happens and we definitely *should* be sending them to the error page, but I'm not sure this is bad enough for 1.0. Retargeting for 1.1.
Target Milestone: Camino1.0 → Camino1.1
*** Bug 332719 has been marked as a duplicate of this bug. ***
From the dupe: 1. Go to http: //apple.com or http:// apple.com or http:/ /apple.com --- In my testing, http:// www.apple.com brings the error page, but http:// apple.com illustrates this bug, which is an even worse inconsistency. If the space is anywhere in the protocol (up to and including the colon), you get the "this url is not valid" sheet; if the space is anywhere after the colon, you get this bug. Is the url parsing something we get from Core, or do we do it ourselves?
Component: General → Location Bar & Autocomplete
QA Contact: location.bar
Assignee: mikepinkerton → nobody
Status: ASSIGNED → NEW
Component: Location Bar & Autocomplete → Networking: HTTP
Product: Camino → Core
QA Contact: location.bar → networking.http
Target Milestone: Camino1.1 → mozilla1.9alpha
Version: unspecified → Trunk
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Make nsStandardURL::SetSpec and SetHost consistent with respect to handling spaces in hostnames (i.e. make both return an error) The problem is that URI fixup uses SetHost to create the fixup URI, and docshell later on uses GetSpec/SetSpec on the URI it gets from URI Fixup. it doesn't handle failure from that SetSpec particularly well.
OS: Mac OS X 10.2 → All
Hardware: Macintosh → All
CCing mento in case we end up needing to take this on a minibranch for 1.1.
another patch I kind of forgot about :( checked in now: Checking in nsStandardURL.cpp; /cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp,v <-- nsStandardURL.cpp new revision: 1.95; previous revision: 1.94 done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
I'd write the testcase if I had time, but I'm not sure I'm likely to have it in the near-ish future.
*** Bug 364489 has been marked as a duplicate of this bug. ***
Possible unit test v1 * Not sure if this is the correct test for this case.
As above but with the correct diff formatting.
Comment on attachment 261960 [details] [diff] [review] As above I'd have created a standard URL more directly, but this works too
Attachment #261960 - Flags: review?(cbiesinger) → review+
(In reply to comment #15) > (From update of attachment 261960 [details] [diff] [review]) > I'd have created a standard URL more directly, but this works too > I can change it if that's a problem.
Checking in test_bug261425.js; /cvsroot/mozilla/netwerk/test/unit/test_bug261425.js,v <-- test_bug261425.js initial revision: 1.1 done
Flags: in-testsuite? → in-testsuite+
Whiteboard: [checkin needed]
Looks like part of this regressed because the test was broken: bug 431890.
You need to log in before you can comment on or make changes to this bug.