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

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

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.

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.

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

(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 :)

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.

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

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.

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

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?

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

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

hey, this is now fixed by async visits :)