Closed Bug 251447 Opened 20 years ago Closed 18 years ago

Automatic retrieval of Atom/RSS feed's title for Live bookmarks

Categories

(Firefox :: Bookmarks & History, enhancement)

Product:
Firefox
Component:
Bookmarks & History
Platform:
x86
Windows XP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 348227
Milestone:
Firefox 3 alpha1

People

(Reporter: mozilla, Unassigned)

References

Details

(Keywords: polish) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7) Gecko/20040714 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7) Gecko/20040714 Firefox/0.9.1+

Like the summary says - Livemarks should, by default, use the title of the RSS
or Atom feed as their title, rather than the title of the page.

There are many cases where the content of the feed isn't restricted to the
content of the page from which one happens to subscribe, for example Firefox's
product page.

Reproducible: Always
Steps to Reproduce:
1. Visit getfirefox.com
2. Click the Livemark icon
3. Accept the default title

Actual Results:  
Title is "Firefox - The Browser, Reloaded"; the feed is for all of mozilla.org

Expected Results:  
Title should be "Mozilla Dot Org"
Doing this would require fetching and parsing the feed when the user tries to
bookmark the feed; this would probably block the UI on all but the fastest
connections.  Alternatively, we could fetch one of the feeds on page load and
grab its title, but that would add extra load/network activity for every page
that has a rss feed, whether the user wants to livemark it or not.  I don't
think either of those are acceptable solutions.

Another possibility is to include a checkbox that says "Use title from feed" in
the add bookmark dialog, but that would mean that the user has no way to know
what the livemark they just added will be called.  Or maybe checking that box
causes the feed to be downloaded/parsed for the title; that might be acceptable
(unchecked and page title as livemark title by default, check it and the page
title entry gets disabled and filled in with the real feed title once its loaded).

I'm open to other suggestions, also.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I was thinking of fetching and parsing the feed when the user tries to
bookmark the feed, but I understand that this wouldn't be friendly to slower
connections.

I like the idea of an extra checkbox in the dialogue, except I'd make it a
button. The user would click the button ("Get Feed Title" or similar), the feed
would be fetched and parsed, and the editable title displayed in the dialogue
would change to the feed's actual title; the user then dismisses the dialogue by
choosing OK. This way the user gets to see the feed's actual title before
completing the process of bookmarking it.

If the feed is invalid or AWOL, a notification dialogue would pop up saying "The
feed could not be found or contains an error [OK]", and the editable title would
not change.

As a bonus prize for users with patience or a fast connection, perhaps there
could also be an "Automatically retrieve feeds' titles" checkbox.
Summary: Livemarks should use RSS/Atom feed's title by default, not the page's title → Automatic retrieval of Atom/RSS feed's title for Livemarks
Severity: minor → enhancement
*** Bug 253315 has been marked as a duplicate of this bug. ***
Under the category of how everyone else is doing it.

RSS Bandit:
http://img.photobucket.com/albums/v259/red_avni/rssbandit_newfeed_1.png
http://img.photobucket.com/albums/v259/red_avni/rssbandit_newfeed_2.png
http://img.photobucket.com/albums/v259/red_avni/rssbandit_newfeed_3.png

NetNewsWire:
http://ranchero.com/downloads/nnwServicesSubscribe.mov
  moving pictures...what will those zany mac people think of next?

SharpReader:
Doesn't allow you to subscribe until after it has retrieved the xml. It
automatically uses the feed title. Very streamlined interface. This seems to be
the most common way of doing it with the minimal aggregators.

FeedDemon:
http://img.photobucket.com/albums/v259/red_avni/feeddemon_newfeed_1.png
http://img.photobucket.com/albums/v259/red_avni/feeddemon_newfeed_2.png
  The auto-discover checkbox will fill in the title on screen 3.
http://img.photobucket.com/albums/v259/red_avni/feeddemon_newfeed_3.png
http://img.photobucket.com/albums/v259/red_avni/feeddemon_newfeed_4.png
  
I tried a few others and one (blago) gives an input, and actually says something
to the affect of "no title" - site.com on the subscriptions tab until it gets
the title from the rss.

Whatever the ultimate solution, I think changing it so that the the Title
attribute of the Link tag for the feed gets in before 1.0. Sites with multiple
feeds require a way to differentiate them.

Personally, I agree 100% with Greg's line of thinking.


(In reply to comment #4)
> Whatever the ultimate solution, I think changing it so that the the Title
> attribute of the Link tag for the feed gets in before 1.0. Sites with multiple
> feeds require a way to differentiate them.

Not sure what you mean here -- in most cases, the title attribute is just
something like "RSS" or "XML" or whatever.  Very few sites (I've yet to run into
any, honestly) actually set a real title there.  Perhaps  "Page Title (Link
Title)", e.g. "Mozilla Blah Blah (RSS)" for a feed whose title is RSS..
Summary: Automatic retrieval of Atom/RSS feed's title for Livemarks → Automatic retrieval of Atom/RSS feed's title for Live bookmarks
*** Bug 260620 has been marked as a duplicate of this bug. ***
*** Bug 261439 has been marked as a duplicate of this bug. ***
Trying to add a feed for Thunderbird shows the original RSS title. That's happen
because the feed will be verified before it is added to the News & Blogs
account. Vladimir, we don't have extra load when we cache the received feed data
and use it afterwards to fill the live bookmark. We have to do it either way.
When adding a live bookmark the bookmark dialog could show a line like
"Verifying RSS feed..." and an undetermined progress bar. So the user sees that
there is activity. IMO this would be the smartest way to get the RSS title into
the bookmark name.
Assignee: vladimir → vladimir+bm
*** Bug 273236 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
> (In reply to comment #4)
> > Whatever the ultimate solution, I think changing it so that the the Title
> > attribute of the Link tag for the feed gets in before 1.0. Sites with multiple
> > feeds require a way to differentiate them.
> 
> Not sure what you mean here -- in most cases, the title attribute is just
> something like "RSS" or "XML" or whatever.  Very few sites (I've yet to run into
> any, honestly) actually set a real title there.  Perhaps  "Page Title (Link
> Title)", e.g. "Mozilla Blah Blah (RSS)" for a feed whose title is RSS..

