The history window in Mozilla mimics that of Netscape 4. I think the history window of IE is much easier to navigate (see http://www.lemnet.com/ie-history.gif ). When you open the history sidebar in IE, you are presented with a list of days, clicking on one of the days will expand it. Underneath is a list of sites (listed by domain, so www.yahoo.com and my.yahoo.com are seperate) that have been visited on that day, and you can click on one to expand it. Underneath that is a list of pages on that domain that have been visited on that day. I think the mozilla history would be much easier to use if it was in this format.
Let's see what alecf thinks of this. Would this replace the current history or would it be on top of it?
this should be assigned to me, not radha I'm working on this now. it should essentially replace the current history because the current history sort/display is arcane and difficult to use.
On second thought, I'm going to file a seperate bug (walk, run, crawl..) to sort things as 'Day -> Page' and fix up some dependancies. I think that I won't get to this in mozilla 1.0, but I will get to Day -> Page soon.
Maybe 'grouping by site' could have the gui analogous to the 'threaded' news viewing option - a button left to the header of the 'URL' column?
i like that idea.
That looks great alex, just what I was asking for. Does this mean bug 65875 should be marked wontfix or something - since you are skipping that step? Oh, and is there any way I could see this in action? (Or will it be in the builds soon?)
no, this fix will fix both this and the other one.. it will be a couple days before I can clean up my code, and get some reviewers... I'll attach a patch soon.
ok, there you go! that patch does it. Here's what's going on, follow along with the patch - new RDF resources to add #Hostname and #AgeInDays, and a behind-the-scenes sort by name resource for the history sidebar. "Hostname" exists in the database, but AgeInDays does not (because it's dependant on the current time) - thanks to morks use of atomized yarns, even if you have 100 sites on www.foo.com, the string "www.foo.com" only appears once in the db. - defining of structures, etc.. you'll see these used below - updating PRInt64toChars to use nsAWritableString - it just made life easier, you'll see updates to the consumers in the file - matchAgeInDaysCallback is a special callback for matching since AgeInDays doesn't actually exist in the db. I do some little closure tricks to cache the value of PR_Now() to avoid a flood of system calls. - two new timers are defined: - one to sync the database whenever it's been changed, but only after it's 'idle' for a certain period of time - not relevant to this bug, but useful nonetheless. - one to cache the value of "Now" so that we're not constantly calling PR_Now () if we're displaying the value of AgeInDays in a ui (for similar reasons that it's cached in the callback closure above) - Changed FindUrl to FindRow, so that we could do indexing on other columns other than the URL column - not used yet, but probably will be at some point later in time. - more switching from AliasCellRow to GetRowValue - filled in some missing datatypes, cleans up the code pretty signifigantly - whenever a NEW page is added to the database, store the hostname for quick access later (and future indexing possibilities) - implementation of some of the necessary GetRowValue functions - nsPromiseFlatCString does not null-terminate strings (not what it was designed for), so in the off chance that we hand it a string from the db, we need to make an nsCAutoString copy, so that we get the null termination (this is updated in a few locations) - update GetTarget/GetTargets/GetSources/etc to recognize the #Hostname arc - update GetTarget() to use the same trick for NC:HistoryByDate as for NC:HistoryRoot - for find URIs, we need to special-case the "#Name" arc - for the displayable version, we try to guess at it, and for the sorting version, we need to sort by URI (the only logical sort I could come up with for now) - for the #AgeInDays arc, we need to do a runtime calculation of the age in days of the current url.. - when we're asked for the #Name of a page and there isnt' one stored in the db, we try to guess at one, based on the uri - this make history a whole lot more usable when the URL column isn't visible (like in the history sidebar) - the sync timer is pretty straight forward - just force a flush - but when the user changes the db in SetDirty, we make sure that we don't constantly set this timer, so we cancel and restart it.. at some point the user will stop surfing, and the timer will actually fire. - the now timer basically invalidates the "mLastNow" variable - GetNow() will always be smart and call PR_Now() if mLastNow is invalid. - GetRootDayQueries generates the initial list of queries for the top level history - we can change this easily in the future - for now it's very simple - CreateFindEnumerator will actually generate an enumerator which searches the db for the results that were asked for. - clean up some of the aTruthValue code so we're not indenting so damn much - random rdf stuff to support all these arcs - cache the bundle - we need it all over the place to generate the find url strings - CheckHostnameEntries will go through the database at startup, and fill in the "Hostname" column for everyone - but it's smart and will bail if it finds a row that has a hostname, so that we don't hurt startup performance I gotta run, but I'll complete the description of this patch soon.
moving this to moz 0.8.1 cuz I have a patch
fix in hand. Anyone have any questions/comments thus far?
Does history.xul really need to include DumpDOM.js? (I was actually going to bug you about removing from the build now that we have the ``Inpspector''.) Also, why is history including the bookmarks stylesheet? Everything else looks fine. Answer/fix the above questions and r=waterson (or sr=, if you need that).
DumpDOM.js [or the versions i've modified] is a useful debugging tool, but real chrome should never depend on it since we don't distribute it. please don't cvs remove the file.
I haven't had a chance to try this yet, but it *looks* great. Could 'today' be opened by default, since that's probably the common usage case?
oops! I didn't mean to include DumpDOM.js - it's not even exported normally! yanked. I included bookmarks.css so that we would get folder/bookmark icons like we have in the history window (history.xul already includes it) Now I just need an r=.. hunting one down now.
Trying a debug build with this patch I got a compiler error on nsGlobalHistory.cpp, line 3018 The assertion: NS_ASSERTION(mQuery->groupby != 0, "Can't generate find uri prefix without a groupby!"); asserts on 'groupby', this is defined in searchQuery with an uppercase B, groupBy.
ack! I had only done an optimized build, thanks!
ok, after a bit of wrestling with the mac and PRInt64, I've checked this in!
Hi, while I congratulate Alec Flett on his accomplishment, this enhancement destroys previous functionality and the column header doesn't make sense. Right now, in my win32 build, the days (Today, Yesterday, etc..) are listed under the "Title" header. The other headers (first visited, last visited, hostname) no longer work. The use of first and last visited may be debatable, but sorting all links by hostname, for instance, is no longer possible. I think it would make more sense if the days had a "Day" Header, and that this new format for sorting with trees was on only when someone has clicked on the "Day" header to sort links by day. When one has clicked on "First Visited" to sort by that value, the days would still show up under the day header, but the tree structure would no longer be present.
This might be just me, but I miss the old way of displaying the history. While I congradulate Alec on this checkin, I think there should be an option to enable or disable this feature.
Indeed, even since just earlier today I have missed the old history on several occasions. If I start researching a new topic, open a bunch of windows and follow some leads, then mozilla crashes (imagine that!), history sorted by date and domain is utterly useless. I still need "First Visited" to retrace my steps.
I absolutely don't agree that it's useless. But what we need is some sort of unthreaded mode, so you can switch back to the old behaviour (last visited first). FYI, I use the domain sorting all the time.
Yes, I am working on a fix to enabled a "Group By" menu that has options like: - Day (which is what I just checked in) - Site (i.e. toplevel is just by site) - None (old-school history) etc Anyhow, we may do other things with this too, but more people were looking for the current behavior over the old behavior because the old behavior was very slow, and most people found it hard to find things (i.e. more people ask themselves "where was the site I looked at yesterday" than "where was that site that I first visited the day before yesterday") Let's not debate the validity of this fix here, let me add the menu to switch the views.
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]