Patrick Dubroy Reporter
	Description • 16 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

I visit several pages in a row, say A -> B -> C -> D. While viewing D, I use the History menu to return to B. After B loads, I realize it's not the page I wanted, so I immediately pull down the History menu again. It has not yet been updated (D is still at the top of the list). If I want for a second, the menu updates (the list of pages is re-ordered properly).

It seems to take about several seconds for the menu to update properly, whether I open up the menu immediately, or just that amount of time to open up the menu. The time between loading page B and the menu finally updating is ~3 seconds on a dual-core Xeon 3.4GHz.

This is obviously not that common of a use case, but the behaviour seems pretty weird when you do encounter it. For me, it had the effect of changing underneath my mouse, which is pretty disconcerting. It took me a few minutes to realize that it seems to just take some time to update, whether you bring up the menu or not.

I guess this is probably related to bug 385397, but not sure if it's the same problem or not, as that bug was apparently fixed.

Reproducible: Always

	Patrick Dubroy Reporter
	Comment 1 • 16 years ago

I've verified that the problem still exists in the latest Minefield:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080812020515 Minefield/3.1a2pre

	Marco Bonardo [:mak]
	Comment 2 • 16 years ago

visits are lazy added on a 3s timer... so for now this is by design, could change if we drop lazy messages to use the new background thread.

	Dietrich Ayala (:dietrich)
	Comment 3 • 16 years ago

Yes, the new table partitioning approach will remove the lazy timer, so the menu should be up to date immediately, so marking the dependency on bug 442967.

Also, the "changing underneath the mouse" is a feature, albeit confusing in this case because of the lazy timer. If you have any menu/toolbar/tree open, it will update dynamically if new information is available. I'm removing that part from the bug summary, to focus on the "slow to update" part. If you feel that these views should *not* live-update, then please file a separate bug.

	Shawn Wilsher :sdwilsh
	Comment 4 • 16 years ago

(In reply to comment #3)
> Yes, the new table partitioning approach will remove the lazy timer, so the
> menu should be up to date immediately, so marking the dependency on bug 442967.
It won't just happen - we'd have to have code to remove the lazy timer still.

	Dietrich Ayala (:dietrich)
	Comment 5 • 16 years ago

(In reply to comment #4)
> (In reply to comment #3)
> > Yes, the new table partitioning approach will remove the lazy timer, so the
> > menu should be up to date immediately, so marking the dependency on bug 442967.
> It won't just happen - we'd have to have code to remove the lazy timer still.

ok, this is the bug for it then :)

	Dietrich Ayala (:dietrich)
	Comment 6 • 16 years ago

per sdwilsh: in order to remove the lazy timer altogether, would need to move the work done on lazy timer execution onto a background thread, so it's not blocking page load.

	Marco Bonardo [:mak]
	Comment 7 • 16 years ago

not going to make 3.1, removing the lazy timer requires changes quite big at this stage

	Black_Ps`
	Comment 10 • 15 years ago

I have the same problem with updating history in 3.0.0.10 but it will take more then 3 seconds to update,like 10-15 at last. Will this problem be fixed ?


Thanks and sorry for asking ...but it's very flustering
A++ and keep up the good work.

	Ria Klaassen (not reading all bugmail)
	Comment 11 • 15 years ago

It happens also often with these STR:

- open Firefox with new profile
- visit a few new sites
- close Firefox
- open Firefox
- open History menu
- click on one of the new entries

And the result can be very often, that while your clicking on a new entry, the last site is added on top, the targeted site is moving down and you're going to the wrong site

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 12 • 15 years ago

Marco/Dietrich: is this something that's doable for Firefox 3.6? Sounds like you had a plan which has now gone stale. Don't think this blocks, but is wanted, yes?

	Marco Bonardo [:mak]
	Comment 13 • 15 years ago

3.7, most likely. this requires rewriting part of history to be async.

	Gervase Markham [:gerv]
	Comment 14 • 15 years ago

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

	Marco Bonardo [:mak]
	Comment 15 • 14 years ago

hey, this is now fixed by async visits :)