createLivemark fails if created feed cannot be loaded




11 years ago
9 years ago


(Reporter: toddsf, Assigned: toddsf)


Firefox 3
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)



(1 attachment)



11 years ago
createLivemark() calls updateLivemarkChildren(). If in attempting to load the specified feed, the Livemark service generates an exception, it is handled thus:

 305     catch (ex) {
 306       if (livemark.loadingId != -1) {
 307         this._bms.removeItem(livemark.loadingId);
 308         livemark.loadingId = -1;
 309       }
 310       MarkLivemarkLoadFailed(livemark.folderId);
 311       livemark.locked = false;
 312       return false;

However, at this point, livemark.loadId is undefined. Because it's not equal to -1, the Livemark service attempts to have the bookmarks service remove it, which as expected fails with the following error:

[Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsINavBookmarksService.removeItem]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsLivemarkService.js :: LS__updateLivemarkChildren :: line 619"  data: no] 

Probably the most straightforward fix for this to change pushLivemark to ensure that this value is initialized to -1, like so:

return this._livemarks.push({folderId: aFolderId, feedURI: aFeedURI, loadId: -1});

... but I confess that I'm not sufficiently familiar with this code to understand whether that would have unintended consequences.
that fix should be correct (can you create a patch?), hwv the real fix would be remove completely loadingId, that is bug 407468

Comment 2

11 years ago
Created attachment 310556 [details] [diff] [review]
Initialize loadingId to -1 in pushLivemark

As requested...
Attachment #310556 - Flags: review?(dietrich)
could you also remove this useless check?

  insertLivemarkLoadingItem: function LS_insertLivemarkLoading(aBms, aLivemark) {
    var loadingURI = gIoService.newURI("about:livemark-loading", null, null);
    if (!aLivemark.loadingId || aLivemark.loadingId == -1)

the first check should be useless if we initialize to -1

Comment 4

11 years ago
(In reply to comment #3)
> could you also remove this useless check?

Useless, yes, but also harmless. And it does provide some measure of safety for Livemark objects that might come in via some other path that skips the initialization that the patch adds.

As I mentioned above, I am but a poor tourist in these parts so I will defer to the local opinion. But given that you've got a more significant change pending that replaces this entire mechanism, I wouldn't immediately be inclined to do this sort of tidying up because it *might* break something.

Still, I'm happy to do it if y'all think it's the right thing to do -- it's an easy change.
insertLivemarkLoadingItem is called in 2 places actually, in both the livemark is extracted from this._livemarks... so that could not skip the init.

hwv i let this decision to dietrich
OS: Windows XP → All
Hardware: PC → All
Comment on attachment 310556 [details] [diff] [review]
Initialize loadingId to -1 in pushLivemark

fine for now, until bug 407468 is resolved. r=me, thanks for the patch.

drivers: low risk fix
Attachment #310556 - Flags: review?(dietrich)
Attachment #310556 - Flags: review+
Attachment #310556 - Flags: approval1.9?
Assignee: nobody → toddsf
Priority: -- → P3
Target Milestone: --- → Firefox 3
Comment on attachment 310556 [details] [diff] [review]
Initialize loadingId to -1 in pushLivemark

Attachment #310556 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Checking in toolkit/components/places/src/nsLivemarkService.js;
/cvsroot/mozilla/toolkit/components/places/src/nsLivemarkService.js,v  <--  nsLivemarkService.js
new revision: 1.41; previous revision: 1.40
Last Resolved: 11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Keywords: checkin-needed
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.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.