Closed
Bug 29604
Opened 25 years ago
Closed 25 years ago
too much is ending up in the history
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: sspitzer, Assigned: travis)
Details
when I implemented nsGlobalHistory::GetLastPageVisited() I noticed that we were
calling AddPage() way too often, and with urls that didn't belong in the
history.
notably, about:blank and chrome urls.
so, to keep the history db clean of un-intended news: mailbox: imap: chrome:
about: file: urls, I added nsGlobalHistory::URLShouldBeInHistory() which makes
sure the url starts with http: or https: before entering it into the history db
and altering the last page visited.
the correct fix would be to call AddPage() only at the correct time, but that is
a tricky problem to solve.
assigning bug to mscott for now, as he mentioned this was something he was going
to clean up after beta.
when you do fix it, please remove URLShouldBeInHistory()
Reporter | ||
Comment 1•25 years ago
|
||
something to note, sidebar panels are ending up in the history.
since we my.netscape.com channels in the sidebar window, those end up in the
history db and as the last page visited.
one more item to the list of tricky cases to fix.
The new code I am waiting to land has structure that allows deciding if code
should be added into global History. nsDocShell::ShouldAddToGlobalHistory.
Before fixing this bug, I suggest waiting to see this new code in place.
Comment 3•25 years ago
|
||
Most (I hope) of the bugs on extraneous history entries:
Same page more than once in a row:
bug 28758, "duplicate entries under the Go menu"
bug 29603, "reloading by hitting enter in URL bar creates new history entry"
bug 21611, "Meta-refreshed page becomes added again to Go menu upon each refresh
Chrome: URLs:
bug 11324, "chrome URLs incorrectly added to global history"
About: URLs:
bug 23557, "about:blank is in the history because I open new windows as blank"
Mailto: URLs:
bug 26829, "mailto is stored in history"
bug 27961, "mailto: URL getting put in session history"
Non-existant pages:
bug 11325, "bad URLs added to browser history"
bug 14695, "nonexistant sites should not be added to session history"
bug 29224, "nonexistant pages added to history and displayed in URL bar"
Comment 4•25 years ago
|
||
ftp: URLs probably should not be excluded from the history. More and more
ftp sites are adding the likes of ftp://ftp.~~~~~.com/index.html
Reporter | ||
Comment 5•25 years ago
|
||
travis, didn't you offer to take this bug from mscott?
I'm going to re-assign to you.
right now, history is hacked so that only http:/ and https:/ urls will make it
in.
that fixes (albeit the wrong way) bugs:
bug 11324, "chrome URLs incorrectly added to global history"
bug 23557, "about:blank is in the history because I open new windows as blank"
bug 26829, "mailto is stored in history"
bug 27961, "mailto: URL getting put in session history"
it also excludes the ftp urls.
But since those bugs aren't fixed the right way (the way travis has in mind)
I'll leave them open.
Assignee: mscott → travis
Build 2000030809
The history list is history. (NOTHING ends up there now.)
Reporter | ||
Comment 9•25 years ago
|
||
rkka, http: and https: urls are ending up in history, right?
Comment 10•25 years ago
|
||
no he's right history is empty on Win and Linux - new bug
Comment 11•25 years ago
|
||
History no longer empty; business as usual. Currently on 2000031909.
(i was rkaa, account now dead - this is the new. Can rkaa@powertech.no be
removed from cc's?)
Comment 12•25 years ago
|
||
Is there a reason why file: URLs are excluded from the history? I'd like to be
able to browse local HTML files etc. In other words: when you fix this, make
sure file: URLs end up properly in the SH.
Comment 13•25 years ago
|
||
(For posterity's sake, if this is already known...)
The reason is that sspitzer put in a hack for the first Netscape beta to work
around the fact that any URI loaded into a content area (e.g., imap:, chrome:,
resource:, resolved resource:, ...) were all added to the global history. At
some point, travis/mscott were going to obviate the need for this hack.
Specifically, "file:" was excluded because "chrome:" and "resource:" URLs are
resolved to god-awful "file:" URLs; e.g.,
file:///C|/mozilla/chrome/browser/content/default/navigator.xul
wound up in global history every time you opened a new browser window!
Comment 14•25 years ago
|
||
tbogard@aol.net checked in a change to mozilla/docshell/base/nsDocShell.cpp at
04/16/2000 19:17 with this comment:
"If the same page is being loaded twice, don't add it twice to session history."
Seems a partial fix for this bug
Assignee | ||
Comment 15•25 years ago
|
||
Ok, I've removed this old code from the global history. Basically it is being
less strict about what is being let in. Right now it's anything that is loaded
in a content area is getting put in. Anything loaded in a chrome area is not.
The content area loads also block out "about", "news", "imap" and "mailbox"
schemes.
This doesn't solve spitzer's desire for sidebar panels not to be in the global
history. I'm not sure I agree with that though. If they don't end up in there
then links aren't properly going to be colored there. In terms of history, you
have been to those pages and would like them to indicate so.
Anyway, the code for deciding to add something or not is found in
nsDocShell::ShouldAddToGlobalHistory. Another thing to point out to those who
have commented on this bug, session history and global history are two
different things and have different rules for when they should be added. I'm
marking this bug fixed now. New ones should be opened for individual protocols
or schemes that are getting added that people feel shouldn't be.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 16•25 years ago
|
||
and markng VERIFIED. New(specific) Session history bugs to radha@netscape.com and new global history bugs to --
(travis?,waterson?)
Status: RESOLVED → VERIFIED
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.
Description
•