Closed Bug 99091 Opened 19 years ago Closed 16 years ago
History is not case sensitive (case doesn't matter)
Mozilla assumes entries in its history are case-insensitive. This is not true for many web servers. The demo URL shows links from index.html to example.html to Example.html. From Example.html, the Back button jumps back two places to index.html. The same confusion from case insensitivity affects the Back button's drop-down arrow also. This strikes me as incorrect behavior. However, it is apparently bug-compatible with IE6.
IE6? Bah! We should be doing a case sensitive compare there.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Related to bug 82964?
History relies on nsIURI::Equals() which uses strcasecmp to compare urls. may be this should change. Shall look in to other options.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
Yes, that should definitely change. The logic needs to be smarter in that it can do a case insensitive compare on the host part of the url, but for the path part it will need to do a case sensitive compare.
A real-world test case: http://www.wikipedia.com/wiki/Spam (click the SPAM luncheon meat link) A simplified test case: http://www.cs.rose-hulman.edu/~yerricde/mozcasebug.html
*** Bug 129671 has been marked as a duplicate of this bug. ***
Apparently my bug (Bug 129671) got thrown in with this one even though it is not the same, but directly related. When a link is followed that contains uppercase letters in the server address, the URI is not displayed as visited, but a version of the same URI with all lower case letters in the server name is displayed as visited. This appears to be becuase Mozilla autmatically changes any upper case characters in the server address to lower case before retreiving the page. Thus the all lower case server address version of the same URI is shown as visited (because it has been), however the mixed or upper case server address version of the same URI is not shown as visited. This indicates that the history comparason of the server name IS case sensisitve even if the compason of the path and file name are not. So Bug 129671 says the server name is case sensitive. Conversely Bug 99091 says that the path/file is not case sensitive (with appears to be have ben changed by the 0.9.8 build). It seems the change to case sensitivity went a bit to far. Afterall, Foo.com is the same as foo.com and fOO.com . At the same time foo.com/foo is not the same as foo.com/Foo . <a href="http://fun.com/privacy.html">All lower case</a><br> <a href="http://Fun.com/privacy.html">Some upper in Server Address</a><br> <a href="http://fun.com/Privacy.html">Some upper in Path/File</a><br> <a href="http://Fun.com/Privacy.html">Some upper in both Server Address and Path/File</a><br> If you follow the second link and return, the first one will display as visited but the second one will not.
Target Milestone: mozilla1.1alpha → Future
Is this going to be fixed anytime soon?
*** Bug 131470 has been marked as a duplicate of this bug. ***
This bug does not exist in Netscape 4.8. This bug makes the search history functionality nearly worthless. For example, go to History. Find an entry with a title that has a capitalized word. Try to search for the word in all lower case letters. No search hit. Major severity. It's also a silent bug. When it hits you, you don't realize the cause. We need this for 1.4.
Is this bug specific to session history, or is it generic to all of history. For example, when you search for something in the history window, the search is case sesnsitive when it should not be.
*** Bug 206348 has been marked as a duplicate of this bug. ***
*** Bug 212107 has been marked as a duplicate of this bug. ***
*** Bug 212484 has been marked as a duplicate of this bug. ***
See also bug 85165, "Sequentially repeated URL does not register in history". If that bug were fixed (unlikely), this bug would be moot.
*** Bug 263572 has been marked as a duplicate of this bug. ***
This was submitted in 2001!? And many dupes over the years (including one by myself because I was only searching in Firefox product). Is this going to be fixed any time soon? IMO, it's detrimental to the overall usability of Mozilla/Firefox/etc. You might wan't to reassign it to someone who doesn't have the words "on family leave" in his name.
Note that the real issue is bug 127373. Once that's fixed, this will be fixed automatically.
*** Bug 265128 has been marked as a duplicate of this bug. ***
Another real world example: Go to any start page, http://en.wikipedia.org/wiki/Usenet will do. Click or got to http://en.wikipedia.org/wiki/Kibo The follow the link to http://en.wikipedia.org/wiki/KIBO The protocol and server are case insensitive, but the directories/filename are case sensitive, just as in the UNIX filesystem. This bug is also related to the unusual but useful feature of Moz that when you navigate to the same page from page x, it doesn't add page x a second time to the navigation history. This can irk me when I'm doing page load time tests, but is otherwise good.
(In reply to comment #21) > Another real world example: > Go to any start page, http://en.wikipedia.org/wiki/Usenet will do. > Click or got to http://en.wikipedia.org/wiki/Kibo > The follow the link to http://en.wikipedia.org/wiki/KIBO > > The protocol and server are case insensitive, but the directories/filename are > case sensitive, just as in the UNIX filesystem. Same problem applies even after the "?" in url parameters in Firefox 1.0: http://en.wikipedia.org/mediawiki/index.php?title=Usenet http://en.wikipedia.org/mediawiki/index.php?title=Kibo http://en.wikipedia.org/mediawwiki/index.php?title=KIBO Both Safari and IE seem to get this right (the domain name is case-insensitive, but everything after the slash is case sensitive).
*** Bug 267806 has been marked as a duplicate of this bug. ***
*** Bug 272500 has been marked as a duplicate of this bug. ***
Fixed by checkin for bug 127373
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
*** Bug 294281 has been marked as a duplicate of this bug. ***
*** Bug 295044 has been marked as a duplicate of this bug. ***
*** Bug 295768 has been marked as a duplicate of this bug. ***
Summary: Browser incorrectly assumes case doesn't matter in history → History is not case sensitive (case doesn't matter)
*** Bug 297859 has been marked as a duplicate of this bug. ***
Okay, my post of bug 297859 was marked as a duplicate of this bug, which it is. Not questioning that. What I *am* questioning is why this bug (99091) is marked as "FIXED". The problem still exists in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4.
I'm going to take a wild guess and say that because it was marked as 'fixed on trunk'; that its not going to be back ported to the Firefox 1.0 tree (aviary?). 1.1 should have it fixed, then. Wild guess, actual developer feel free to correct me...
*** Bug 301239 has been marked as a duplicate of this bug. ***
*** Bug 301511 has been marked as a duplicate of this bug. ***
*** Bug 303459 has been marked as a duplicate of this bug. ***
It gets more complex. URL encoding %2D and %2d are both valid for -, yet should not produce a second entry in history. http://www.foo.bar/file%2Dname.txt and http://www.foo.bar/file%2dname.txt
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.