Closed Bug 99091 Opened 23 years ago Closed 20 years ago

History is not case sensitive (case doesn't matter)

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: tdowling, Assigned: bugs)

References

(
URL
)

Details

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
OS: Windows 2000 → All
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.
Severity: normal → major
Flags: blocking1.4a?
Keywords: 4xp, relnote
Flags: blocking1.4a? → blocking1.4a-
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.
Flags: blocking1.4b?
Flags: blocking1.4?
Keywords: nsbeta1
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Flags: blocking1.4b?
Flags: blocking1.4b-
Flags: blocking1.4?
Flags: blocking1.4-
*** 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. ***
Depends on: 95705
See also bug 85165, "Sequentially repeated URL does not register in history". 
If that bug were fixed (unlikely), this bug would be moot.
Keywords: relnote
*** 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.
Assignee: radha → agwadude
Status: ASSIGNED → NEW
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: 20 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.