65862 - [RFE] Sort history by 'Day -> Site -> Page' using an expanding list ala IE

Status: VERIFIED FIXED

(Core Graveyard :: History: Global, enhancement, P2)

Description

[Ian Tommins ('thelem')]

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.

Comment 1

[Fabian Guisset]

Let's see what alecf thinks of this. Would this replace the current history or
would it be on top of it?

Comment 2

[Alec Flett]

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.

Comment 3

[Alec Flett]

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.

Comment 4

[Robert Pollak]

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?

Comment 5

[timeless]

i like that idea.

Comment 6

[Alec Flett]

Attachment: screenshot of what I've been working on

Comment 7

[Ian Tommins ('thelem')]

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?)

Comment 8

[Alec Flett]

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.

Comment 9

[Alec Flett]

Attachment: giant history patch

Comment 10

[Alec Flett]

Attachment: argh, include all files this time

Comment 11

[Alec Flett]

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.

Comment 12

[Alec Flett]

moving this to moz 0.8.1 cuz I have a patch

Comment 13

[Alec Flett]

fix in hand.
Anyone have any questions/comments thus far?

Comment 14

[Chris Waterson]

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).

Comment 15

[timeless]

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.

Comment 16

[Adam D. Moss]

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?

Comment 17

[Alec Flett]

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.

Comment 18

[ajbu]

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.

Comment 19

[Alec Flett]

ack! I had only done an optimized build, thanks!

Comment 20

[Alec Flett]

ok, after a bit of wrestling with the mac and PRInt64, I've checked this in!

Comment 21

[Ben Ruppel]

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.

Comment 22

[Scott Tran (Wildcard)]

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.

Comment 23

[Ben Ruppel]

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.

Comment 24

[Håkan Waara]

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.

Comment 25

[Alec Flett]

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.

Comment 26

[sairuh (rarely reading bugmail)]

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.]