390505 - [meta] Livemarks on the bookmarks toolbar fail to refresh

Status: VERIFIED FIXED

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

Description

[Joey Bowles]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007073105 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007073105 Minefield/3.0a7pre

The RSS feeds in my Bookmark Toolbar Folder do not refresh. They don't refresh when Mozilla is restarted, nor do they periodically refresh/reload during normal operations. To refresh, I must do it manually by clicking on a menu item and selecting reload.

Reproducible: Always

Steps to Reproduce:
n/a
Actual Results:  
RSS feeds are old. They are as old as last time I manually refreshed. This could be days.

Expected Results:  
RSS feeds should be current.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Please try resetting the pref browser.bookmarks.livemark_refresh_seconds in about:config: http://kb.mozillazine.org/About:config

Comment 2

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091502 Minefield/3.0a8pre ID:2007091502

I'm seeing the same, for me it happens after hibernation.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Blocking for investigation ...

Comment 4

[Frédéric Buclin]

Looks like Fx3b2pre doesn't refresh feeds on startup, but it *seems* to refresh them correctly after an initial manual refresh.

Comment 6

[Ria Klaassen (not reading all bugmail)]

I examined this behaviour for some hours, tried to reproduce and to find out when this regressed, but it was a waste of time :) for the simple conclusion was that since the landing of places Firefox always fails to update the feed and that it only starts to take action in two cases:

- after opening the feed
- after opening the organizer

Comment 7

[Ria Klaassen (not reading all bugmail)]

And before the landing of Bug 387746 there was a third case: after clicking on Bookmarks menu -> Bookmarks Toolbar Folder.

Comment 9

[Marco Bonardo [:mak]]

i think that the update starts at the first livemarks service creation, it fires every 60 seconds (if the pref is not set at a time higher) and expire items only if annotation is expired (about 60 minutes later).

so when you open the feed / open the organizer for the first time, the livemark service gets initialized and the timer starts.

why it does not start when you start the browser, if you have feeds on the bookmarks toolbar? i think that the answer is Bug 398300, that does not initialize the livemark service on startup, so it is initialized on first use (that is when you open a livemark or a dialog that uses the service)... then it should be alive and update feeds regularly every 60 minutes...

Comment 10

[Tracy Walker [:tracy]]

we need to add a "verify automatic refresh" test case to litmus

Comment 12

[rs127]

My bug was marked as a duplicate, but here's what occurred: I launched Firefox 3 Beta 2, and went to the bookmarks menu to view my live bookmarks, which still contained the old headlines.  After 21 seconds (I had a stopwatch) the feeds reloaded.  This is unlike Firefox 2 behavior where the feeds reload immediately when the browser starts.

Comment 13

[Ria Klaassen (not reading all bugmail)]

This bug is still happening; two minutes after starting the browser the Latest Headlines livemark folder still contains the same set.

Comment 14

[Frédéric Buclin]

Probably a separate bug, but when Firefox finally decides to refresh the feeds, it freezes for ~10 seconds till all feeds are updated. I currently have 13 feeds, among which one from distrowatch.com and half of them are buglists on b.m.o. Am I the only one to see this issue (the same patch may eventually fix this issue as well, which is why I comment here)?

Comment 15

[Dietrich Ayala (:dietrich)]

[10:23am] sayrer: problem is that livemark code throwing an exception was moved into RunInBatchMode
[10:23am] sayrer: exception breaks the batch
[10:23am] sayrer: iirc

Comment 16

[Marco Bonardo [:mak]]

Can someone put valid STR or feed links to reproduce this with current nightly? i'm trying to reproduce a situation in which a valid livemark is not still updated after 2 minutes from the browser startup.

Comment 17

[Marco Bonardo [:mak]]

(In reply to comment #14)
> Probably a separate bug, but when Firefox finally decides to refresh the feeds,
> it freezes for ~10 seconds till all feeds are updated. I currently have 13

this is most probably Bug 329534

Comment 18

[Marco Bonardo [:mak]]

(In reply to comment #12)
> After 21 seconds (I had a stopwatch) the feeds reloaded.

this should be the actual expected behaviour, feed refresh set a timer of 15s after an initial delete if 5s, so it should start updating after about 20 s.

Comment 19

[Marco Bonardo [:mak]]

for reference about comment #18: Bug 382711 added a timer in delayed startup on 17/01/2008, that changed the behaviour of the refresh:
- 5s delay to wait for the UI to be setup
- set a repeat timer
- first update after 15s, and so on (every 15s)

Comment 20

[Marco Bonardo [:mak]]

i'm trying to fix bugs that could pollute testing of this problem (because they are somehow related to feed reload), to help finding the actual problem: Bug 341035 & Bug 388716. notice however that, as by now, i've not been able to reproduce the problem with a build after the check-in of Bug 382711, nor i have valid STR for this. But keep trying.

Comment 21

[rs127]

(In reply to comment #19)
> for reference about comment #18: Bug 382711 added a timer in delayed startup on
> 17/01/2008, that changed the behaviour of the refresh:
> - 5s delay to wait for the UI to be setup
> - set a repeat timer
> - first update after 15s, and so on (every 15s)

Is there any way to change this behavior so that the livemarks load immediately upon startup?

Comment 22

[Marco Bonardo [:mak]]

(In reply to comment #21)
> Is there any way to change this behavior so that the livemarks load immediately
> upon startup?
> 

imho we should force a first refresh 5s/10s after the browser startup and then set the refresh time at an higher value (i don't get why we should check for update every 15s, it sounds a too short time). Will talk with dietrich about this.

Comment 23

[Marco Bonardo [:mak]]

filled Bug 419832 on livemark update timings

Comment 24

[Marco Bonardo [:mak]]

Attachment: patch

apart the followup bugs i've filled, that should still be fixed, in _fireTimer (the actual function that we fire every 15s to update) we have

    for (var i=0; i < this._livemarks.length; ++i) {
      this._updateLivemarkChildren(i, false);
    }

_updateLivemarkChildren, if the livemark fails to load or the listener throws, do

    catch (ex) {
      [omissis...]
      LOG("exception: " + ex);
      throw ex;
     }

the exception go out and break the for cycle so subsequent feeds are not updated, this is particularly bad if the failing livemark is the first in the array.

Probably we don't need to pass out that exception, should be useful more for debug purposes, so i'd simply change the return value to a bool, in case some other code nees to see if the livemark has been updated.

Comment 25

[Dietrich Ayala (:dietrich)]

Comment on attachment 306010 [details] [diff] [review]
patch

sounds good, r=me

Comment 26

[Marco Bonardo [:mak]]

please don't close this report after the check-in since it could still be valid until we fix all dependancies (or someone finds an actual STR to reproduce after this fix)

Comment 27

[Brendan Eich [:brendan]]

I'm first among sinners, so don't take offense: bugs should be wholly meta-, or not. So if this bug is patched, file a new bug blocked by this and any followups to be the meta-bug.

/be

Comment 28

[Marco Bonardo [:mak]]

brendan, you're right, i'm moving out the patch to a new bug and use this as meta.

Comment 29

[Marco Bonardo [:mak]]

filled Bug 419885

Comment 30

[Tracy Walker [:tracy]]

Verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008050704 Minefield/3.0pre and the windows equivalent nightly build.

Comment 31

[Tracy Walker [:tracy]]

at 60 minutes this is a good test cases for litmus. And we're not liking test cases that require Litmus users to change about:config settings.

Comment 32

[Tracy Walker [:tracy]]

s/is/isn't/

Comment 33

[Gervase Markham [:gerv]]

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