Open Bug 774168 Opened 12 years ago Updated 7 years ago

History's group by day show some entries in wrong groups.

Categories

(SeaMonkey :: Bookmarks & History, defect)

SeaMonkey 2.0 Branch
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: ant, Unassigned)

References

Details

(Whiteboard: [2012 Fall Equinox] DUPEME)

Attachments

(4 files)

Attached image HistoryGroupByDays.gif
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1
Build ID: 20120615050225

Steps to reproduce:

Surf the day before and the next day. Check its history, sorted by days.


Actual results:

Yesterday's and today's entries seem to be sorted into the wrong places. See attached screen shot as an example. This was a new SeaMonkey v2.10.1 installation with a new profile from yesterday. I also reproduced it easily in Linux/Debian.


Expected results:

Yesterday's and today's entries should be sorted in the right places.
Bug 765689 might be related. Let's see if the fix there also fixes this.
Ant, do you still see this after Bug 765689 fixed? If yes, can you also check on latest nightly build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/seamonkey-2.15a1.en-US.win32.zip? Backup your profile folder before checking just in case
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 WFM]
Phoenix: It doesn't look like it. See https://bug774168.bugzilla.mozilla.org/attachment.cgi?id=663846 screen shot/capture file. :( 

I installed a new SM v2.15a1 into a clean, updated Windows XP Pro. SP3 VM and copied over my places.sqlite to avoid my production machine being tampered. I hope that's OK.
(In reply to Ant from comment #4)
> I installed a new SM v2.15a1 into a clean, updated Windows XP Pro. SP3 VM
> and copied over my places.sqlite to avoid my production machine being
> tampered. I hope that's OK.
Yes, that's ok, you copy only places.sqlite in completely clean profile, right? Did you change any other settings?
I can't reproduce this problem on my PC...
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 WFM] → [2012 Fall Equinox]
Version: SeaMonkey 2.10 Branch → Trunk
Phoenix: Yep. I copied it over after launching and exiting SM. Changing any other settings. Just viewing the history's sorting.
ISTR that I've seen another bug about the same problem (history sorted alphabetically on the datetime string) and even that it has been fixed in recent builds (on trunk at least, SeaMonkey 2.16a1, Toolkit 19.0a1) but I've been unable to find it back.

This sounds like a backend (Toolkit::Places) problem, but I'll let the Places developers judge that.
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [2012 Fall Equinox] → [2012 Fall Equinox] DUPEME
Today (2015-07-20) I see with DE SeaMonkey 2.35(γ)  (Windows NT 6.1; WOW64; rv:38.0 nightly by Adrian Kalla)  Gecko/20100101 Build 20150616034436 (Classic Theme) on German WIN7 64bit in History side bar, sorting descending by "last visited:

Today:     06:56   ... 06:03 100 entries or so
Yesterday  06:50   ... 06:04  10 entries, randomly picked from "today" list
           Yesterday's visited web pages

a) All "today" hits in "Yesterday" list also shown in "Today" list
b) If I delete all "Today" entries in 'Go -> History' list also entries 
   duplicated in "Yesterday" disappear
   I worked a little and no new entries appeared under "yesterday"
c) My suspect: are those duplicated entries the TABs I had open when I
   closed SM yesterday?
d) currently I can't see a 100% relation between Ant' observations and my ones.

@Ant:
Do you still observe that problem?
Do you remember whether that also appeared before SM 2.10?
e) After deletion of history for (b) I did no longer see any today's visit under
   "Yesterday"
f) after having closed / reopened SM I find 3 "today" entries 07:17 in Group
   "Yesterday", but none of them is listed under "Today"
   So my observation (a) might have been coincidence. 
g) After having changed to ungrouped view and switched back to grouped view, 
   the three entries "07:17" form (f) still are in "Yesterday", but now with
   timestamp 07:32. And now I see the duplicates of these 3 with same time 
   under "Today".

I will need some time to think about my observations.
Attached image v2.33.1 screen shots
A screen shot from my SeaMonkey v2.33.1.
RB: I still have this problem with v2.33.1. I attached my screen shots above.
what you read under last visited is "last visited", not "last visited in the given group", that means you won't read the last visited time from yesterday, but the globally last visited time.
In Firefox we renamed that column as "Most recent visit"
(In reply to Marco Bonardo [::mak] from comment #12)
I do not understand! Do you want to tell that in attachment "2015-07-20 07:47 CEST, Ant" shown first entry under "Yesterday" (and folowing ones) aare listed under "Yesterday" for good reasons?

h) I did not find obvious DUPs in shared query DUPs774168 <https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=DUPs774168&sharer_id=41036&list_id=12405312>
i) I also see similar effects with SM 2.0.5: Lots of "latest viseted in July"
   entries were listed under "April". so I modify VERSION (for details see
   dev-apps-seamonkey@lists.mozilla.org)
h) I also saw a similar effect with FF Nightly 42.0a1 (2015-07-18):
   A Page I visited today was listed under "April" with today's time. 
   So this one might be a Core or FF issue, but I think a developer should decide
i) Vague suspect: may be an entry what _also_has been visited a former day
   keeps the group where it has been listed before last visit, but gets
   time of today's visit? I will try to check that, but unfortunately
   it's rather unpredictable what of today's visits will appear in 
   older group

@antoine.mechelynck@gmail.com:
With what other OS did you observe the problem?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(antoine.mechelynck)
Summary: History's group by day show some entries in the wrong places. → History's group by day show some entries in wrong groups.
Version: Trunk → SeaMonkey 2.0 Branch
(In reply to Rainer Bielefeld from comment #13)
> (In reply to Marco Bonardo [::mak] from comment #12)
> I do not understand! Do you want to tell that in attachment "2015-07-20
> 07:47 CEST, Ant" shown first entry under "Yesterday" (and folowing ones)
> aare listed under "Yesterday" for good reasons?

pages can be shown in multiple containers, for example if that page has been visited both yesterday and today, it will appear in both yesterday and today, but the last visited time will be the same cause it's the most recent visit.
(In reply to Marco Bonardo [::mak] from comment #15)
> pages can be shown in multiple containers, for example if that page has been
> visited both yesterday and today, it will appear in both yesterday and

Plausible argument, but to me that seems useful for nothing - I will have to think about that and relation to other observations (currently your argument matches with my observations in FF, but not with (f). 
And also that does not match with "Bug 749908 - Existing history entries replaced when revisit web page" - why becomes old entry deleted"
(In reply to Rainer Bielefeld from comment #16)
> And also that does not match with "Bug 749908 - Existing history entries
> replaced when revisit web page" - why becomes old entry deleted"

some views admit dupes, others don't, when a view doesn't admit dupes, the old entry is replaced by a new one.
Yes, the situation is not the clearest, but we also have very limited (to none) resources to work on these edge cases.
(In reply to Rainer Bielefeld from comment #13)
[...]
> @antoine.mechelynck@gmail.com:
> With what other OS did you observe the problem?

Linux64

Sorry for the delay, I've been without Internet for months now; it's only yesterday that I found out how to configure the NetworkManager correctly on this new system (my former box had a disk crash so no way to recover the config, I had to reinstall the whole OS from scratch).
Flags: needinfo?(antoine.mechelynck)
See Also: → 1347652
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: