44282 - bookmark scheduled update fails to trigger

Status: RESOLVED DUPLICATE of bug 107268

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

Description

[Dan M]

- Bookmark some page that's served up by HTTP
- Edit the bookmark's properties to check for changes. Tell it to open
  the URL in a new window when a change is noticed.
- Edit the HTTP page
- Wait for Mozilla to notice. Keep waiting.

  I'm not quite sure what the pattern is. Multiple edits on the source don't seem 
to help. I believe Mozilla begins to notice only after editing the bookmark's 
schedule property a second time, turning on all the notification methods. (Also, 
quitting and relaunching seems to make it not notice that the page has been 
changed since last it checked while running.)

- Repeat with a different page. (set up two bookmarked pages to simultaneously
  check for changes.)

  Generally it seems only the new page is checked. Sometimes the first page is 
also checked for a while. It's hard to be certain, because the act of making the 
new bookmark to check seems to turn off all checking until the bug mentioned 
above has been somehow circumvented.

Comment 1

[Robert John Churchill]

Here's a description of what's going on.  To tell whether a remote HTTP URL has 
changed or not, we track what the remote server indicates as the "Last-Modified" 
value.  When you first mark a bookmark with a schedule, we have no idea what the 
"Last-Modified" value is at that point, so the URL starts out marked in an 
"unknown" state. When the schedule fires for the first time after that, we get 
the "Last-Modified" value from the server and merely remember it, changing the 
URL to a "current" state. From that point on, whenever the schedule fires, we 
continue getting the "Last-Modified" value from the server and comparing it to 
the last well-known value we have.

Comment 2

[Dan M]

  OK, that makes sense. But it doesn't quite cover all my worries. I didn't 
explain this well, but part of my testing above was setting the update period to 
one minute and then changing the source HTML file once every minute or so for 
several minutes. This wasn't guaranteed to make the file reload.

Comment 3

[Robert John Churchill]

Yeah, that's what I usually do... set the duration to 1 minute... makes for 
quick/easy testing.

If you want to test it some more, I'll stop by and show you how to turn on some 
stronger logging, and we can try and get a feel for what's happening with it.

Comment 4

[Robert John Churchill]

Marking this REMIND to see if we can come up with a faster resolution of 
detecting changes of remote URLs.  (I have some ideas.)

Comment 5

[Christopher Hoess (gone)]

REMIND is deprecated.

Comment 6

[Christopher Hoess (gone)]

->default

Comment 7

[Chris Lyon]

This is the same issue as bug 107268, but that bug is ASSIGNED and has been
getting more attention than this one.

*** This bug has been marked as a duplicate of 107268 ***

Comment 8

[Henning Schnoor]

An update: This is still an issue. A new bug has been openen, bug 207814, to
track these problems. Nobody seems to work on bug 107268 anymore, the owner
wasn't even able to update the status fields. So, if anyone knows anything about
the bookmark schedule system, please take a look at that one.