388716 - Subscribing to same RSS feed will return NULL entries

Status: VERIFIED FIXED

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

Description

[Tony Chung [:tchung]]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007071812 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007071812 Minefield/3.0a7pre

On trunk, adding the same RSS feed to one that already exists, will return empty entries.   This doesnt repro on 2.0.0.5, as the 2nd duplicate RSS feed still returns the contents found.

Reproducible: Always

Steps to Reproduce:
1. launch trunk, new profile
2. goto site with RSS feeds.  (eg. cbs.sportsline.com)
3. Add a RSS feed to live bookmarks, to the bookmark Toolbar (eg. "NBA basketball news")
4. Click on the RSS bookmark, verify entries are returned.
5. Go back to the same website, and subscribe to the same RSS feed again
6. Verify two RSS bookmarks are now added, and clicking on them will show one with entries, and the other return (EMPTY).

Doesnt repro on bon echo builds.
Actual Results:  
2nd RSS bookmark should still return entries

Expected Results:  
2nd RSS bookmark returns null.

Comment 1

[Carsten Book [:Tomcat]]

confirmed using the steps to reproduce on fedora F7 - also works fine in
Firefox 2.0.0.5

Comment 2

[Tony Chung [:tchung]]

Fall under places area?

Comment 3

[Christine Yen]

For more information:
Right-clicking and selecting "Reload Live Bookmark" populates the second livemark, for me.

A similar situation arises when a livemark is copied/pasted, where the second one doesn't seem to expand until forced to by the "Reload" menu item.

Comment 4

[Mike Connor [:mconnor]]

moving out bugs that don't need to block b1

Comment 5

[Mike Connor [:mconnor]]

Not going to continue to block on this.  If you disagree with this decision, please renominate with reasons why we can't ship with this in final

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: patch

another swept while looking at problems with feed reload.
when updating children of a livemark we should force update children of other feeds with the same address. The same for creation, we should always update on creation.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

since it's not clear from the patch itself, the first change is inside _updateLivemarkChildren. So it's fired on timer, if you have 2 feeds for the same url there will be a step that will update 2 live bookmarks and a step that will not update anything (because anno will show that the url has been already updated).

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

rethinking to this... why are we setting a page annotation on the livemark url instead of an item annotation on folderId? that would be unique and would solve the problem in a cleaner way...

so possible solutions:

- mantain page annotation, in fireTimer fill an array with correctly updated item urls, before updating a livemark check if we have already updated the same url in this cycle, in that case force update (or that livemark will not be updated). Similar to actual patch, but probably cleaner.

- mantain page annotation, try to be gentle copying the results from a livemark to all other livemarks that point to the same url (will need changes to update LivemarkChildren). Would setting the same loadgroup work?

- change everything so that you mantain an internal array of livemarks and an array of unique urls livemark, when you ask results for a livemark you serve the corresponding unique. Quite big change for the actual dev cycle.

- move pageAnno to an itemAnno, so that all livemarks are reloaded based on their expiration value. Simpler change, probably the better choice if there are no reasons to have that like a pageAnno

Comment 10

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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

clearing the review request waiting for a decision.

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

i'm fixing this using itemAnno since that appear the more easy and readable solution (every livemark has an expiration and an itemId, so that appear like the correct thing to do atm), and merging this patch in Bug 419832 to simplify unbitrotting (there are other patches ready for this service)

Comment 14

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

should have been fixed by check-in of bug 419832

Comment 15

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre

-and-

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre

Comment 16

[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