Closed Bug 357237 Opened 18 years ago Closed 18 years ago

nsLivemarkService.js shouldn't use just one ERROR_EXPIRATION time

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
trivial

Tracking

()

RESOLVED FIXED

People

(Reporter: philor, Assigned: sayrer)

References

Details

(Keywords: regression)

Attachments

(1 file)

The C++ LivemarkService implementations both had two different expiration times for errors: a 5 minute retry for failure to fetch the feed (which is more likely to be the result of transient connection troubles, and to be cheap to retry), and a 60 minute retry for failure to parse (since, sadly, making a feed not well-formed isn't something that sets off most people's pagers and starts an instant firedrill, yet).

The new JS service uses a 10 minute retry for either sort of failure, which not only adds injury to the embarrassment of breaking your feed, as all your Firefox subscribers start pounding away at it, it also puts us squarely in the sights of Slashdot's "fetch more than once every 30 minutes, and we'll ban you" rule: if they become unparseable, as they certainly have in the past on occasion, they'll wind up banning a few million Firefox users.
The fix here is to change line #490

http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsLivemarkService.js#490

from 

487       // Enforce well-formedness because the existing code does
488       if (!result || !result.doc || result.bozo) {
489         this.insertLivemarkFailedItem(this._livemark.folderId);
490         this._ttl = ERROR_EXPIRATION;
491         throw Cr.NS_ERROR_FAILURE;
492       }

to

487       // Enforce well-formedness because the existing code does
488       if (!result || !result.doc || result.bozo) {
489         this.insertLivemarkFailedItem(this._livemark.folderId);
490         this._ttl = EXPIRATION;
491         throw Cr.NS_ERROR_FAILURE;
492       }

right?
Probably. I don't have a strong feeling about whether it should be DEFAULT_EXPIRATION if the fix for bug 357236 sets EXPIRATION to the user's pref if there is one. The old non-Places code used a hard-coded 60 minutes for failure to parse, even with a user pref, but I'm not sure whether that was heavy-handed but right, or just heavy-handed.
(In reply to comment #2)
> The old non-Places code used a hard-coded 60 minutes for
> failure to parse, even with a user pref, but I'm not sure whether that was
> heavy-handed but right, or just heavy-handed.
> 

I don't know if it was right either, but the upcoming patch will make it the same, which is all that matters, evidently.
Assignee: nobody → sayrer
Status: NEW → ASSIGNED
Attachment #242735 - Flags: review?(mconnor)
Comment on attachment 242735 [details] [diff] [review]
set XML errors to 60 seconds

you mean 60 minutes, not 60 seconds, obviously ;)
Attachment #242735 - Flags: review?(mconnor) → review+
Severity: major → trivial
minutes... seconds... who gives a rip!
Checking in nsLivemarkService.js;
/cvsroot/mozilla/toolkit/components/places/src/nsLivemarkService.js,v  <--  nsLivemarkService.js
new revision: 1.3; previous revision: 1.2
done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: