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.
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.
*** 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..
*** 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.
*** 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.
*** Bug 304689 has been marked as a duplicate of this bug. ***
This was regressed by the checkin from bug 305134 comment 12.
(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. ***
*** 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
Fixed for 2.0 and beyond in bug 348227 *** This bug has been marked as a duplicate of 348227 ***