Closed Bug 244763 Opened 21 years ago Closed 21 years ago

Sites not added to history sidebar if 'Today' is expanded

Categories

(Firefox :: Bookmarks & History, defect, P3)

defect

Tracking

()

RESOLVED FIXED
Firefox0.9

People

(Reporter: parish, Assigned: bugs)

References

Details

(Whiteboard: fixed-aviary1.0)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040510 Netscape/7.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040510 Netscape/7.0

If 'Today' is expanded in the History sidebar sites do not get added as they are
visited; you have to collapse and expand 'Today' to see them. This works
correctly in Mozilla.

Reproducible: Always
Steps to Reproduce:
1. Open History sidebar, sort By Date and Site
2. Expand 'Today'
3. Visit several websites (that don't already appear under 'Today')
4. Collapse and expand 'Today' and the sites appear.
Actual Results:  
The new sites don't appear in the tree as you visit them

Expected Results:  
The sites should have been added to the tree, as happens in Mozilla.

This behaviour only affects the top-level tree nodes. If you expand a site under
'Today' and browse different pages at that site the pages appear in the tree as
they are loaded.
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040524
Firefox/0.8.0+

With which Firefox version are you testing this? Your user-agent string gets me
confused.
--> NEW. Confirming on Windows/Linux.

(In reply to comment #0) the tree, as happens in Mozilla.
> 
> This behaviour only affects the top-level tree nodes. If you expand a site under
> 'Today' and browse different pages at that site the pages appear in the tree as
> they are loaded.

It seems to affect the site level nodes for me too, but also some sublevels. I
can't really put a finger when it does and doesn't. But I'd assume that the
cause is the same.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
> With which Firefox version are you testing this?
> Your user-agent string gets me confused.

I've got general.useragent.vendor and general.useragent.vendorSub set. It's a
CVS build from 2004-05-10

Attached patch patchSplinter Review
Make sure notifications are sent as pages are added to the history datasource.

This corrects two issues:
- Pages are added to the history datasource by "MarkTypedPage" first, which
wasn't sending NC_child update notifications to the front end in the flat
lists, and
- An error in NotifyFindAssertions meant that new hostnames were not being
dynamically added to each Day folder.
Assignee: firefox → bugs
Status: NEW → ASSIGNED
This also contains the fix for 234700. 
Flags: blocking0.9+
Priority: -- → P3
Target Milestone: --- → Firefox0.9
Blocks: 234700
br & trunk fixed. 
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
calling compress commit for every row deleted is really not nice - is there no
batching on a mass delete? It would be simple to at least just set a flag saying
that a compress commit is required when a row is deleted, and let the normal
commit that we do on the timer, or on shutdown, do a compress commit.
This doesn't appear to be fully fixed. If the site you visit already exists in
the History, but on a previous day, then it doesn't get added to Today. For
example, I clicked the link to this bug in the bugmail but had to collapse and
expand Today to make it show up as it existed under 3 Days Ago. I can
consistently reproduce this behaviour.
Ignore comment 8 - Mozilla behaves the same way so I guess this is the correct
behaviour (although I still think it's wrong)
Whiteboard: fixed-aviary1.0
Yeah, it's ugly, but piecemeal deletion is an uncommon task (mass clearing is
done in a batched fashion via a different API) and history does not expose any
batching API that can be used from script. I considered adding it but didn't
because shaver is busy rewriting all of this anyway and I figured making it work
efficiently was wasted effort ;-) 
I was trying to reproduce this behavior on my Windows XP. I found out that there
are some sites having this behavior and some are not.
The sites have this behavior are:
www.yahoo.com
www.google.com
The sites don't have this bug are:
www.cnn.com
www.abc.com
www.nbc.com
Component: History → Bookmarks & History
QA Contact: mozilla → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: