The history file stores a seperate entry for all URLs that have # (ie referring to specifc name tag) in them. For example for today I have: http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02439 http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02426 http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02409 http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02408 http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02395 http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02387 http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02373 http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02367 which of course all refer to the same page This causes a few problems. A) The link color of any hypertext refering to that page with a name tag only gets changed if the URL exactly matches one with the same name tag. B) Location Bar gets very cluttered with all of the # versions which slows it down significantly and makes the automatic quicktype selection much less useful. C) It would cut down on the history.dat size, thus speeding it up also. The solution is two only store up to the # in the history file and only lookup matches to the Read (Purple) link color up to the # sign of URL referenced in the page being displayed. This is the behavior of MS Interent Explorer, FWIW.
To see an example: Go to http://gcc.gnu.org/ml/gcc-patches/2002-04/threads.html Click on an entry. Click on Thread Index (which will incorrectly be blue) Click on a different entry Click on Thread Index (which will incorrectly be blue) Click on a different entry Click on Thread Index (which will incorrectly be blue) View your History.
(A) is actually desired behavior. It makes page navigation much clearer. The IE behavior there is very confusing. The URLbar dropdown should filter these duplicates, though.
I forgot to mention the fact that since they are "different" URLs, it won't pull the (same) page from the cache, which matters over slow connections.
Sure it'll pull the same page. The #ref is ignored when generating the cache key. See http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel. cpp#919 Let's not confuse history and cache. ;)
if I understand Boris' comments, mozilla is doing what is desired here, and so this isn't a bug, and therefore should be INVALID? is that right?
To repeat, "The URLbar dropdown should filter these duplicates, though."
ah... ok. thanks. well I can't see any other bug for making the URL bar filter the duplicates, so I'll update and confirm this one for that.
and the component of the day is... ;)
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Though the URLBar issue is technically still there, the changes over the years from simply alphabetical sorted to the popularity sorted URLbar to the now much smarter places bar has made this issue completely irrelevant for me. I had forgotten about it. As the original opener, I'd advocate closing it as INVALID
agree to comment 10