162600 - Checking for bookmark updates raises false alarms

Status: RESOLVED INVALID

(SeaMonkey :: Bookmarks & History, defect)

Description

[William Cloherty]

Several entries in my bookmark file routinely give a false page updated flag. 

This behavior is more common in sub-nested folders than higher level folders.

Will attach a file with several instants of a few affected bookmark entries.

This is on build 2002080404 (1.1b).

Comment 1

[William Cloherty]

Attachment: Bookmark Entries that demonstrate the bug

The attachment contains a few sequencal entries of a few bookmarks that gives
false		indications of an updated page. In a few cases the
"PING_LAST_MODIFIED" date is not  in a more recent date than the prior entry.  
 

The entries are cut and pasted from the bookmark file while Mozzilla is
shutdown.

Comment 2

[Chris Lyon]

William, can you reproduce this on the most recent build?

Comment 3

[William Cloherty]

Attachment: 10-05-02 Bookmark file with entries that demonstrate the bug.

This is a trimmed file with only the sites that have shown this bug on the
following build.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021027

I have removed the above build and installed the following latest build.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021105

The following bookmarks have already shown this bug on the latest build:
   Fan Sites/FanFiction/Queen
   Fan Sites/FanFiction/Quicksilver
   Fan Sites/FanFiction/Sunhawk
   Fan Sites/FanFiction/Thrythlind

Comment 4

[Chris Lyon]

Tweaking summary to make this bug easier to find.

William, are you creating a new profile when you install the new build?  If not,
please do so and see if you can reproduce this bug.

Comment 5

[William Cloherty]

Chris, I was not creating a new profile. The number of false updates has tapered
off with the newer build though.  I will install a newer build and profile
tonight and keep an eye out for more false updates.

Comment 6

[Chris Lyon]

*** Bug 179478 has been marked as a duplicate of this bug. ***

Comment 7

[William Cloherty]

Attachment: A bookmark file prior to a false update.

Comment 8

[William Cloherty]

Attachment: A bookmark file during a false update.

Comment 9

[William Cloherty]

Attachment: A bookmark file after checking a false update.

Comment 10

[William Cloherty]

Chris, after installing a new nightly build with a new profile I am still
getting a few updates.

I just attached three boobmark files of one website that routinely generates a
false update.  The priorbookmark file is from prior to getting a false update,
duringbookmark is from when the bookmark was indicating an update had occured,
and   afterbookmark is from after I checked the site. I copied these files with
Mozilla shutdown. I am currently using Mozilla/5.0 (Windows; U; Win98; en-US;
rv:1.3a) Gecko/20021111.

The fequency of the false updates has dropped from the 10-05-02 entry.

Comment 11

[William Cloherty]

Chris, I changed the update frequency back to every 20 minutes from 5 minutes
after yesterday's comment and the number of false updates returned to the rate
prior of 10-05-02.

Comment 12

[Max Alekseyev]

I often see false bookmark updated alerts on Linux 1.6a build. In particular,
I've schedulled a daily check for updates of
http://www7.software.ibm.com/2bcprod.nsf/ddpakbydate?OpenView
and it rises an alert on every checking even when the page is still the same.

Confirming...
Hardware/OS -> All/All
Severity -> major
Clarifying summary

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Mass reassign of my non-Firefox bugs to [e-mail]

Comment 14

[john jack]

Attachment: a very simple page I set up entitled this_page_will_never_change.html

I had the same problem on various blog sites, but couldn't be sure that there
weren't changes going on behind the scenes, so I set up the following page. 
You can 'watch' http://plaza.ufl.edu/johnjack/this_page_will_never_change.html
to verify.

Comment 15

[Stewart Gordon]

In my experience, false alarms (or what appear to be) are often due to one of two things:
(a) the site has gone down, or is back up again after being down
(b) the exact page hasn't changed, but some page within the same website has

For (a), it should be simple to fix the update checking mechanism so that nothing happens if the server returns an error code.  The bookmark's last modified time will remain what it was before the outage, so that when the site comes back online, SeaMonkey won't think the page has changed.

But (b) would be a useful feature if only it had the decency to tell us _which_ page within the site has been updated, rather than just opening up the exact page that was bookmarked regardless.

Even so, there are situations in which the last modified time may have changed even though the content hasn't:
(c) the page is dynamically generated - often such pages report the current time as the last modified time
(d) the site has moved to a new server, and the timestamps changed when the files were transferred to it
(e) some people, when updating a site, would just reupload all the files whether they've changed or not, or otherwise reupload a handful of files they don't need to (this would tend to trigger (b) anyway, but could cause confusion as it tries to work out which files have been updated)

Do the cases people are reporting fall under any of these?  Or is there another cause?

Comment 16

[Phoenix]

Ability to check bookmarks updates was lost when moving to Places, so this bug became obsolete, closing