Open Bug 270275 Opened 21 years ago Updated 2 years ago

Doesn't recognise when articles have been modified since original download

Categories

(MailNews Core :: Feed Reader, defect)

defect

Tracking

(Not tracked)

People

(Reporter: ygoe, Unassigned)

References

Details

User-Agent: Firefox/0.10 (Windows NT 5.1) Build Identifier: Thunderbird 0.8 - 0.9 Sometimes RSS newsfeed's items change because the author makes an update to them. Thunderbird should now detect this change and mark the item as unread or updated so that I see there's a change. But it doesn't. You will miss any change of the RSS feed after you have downloaded it once. Reproducible: Always Steps to Reproduce: 1. Download RSS newsfeed 2. Change an item of the feed 3. Item is not updated in Thunderbird Actual Results: Item is not updated in Thunderbird Expected Results: Item should be updated in Thunderbird and marked appropriately
Confirming, and adjusting summary.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: RSS items are not updated in Tb when they change in the source → Doesn't recognise when articles have been modified/updated since original download
Isn't this the responsibility of the feed, not of the client? All the client does is retrieve the feed, telling the server what it's seen already. This is not a problem if you configure the feed to store articles that load the web page rather contain than the summary.
All that the server does is provide a more or less static XML/RSS compliant file via HTTP. All the client can do is get this file and parse it. I know from SharpReader that it can detect updated items which are likely to appear on forums, weblogs or redactional content (news ticker like heise.de). Of course with this the URL or GUID (if present at all) of an item won't change, so the client must somehow maintain a hash of the content or so. And I really prefer feeds that contain the data inline than having to read some fully-bloated website with all sidebars, headers and irrelevant stuff inside a little feed reader window. With remote content, it would actually be worse since you don't realise when the content has changed because the feed reader never gets to see it. This is not a solution to our problem.
(In reply to comment #2) > Isn't this the responsibility of the feed, not of the client? All the client > does is retrieve the feed, telling the server what it's seen already. > > This is not a problem if you configure the feed to store articles that load the > web page rather contain than the summary. Disclaimer - I know nothing about the XML of an RSS feed. I've got feeds that add the article again when something changes, and I've got feeds that don't. If there's any way that Thunderbird can easily identify changed articles, then it should IMHO. If RSS doesn't give that ability, then this bug should be adjusted accordingly. I confirmed the bug based on the initial report and the guidelines given for confirming unconfirmed bugs (clear report, not obvious dupe). I'll leave technical stuff to those who know best.
So nobody uses RSS feeds in Thunderbird or feels like this should be fixed? What's the current status of this, please? My suggestion of a possible solution (I have no idea of Thunderbird's internals): Store a hash of the article content and metadata and compare it each time the article is downloaded again. When it differs, mark the article unread (or better: updated*) in the list. *) could be in italic font (cf SharpReader), default rules for marking read apply Estimated work for an experienced Thunderbird coder: not longer than 1-2 hours. How far from reality is this?
Flags: blocking1.8b4?
not a blocker. feel free to contribute a patch if this is something you are interested in.
Flags: blocking1.8b4? → blocking1.8b4-
Sorry for the block request, I thought I'd just try it out... there's no docs about it. > feel free to contribute a patch if this is something you are > interested in. It would take me a considerable amount of time only to get into the code and I have other projects to work on. So may I assume you're not interested in it? I'm just curious if I should wait at all for this bug to be fixed sometime.
This is still a problem with Thunderbird 1.5.0.9.
QA Contact: rss
I don't know whether this bug is still an issue. I know that on some Craig's List feeds, I'll see a few items appear several times over the course of a week, while most of the items in the list have just the single entry. I've been wondering why and supposing that the ad has been somehow updated on the host, resulting in a duplicate (or near-duplicate) item in my folder. If I'm correct about that, then maybe this bug no longer occurs. Yves Goergen, do you still have this problem? This symptom I describe is not the same as bug 258465. It's probably worth noting that 258465, which has dozens of duplicates, is sort of an opposite problem of this bug.
No, I've quickly moved on to an RSS-to-email application that did the job better than Thunderbird. Meanwhile, I've re-written the whole thing and it now supports the References: header to correctly thread the updates in threaded view in Thunderbird. This has the advantage that I also get feed items when my computer is off, which cannot be solved by Thunderbird (or any other client-computer software) for conceptual reasons. I now handle RSS newsfeeds the same way as mailing lists, with my own server-based "adaptor".
Assignee: mscott → nobody
Component: RSS → Feed Reader
Product: Thunderbird → MailNews Core
This might be caused by the problem cited in bug #754704.
OS: Windows XP → All
Hardware: x86 → All
I don't think this is a bug of TB, but rather of the feed provider. Please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=754704#c4 for explanation.

alta88, do you disagree with comment 15? Or, does this bug not match that issue?

Flags: needinfo?(alta88)
Summary: Doesn't recognise when articles have been modified/updated since original download → Doesn't recognise when articles have been modified since original download

Yes, updates should be handled in atom, maybe not doable in poorly specified rss. There are issues of implementation and user choice in deciding how to handle updates.

Flags: needinfo?(alta88)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.