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)

x86
All
defect

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()
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.
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"
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
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
bug 29224 nonexistant pages are added to session history
bug 30833 - downloaded files are added to session history
Build 2000030809 The history list is history. (NOTHING ends up there now.)
rkka, http: and https: urls are ending up in history, right?
no he's right history is empty on Win and Linux - new bug
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?)
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.
(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!
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
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
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.