That some webmasters code their pages wrongly doesnt mean that a product that
parses those pages should comform to their buggy useage.
The title attribute for a link has a purpose to be used.
If you want to see a page that correctly uses it try mine, that way at least you
have seen one :P
URL: http://www.trimoon.demon.nl/
There are two titles, with different purposes. <link rel="alternate"
title="RSS"> is not wrong, it is exactly according to spec (it's not required to
be RSS, but that's the example), because the purpose of the title of an (X)HTML
<link> is to tell someone looking at an HTML page what sort of link it is: see
the toolbar in Seamonkey or iCab. "RSS" is a perfectly appropriate title,
fitting in with "Top", "Next", etc., while "Jimbob's Weblog" doesn't say what
sort of link it is, and "Jimbob's Weblog in RSS" doesn't do either use much
good: looking at the HTML, you already know that's Jimbob's Weblog, and once
you've subscribed, you already know it's RSS.

The correct place for the title of a feed is in the feed, in <channel><title>.
We just have to find a way to look it up that doesn't interfere with the
"bookmarkingness" of adding a feed in Firefox. Unfortunately, doing that means
either forking addBookmark2.xul or rewriting its API, neither of which could
happen during the 1.0 runup.
I think that even if we don't go direct to the feed, it should at least use the
<link> title by default, rather than the page title.

Currently any page with multiple feeds on it ( e.g. http://www.aub-unison.org.uk
) , displays the link title correctly in the add feed icon.

Unfortunately when you click to add, it then goes and ignores the link title and
just uses the page title, ending up with duplicate titles in bookmarks etc. if
you subscribe to more than one from the same page.
(In reply to comment #11)
> There are two titles, with different purposes. <link rel="alternate"
> title="RSS"> is not wrong, it is exactly according to spec (it's not required to
> be RSS, but that's the example), because the purpose of the title of an (X)HTML
> <link> is to tell someone looking at an HTML page what sort of link it is: see
> the toolbar in Seamonkey or iCab. "RSS" is a perfectly appropriate title,
> fitting in with "Top", "Next", etc., while "Jimbob's Weblog" doesn't say what
> sort of link it is, and "Jimbob's Weblog in RSS" doesn't do either use much
> good: looking at the HTML, you already know that's Jimbob's Weblog, and once
> you've subscribed, you already know it's RSS.

I don't think it necessarily has to be so restrictive as to say only 'RSS'.  A
more descriptive title of the content is perfectly reasonable according to the
examples given for link titles here:

http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3.3

There they have examples such as 'The manual in French' and 'The first page of
the manual'.  This is describing the content not the format it is stored in
(which should be defined by the 'type' attribute).
(In reply to comment #13)
> I don't think it necessarily has to be so restrictive as to say only 'RSS'.  A
> more descriptive title of the content is perfectly reasonable according to the
> examples given for link titles here:
> 
> http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3.3
> 
> There they have examples such as 'The manual in French' and 'The first page of
> the manual'.  This is describing the content not the format it is stored in
> (which should be defined by the 'type' attribute).

To expand on this a bit: In the W3C document above, the title of the
page in question is given as "The manual in English", the alternate
links give the same title in other languages.  It seems clear to me
that using the title in the link for the name of the Live Bookmark
is the right thing to do, given the examples in the W3C document.

I have another point of view on this.  I maintain a web site, on
that web site is a "News" page.  On that "News" page I actually
have two different sections each containing a different type of
news article.  One lists external events which will occur in the 
near future and the recent past, and the other lists changes to
the website.  I have two RSS feeds, one for each section.  The
problem is that since Firefox does not use the value of the
title attribute of the link element in the head of the document
the two RSS feeds are created with the same title by default,
namely the title of the "News" page.  In addition, I have links
to two other related RSS feeds on that page.  Of course, those
links are also given the title of the "News" page instead of
the value of the title attribute of the link element.

Here's another thought: many sites have pages which contain
lists of RSS feeds available from that site.  Washingtonpost.com,
for example, has an "RSS Feeds" page which lists all of the feeds
available.  Wouldn't it be nice if they could all be included
in link elements in the head of the document so that the user
could pop up a menu of all of those feeds from the Live Bookmark
icon at the bottom of the Firefox window?  Instead of having to
find the web page associated with each RSS feed and Live
Bookmarking each page one at a time?

(In reply to bug 253315 comment #1)
> This is a problem with the web page itself; a <link> with a RSS feed should be
> relevant to the page it's on, not something else.  (If it's something else, it
> should just be a normal <a> link somewhere within the body.)

Sometimes the feed *is* relevant to the page it's on, but it applies to other
pages too, e.g. the rest of that site, so the logical title is the site's title,
not the page's.
This seems like it's been resolved with the new Live Bookmark creation method
via feedview.  It uses the TITLE field in the feed to name the live bookmark.
(In reply to comment #16)
> This seems like it's been resolved with the new Live Bookmark creation method
> via feedview.  It uses the TITLE field in the feed to name the live bookmark.

Yes. It prepends "Feed: " but it does use the correct title.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 304689 has been marked as a duplicate of this bug. ***
This was regressed by the checkin from bug 305134 comment 12.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to bug 305799 comment #2)
> I don't think it should block, no, since bug 251447 (which I fully support, btw)
> probably represents a non-trivial amount of work. We kinda got it for free with
> feedview in that feedview DID parse the feed, but now that we're not doing that
> again, we'd need a solution like the one proposed in bug 251447 comment 8.
> 
> Some points in that bug are valid, and we should probably adopt a change to get
> around the case where there are multiple feeds that someone wants to bookmark on
> a single page; in those cases, I think a smarter default name for the Live
> Bookmark might be "&pageTitle; - &feedTitle;". Not perfect, but should cover a
> lot of the cases. Thoughts?

I suggest retrieving and parsing the feed before presenting the Add Bookmark
dialogue. This will ensure the feed actually exists and that Firefox can read it
and will allow the most appropriate title to be chosen for the live bookmark.

Upon clicking the Add Live Bookmark icon, show "Validating the feed" and a
progress bar. RSS/Atom files are generally small so the wait won't be excessive;
anyway, Thunderbird makes the user wait at this point.

If the feed is AWOL, invalid or otherwise foreign to Firefox, display "There was
an error retrieving the feed." or "There was an error reading the feed." as
applicable, and abort.

If the feed is given the Firefox seal of approval, display the Add (Live)
Bookmark dialogue with the Title field prefilled with the feed's actual title.
The author should have given semantically distinct feeds different titles and
Firefox should have offered only one of each set of semantically indistinct
feeds (such as in bug 305134 comment 4). i.e. the feed's title needs no further
qualification.

The user optionally changes the title to suit them better (we can't read minds),
picks a bookmark folder and clicks OK. Fin.
(To be clear on the context in which I was cross-quoted: I *do* support using
the full feed title, but I *don't* think that doing so should block 1.5 :)

As for the proposal above, it sounds good to me but do remember to consider the
case where there's > 1 feed. At that point, we want to be able to give the user
some choice of which of the feeds they want to subscribe to before getting the
relevant title. I don't think we want to go parsing an arbitrary number of feeds
just to get that list of names, as that operation could take significant time.
(In reply to comment #21)
> As for the proposal above, it sounds good to me but do remember to consider the
> case where there's > 1 feed.

I did consider that case, I just forgot to explicitly mention it. If there are
several feeds, show a menu of them as is currently done, using the titles given
by the page. When the user chooses one, retrieve and parse that feed and
continue as if it was the only feed.

It *does* make sense for the title given to the live bookmark to be different to
the one shown in the dropdown menu of feeds, in the same way that it often makes
sense for link text to be different to the title of the target page. Besides,
the author specifies the titles independently and for the purposes for which
we'd be using them.
That's right along the lines of what I was thinking for the expected behaviour.
Sounds like we're on the same page. :)
*** Bug 308000 has been marked as a duplicate of this bug. ***
Assignee: vladimir+bm → nobody
Status: REOPENED → NEW
*** Bug 327274 has been marked as a duplicate of this bug. ***
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
Keywords: polish
Target Milestone: --- → Firefox 3 alpha1
Fixed for 2.0 and beyond in bug 348227

*** This bug has been marked as a duplicate of 348227 ***
Status: NEW → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.