Closed Bug 22859 Opened 25 years ago Closed 25 years ago

Mixed/upper case URL's don't work in mozilla

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jst, Assigned: warrensomebody)

References

()

Details

(Whiteboard: [PDT+]w/b minus on 03/10 [Fix attached])

Attachments

(1 file)

Clicking on urls with uppercase characters in the scheme (protocol) field doesn't work correctly on any platform. Currently it works on Win32 because of bug #22712 but once that is fixed Win32 will break too! The reason for this is that if a user clicks on a HTtp://... link the networking code tries to create a component://netscape/network/protocol?name=HTtp component, this is wrong, it should be component://netscape/network/protocol?name=http Same thing happends with JavaScript url's and probably others.
Assignee: gagan → warren
Target Milestone: M15
asdf
fix for this in ANDREAS_URL_BRANCH
*** Bug 24783 has been marked as a duplicate of this bug. ***
This is XP now. This is only partly fixed (I assume ANDREAS_URL_BRANCH landed yesterday), HTtp://... works now but JavaScript:... doesn't work yet...
OS: Linux → All
Hardware: PC → All
Summary: Mixed/upper case URL's don't work in non-win32 mozilla → Mixed/upper case URL's don't work in mozilla
javascript urls seem to work a very different way, does anyone know where to look?
This patch fixes the JavaScript:... handling but I'm afraid this will brake other things, unless protocols are *allways* lowercase? --- nsSimpleURI.cpp 2000/02/03 03:44:10 1.15 +++ nsSimpleURI.cpp 2000/02/03 18:42:05 @@ -105,6 +105,7 @@ NS_ASSERTION(n == count, "Mid failed"); if (mScheme) nsCRT::free(mScheme); + scheme.ToLowerCase(); mScheme = scheme.ToNewCString(); if (mScheme == nsnull) return NS_ERROR_OUT_OF_MEMORY;
I think this patch is safe, the only mixed case scheme I could find was mailboxMessage and this is gone now.
I vaguely remember seeing IMAP:... urls someplace but I might be wrong, and they could even be hadled by their own URI implementation, couldn't they. If you the patch is OK then please go ahead and check it in...
It seems wrong for me to have nsStdURL lowercase the scheme name. We fixed the protocol lookup to be case insensitive. There must be another case we have to fix somewhere.
Warren, note that it was nsSimpleURI and not nsStdURL, but it still might be wrong...
Warren: Both has to happen. First we have to lowercase to search and find the right component. And second we have to lowercase the scheme to move urls like HtTp://www.mozilla.org to http://www.mozilla.org which is only cosmetical but looks much nicer. We are already doing it in nsStdURL.cpp with the landing of ANDREAS_URL2_BRANCH. So what's missing now is to lowercase at the place where the "javascript-protocol-handler" is searched for if something like this exists.
It's arguable whether javascript: mailboxmessage: looks nicer than JavaScript: or MailboxMessage:. I think we should leave the URL as typed. The case-insensitive comparison should happen elsewhere.
If I remove the lowercasing of the scheme in the urlparser case four of the testcase does not work anymore. There must be more places than in nsIOService where the search for the protocol is case sensitive.
I just realized that if I type "http://www.MOZILLA.Org" into the URL bar and hit enter the url I just typed is changed to "http://www.mozilla.org". Is this due to some of the changes that were made to fix this bug or is it unrelated to those changes?
No, that was related to a very similar bug, now fixed, can't find the number at the moment
Very likely a dup of 21686.
No, not a dup, try the testcase. Here is something different beyond lowercasing the scheme while trying to get the right protocol-handler. To fix this we currently have to really lowercase the scheme in the URIs. This is currently done with Std-Urls, but not with Simple-Urls, and that's why the javascript example fails. There must be another case of case-sensitive comparison for the scheme, it's just not found yet.
Okay, found it. It was the securitymanager. See the attached patch to make it caseinsensitive. Also target="_blank" seems to be currently broken, the new browser instances are created but you can't see them. They appear briefly when you shutdown the app. But that's another problem.
*** Bug 27765 has been marked as a duplicate of this bug. ***
Nominating for beta1, this is nothing really serious but the fix is available and this would make more websites work without much effort, and I bet we'll get (more) dups of this one if it's not fixed before beta1.
Keywords: beta1
Whiteboard: [Fix attached]
better patch is on bug 29419
*** Bug 30655 has been marked as a duplicate of this bug. ***
*** Bug 29995 has been marked as a duplicate of this bug. ***
Putting on PDT+ for beta1. Please fix by 03/10
Whiteboard: [Fix attached] → [PDT+]w/b minus on 03/10 [Fix attached]
Depends on: 29419
As far as I can tell this was fixed when norris fixed bug 29419, marking as such, please reopen if you disagree.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
No longer depends on: 29419
verified: Linux 2000030809 Mac 2000030808 NT 2000030809
Status: RESOLVED → VERIFIED
*** Bug 31260 has been marked as a duplicate of this bug. ***
*** Bug 31243 has been marked as a duplicate of this bug. ***
*** Bug 31243 has been marked as a duplicate of this bug. ***
*** Bug 31243 has been marked as a duplicate of this bug. ***
*** Bug 31974 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: