Closed Bug 255637 Opened 16 years ago Closed 15 years ago
Easier way needed to create Live Bookmarks from <a> links to feeds
repro/demo: 1. go to http://www.tweakers.net./ 2. at the bottomright of the page is a blue [RSS] button, rightclick on it 3. select -- Bookmark this Link -- from the contextmenu 4. The -- Add Bookmark -- dialoue pops up exp: After selecting "Bookmark this link" the -- Properties for "New Live Bookmark" -- dialogue should pop up. A lot of sites have the RSS feed only available via this kind of link so it would be nice if we could directly bookmark them i/o having to copy/paste the url via Bookmarks->Manage Bookmarks->File->New Live Bookmark.... It's not that the current method doesn't work, but it is user unfriendly. ( this bug is vaguely related to bug 251394 )
There is no way to identify the target of a <a> as a RSS feed. I agree that there should be an easier way to create live bookmarks though; having to go through the bookmarks manager isn't ideal. I'm not sure what that should be though; adding "Create Live Bookmark for this link" in the right-click context menu for all links is overkill. I've been thinking about this off and on and haven't been able to come up with a good solution. Cc'ing ben and blake for any ideas.
Summary: Bookmark this Link on an RSS link should result in New Live Bookmark dialogue pop up → Easier way needed to create Live Bookmarks from <a> links to feeds
*** Bug 251394 has been marked as a duplicate of this bug. ***
just an idea.... forget abut the context menu If we click on the [RSS] link, Firefox will want to open that page The mimetype should tell it that this is not a page to open but something to add to "live bookmarks". As soon as it has the mimetype it should stop loading and show the "add the live Bookmarks" dialogue. After the Live bookmark is set load about:blank and show a message that you can look at the page(s) by selecting a bookmark from the Live bookmark you just created.
Can't trust mime types; for most RSS content, it'll be application/xml or text/xml or something, which doesn't indicate RSS.
A suggestion following on from comment 3 and comment 4 If a user clicks on an RSS link, we don't know if its RSS based on the MIME tag. So, let Firebird load the XML page (as it does currently), and then check to see if its RSS. This should avoid the MIME type problem. If it is RSS, offer to add it as a live bookmark (aka livemark). This could be by a popup dialog, or use the lightning bolt icon on the status bar.
The automatic filtering of the RSS would be great, but it would mean you'd have to filter any XML page on presence of RSS. This would have to be done for (RSS0.9 ?), RSS0.91, RSS0.92, RSS1.0 and RSS2.0. For a short term, maybe not perfect, solution it would be easiest to add "Bookmark This Linked RSS/Atom/Feed..." (or something similar) in the contextmenu. Open Link in New Window Open Link in New Tab ---------------------------------- Bookmark This Linked Page Bookmark This Linked RSS/Atom/Feed ---------------------------------- Save Link As... Send Link... Copy Link Location... ---------------------------------- Properties Comments: 1. the 2 "bookmarks" are now in a separate "group" 2. "Bookmark This Link..." is renamed to "Bookmark This Linked Page"
Thoughts on achieving the solution through site evangelism as opposed to an enhancement perhaps? I had a recent experience with a site (JetBrains) that had a link to an RSS on their site. I suggested they add the link tag so the RSS feed would get picked up. They added it and now it works the intended way with the nice RSS in the toolbar.
I agree with Steve on suggesting <link> tags, but that's not always possible. A simple example is the MozillaZine forums, where there are daily posts about new versions and they offer a link to an RSS feed. Because of the limitations of a forum, users can't add tags to the header, only a few specific ones to the contents of their posts. I suggest offering right-click menus, but only to links that /look like/ RSS feeds (http://....rdf,.rss,.xml) -- somewhat like we have "Copy e-mail address" to links that use the mailto: protocol. I know this isn't a completely reliable method (Gentoo.org serves all their pages as .xml when they're not even XHTML, just HTML 4; reasons for that are beyond me), but it doesn't make the wrong assumption when simply bookmarking, and requires the user to be aware that he's adding a Live Bookmark.
I agree with comment 8. Parsing through the URL and guessing if it's RSS would probably catch 80-90% (just a guess) of the RSS links. Doing it after the page is already loaded is more confusion (thou yes, probably mor reliable). Thou would we want the default behavior for clicking on a link that we think is RSS to be to add a livemark? My suggestion is that if we can be reasonable sure that our regex would have none or almost none false positivies, then it might be a good candidate for default behavior change.
Another option would be to modify the dialog that appears when you click "Bookmark This Link..." so that you could specify then whether it is a Live Bookmark. You could probably get away with just a checkbox, though it might be a good idea to have a link to the help system that explains what Live Bookmarks are.
How about using the info bar. Similar to comment #5, except the info bar is less obtrusive than a pop-up, and much more explanitive than an icon tucked away in the status bar. This would also leave us (or an extension?) opportunity in the future to parse the RSS (and friends) file for display in the main window, for whatever limited value that has, while still prominently offering the syndication option.
*** Bug 258987 has been marked as a duplicate of this bug. ***
Seems to me that _when you go to bookmark the page_, we should try to see if we think it is an RSS or Atom page (e.g. by trying to interpret it using our current RSS/Atom code) and if it is (that is, if there are no fatal errors while parsing it) then you put up the Livemark dialog, otherwise you put up the Bookmark dialog.
Maybe the Feed Finder is worth a look at: <http://diveintomark.org/projects/feed_finder/>
Hardware: PC → All
(In reply to comment #15) > Maybe the Feed Finder is worth a look at: > <http://diveintomark.org/projects/feed_finder/> In particular the testpages http://diveintomark.org/tests/client/autodiscovery/ are interresting. Firefox does fail in some cases ( like http://diveintomark.org/tests/client/autodiscovery/html4-014.html where Uppercase is used i/o Lowercase ). A simple toLowerCase() would easily fix this offcourse. (I am aware the above does not refer this bug)
*** Bug 258384 has been marked as a duplicate of this bug. ***
An easy fix could be this: Change the add-bookmard/add-live-bookmarks dialog boxes such that they are ONE dialog boxes with two tabs - "Bookmark" and "Live Bookmark". This is the dialog box which will pop-up when the user clicks "Bookmark this link" from a context menu. The default will be a regular bookmark, but if the user will click the "live" tab, the URL will already be filled in where it belongs. A lightweight alternative: Add a "live bookmark" checkbox to the "add bookmark" box. The rest is obvious.
*** Bug 260491 has been marked as a duplicate of this bug. ***
There's no single good answer. As Hixie said in comment 14 we can attempt to parse every single displayed page that someone attempts to bookmark (*every* page, because RSS is delivered as text/plain and text/html as often as application/xml), and *offer* to bookmark or Live Bookmark it (I'll thank you not to force a Live Bookmark when I'm bookmarking at a genuine text/plain test-case), which covers almost all the wrong-mime-type situations (except application/octet-stream), we can have handlers for application/rss+xml and application/atom+xml (though we're likely to lose that one to real aggregators, since it can be used) assuming we cheat and pass the handler the URL, not a copy of the file (since RSS doesn't have an element that gives you the URL to bookmark), we can try to guess what a link leads to by the URL (keeping in mind that popular blogging programs like WordPress typically have their feeds at .../feed/) so that we can quite often avoid the ugly step of displaying garbage to subscribe to it... Or, we can just say "we support autodiscovery, get to adding those <link> elements" with extensions like http://philringnalda.com/mozilla/livemarkthis/ to cover the needs of really heavy Live Bookmark users.
(In reply to comment #20) > Or, we can just say "we support autodiscovery, get to adding those <link> > elements" with extensions like http://philringnalda.com/mozilla/livemarkthis/ to > cover the needs of really heavy Live Bookmark users. I'm very happy to go this route, especially for 1.0. That extension is awesome, btw! I was hoping someone would do that -- it was decided to not put it in the UI, but for the people who are interested in heavy live bookmark use, it's great. Get it on update.mozilla.org if it isn't there already :)
*** Bug 261007 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Can't trust mime types; for most RSS content, it'll be application/xml or > text/xml or something, which doesn't indicate RSS. True that. On the other hand I haven't seen a lot of web pages linking to not rss xml files. Having said that, if there is still now way for the browser to indentify a xml target as a valid RSS feed, then a context menu item like eg. "Bookmark as RSS feed" should be prefered to "Bookmark *this* RSS feed" IMVHO.
Does this bug also cover the request for a "New Life Bookmark" toolbar button in the bookmark manager?
(In reply to comment #24) > Does this bug also cover the request for a "New Life Bookmark" toolbar button in > the bookmark manager? I don't expect that to happen - such a button did exist for a couple of days, but was removed.
(In reply to comment #25) > (In reply to comment #24) > > Does this bug also cover the request for a "New Life Bookmark" toolbar button in > > the bookmark manager? > > I don't expect that to happen - such a button did exist for a couple of days, > but was removed. Actually, it might come back -- it was removed only because it was deemed as not-generally-useful UI. However, given the relative popularity of live bookmarks, and that going through the bookmarks manager is the only way to manually create a live bookmark, it might make sense to put the button back...
For some reason, one relatively simple solution wasn't mentioned yet. If someone clicks on an rss feed, an xml document tree is shown. There even is a bar telling that "This XML file does not appear to have any style information associated with it. The document tree is shown below." So, how difficult it is to discover if it's an rss feed NOW? All we need is a bar telling "It's an rss feed, click here to create a live bookmak". Granted, we'd love this dialog to be shown before XML is loaded, parsed, or even sooner - but this solution seems as good as you can get. People simply click on links anyways, even if they are rss feeds. At least I, when I found RSS feed for the first time, just left-clicked. An idea of bookmarking it instead never crossed my mind.
*** Bug 261939 has been marked as a duplicate of this bug. ***
One other problem: If, for whatever reason, you somehow create a normal bookmark to an RSS feed, there is no way to convert it to a live bookmark. My first instinct was to go into the properties for the bookmark and see if there was a checkbox, like the "load in sidebar" option, though depending on the underlying implementation (I haven't looked) a "convert to live bookmark" button would be better. At that point you could retrieve the file, see if it parses as RSS or Atom, and replace the normal bookmark with a live bookmark. (If it's not in a supported feed format, say "Sorry, this doesn't look like a feed" and leave it alone.) Usual caveats about content sniffing wouldn't apply, since it's in response to a specific action.
hmmm... Someone said that looking at MIME type isn't trustworthy. OK. but why not look at it anyways, and then act accordingly if it DOES say that this is a feed? Same idea could be applied to some other solutions. I think it's not hard to convince weblogging engines (such as wordpress) to use an additional header() command in their PHP files, that provide feeds. Same applies to others, i guess.
*** Bug 255529 has been marked as a duplicate of this bug. ***
*** Bug 266967 has been marked as a duplicate of this bug. ***
*** Bug 268102 has been marked as a duplicate of this bug. ***
I think the best ideas are: 1) use option/checkbox/tab in the "Add Bookmark" dialog; 2) give the possibility to change Standard Bookmark into Live Bookmark and viceversa; Another one: 3) Instead of parsing the XML file when the user clicks on it, why not download and parse it in the background when the user loads the main page? Probably you need to download only the first bytes of the file, because it starts like: <?xml version="1.0" encoding="ISO-8859-1"?><rss version="2.0" This could be a problem if a page contains a lot of links... In this case we could put an icon (bottom right) for a manual search like "Search for RSS". We could put an option like "Enable automatic search for RSS" with a limit of links.
(In reply to comment #40) > why not download and parse it in the background when the user loads the main page? Please no. This would cause such catastrophic problems with database driven sites that I would be forced to stop recommending Firefox to people. However, it would be nice for Firefox to simply handle the application/rss+xml. This may not be the only mime type used... but many css files are sent text/plain, aren't they? That doesn't make it correct. -[Unknown]
What's wrong with a checkbox to make bookmarking any arbitrary URL a Live Bookmark is that the average user doesn't understand that just bookmarking cnn.com and checking "Make it Live!" doesn't amount to a Live Bookmark. Even as hard as it currently is to livemark an arbitrary URL, I've already dealt with bugs and support questions from people who did that. Having every Add Bookmark dialog encourage people to think that way is not a happy option. As to the Right and Wrong of application/rss+xml - using that mime type is actually Wrong: it's both unregistered and unregisterable (there's no way something which encompasses all of RSS 0.91-2.0, 0.90, and 1.0, could ever be registered, and for Right use as an unregistered type it would need to be structured differently). But ignore that, and persuade someone to write handlers for it, and for application/atom+xml. The one set of statistics I'm aware of, when someone sampled 5096 feeds from the pending list at Syndic8.com, 3452 were text/xml, 1064 were text/plain. If all the rest were application/(rss|atom)+xml, that gives you ~10%, but, that's 10% of all feeds, not 10% of feeds which lack a <link> autodiscovery tag. I'd expect that using a "wrong" mime type is much more common among people who've never heard of autodiscovery than among those who have. Among the sites mentioned here and in dups, and the ones I could think of offhand that don't support autodiscovery, you would catch exactly 0%.
Assignee: vladimir → vladimir+bm
Mabey instead of looking at the mimetype, you should be instead looking at the content of the file. if it contains rss-like tags then its an rss feed. do intelegent decisions. for example: <rss version=1.0> this mush be an rss feed <html> this is not an rss feed once you know what it is, you automatically create a bookmark or a live bookmark as appropriate. the other option is to use a checkbox "make live!" but only have that avaliable if there is a <link> to the rss feed in the file that is being bookmarked, and if there is, create the live bookmark if checked (possibaly also create a standard bookmark to the reffering page?)
Arg! I accidentally pressed Enter before completing my comment. Anyway, Phil Ringnalda has a extension on his site that solves this problem. See previous comment for the link. Sorry for the spam, Prog.
Whiteboard: SA → Workaround in comment #45
I do like the "Make it live!" checkbox idea but I agree that it would be to confusing for the avarage user. But what about parsing the location of a link ONLY when the user selects "Add Bookmark" for it. The "Make it live!" (or whatever it should be called) option could be greyed out until Firefox discovers that the user is actually trying to link to a RSS/Atom Feed. And it still gives the user enough control to even create regular Bookmarks to XML/RSS/Atom-Documents. The "Add Bookmark" Dialog could look just the way it does right now. Links entered in it could be checked and parsed in the background and if it is a link to a file that's clearly a "working live bookmark" the "live bookmark flash" and a message like "This Bookmark can be used as a Live Bookmark, click here to make it live!" should appear somewhere in the dialog.
Version: 1.0 Branch → Trunk
*** Bug 285375 has been marked as a duplicate of this bug. ***
*** Bug 293014 has been marked as a duplicate of this bug. ***
> The "Add Bookmark" Dialog could look just the way it does right now. Links > entered in it could be checked and parsed in the background and if it is a link > to a file that's clearly a "working live bookmark" the "live bookmark flash" and > a message like "This Bookmark can be used as a Live Bookmark, click here to make > it live!" should appear somewhere in the dialog. I think this is definitely the right idea, no need to say "Live Bookmark" in the context menu, it's certainly good enough to show it in the Add Bookmark dialog. However, However, I think instead of a message like this, there should simply be a checkbox that is called "Live Bookmark". This checkbox would be greyed out until the browser discovers the link is an RSS feed, and then would be ungreyed and <i>checked by default</i>. I think there are very few cases where the user will want to bookmark an RSS feed but not make it Live. The majority of the time this will do what the user expects, but someone who does want a regular bookmark (perhaps a web developer) will know what the checkbox means.
My vote is to implement this exactly like the LiveBookmarkThis extension does. An additional item in the context menu when right-clicking on a link. Fetching it in the background means the browser would have to be forced to do this for EVERY single link the user wants to add and is NOT a good approach in my opinion. Just let the user choose "Bookmark this Link" or "Add Live Bookmark". It works beautifully and is the simplest approach. Anything else is just overhead with little benefit.
this isn't going to make 1.1, I don't think any of the solutions proposed thus far really work in such a way as to be acceptable for the general userbase.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
See also bug 299354.
As bug 302121 -Integrate Feedview for beta is fixed, I believe that this bug is obsolete. Feedview allows to click on a feed to view it, and in viewing mode you get option to create Live bookmark in a standard way.
(In reply to comment #53) > Feedview allows to click on a feed to view it, and in viewing mode you get > option to create Live bookmark in a standard way. Unfortunately until now, only a Bookmark (of Feedview) can be created in that way, and not an Live Bookmark afaik
How about resolving this one INVA in favor of Bug 303105 ?
Agreed. With Feedview being integrated, this is now obsolete.
Confirming, we're saying that allowing the user to have a pretty view of an RSS feel is seen as removing the need for easy ability to add a live mark from the link to a feed. That makes sense, but then I think the issue then transistions into a shortcoming in the feedview that it does not seem to allow ability to add a live bookmark from the display of the feed. Should this issue be made more generic to encompass that situation or retargeted since we're still left with essentially the same issue however we've made it past the point of detection by the feedview intergration.
Feedview does allow to add a live bookmark to the current feed, check your statusbar (The UI needs more love, but that's out of the scope of this bug).
Flags: blocking-aviary2.0? → blocking-aviary2.0-
I do see the typical icon for feed detection thou since we have a "control area" in feedview where the adjust article length control is, perhaps a link to adding the livemark could be in that section as well to be clearer for newer users or ones who don't notice / understand the icon in the status bar.
(In reply to comment #59) > I do see the typical icon for feed detection thou since we have a "control area" > in feedview where the adjust article length control is, perhaps a link to adding > the livemark could be in that section as well to be clearer for newer users or > ones who don't notice / understand the icon in the status bar. That's the "more love" part of comment 58.
Closing WFM given the comments (Peter please reopen if you disagree) If there are "UI needs more love" bugs in the feedview implementation please file seperate bugs for them. Ben G and Beltzner have put some thoughts on areas that need imporvement at http://wiki.mozilla.org/Firefox:1.1_RSS_Pretty_Print which I believe covers most of the points raised below.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Having backed out of feedview, this bug gets re-opened, really. I don't think we'll be able to hit 1.5 with any form of a solution, mind you, but we should either leave it open or resolve it WONTFIX.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #62) > Having backed out of feedview, this bug gets re-opened, really. I don't think > we'll be able to hit 1.5 with any form of a solution, mind you, but we should > either leave it open or resolve it WONTFIX. Should the - be changed back as well?
*** Bug 306140 has been marked as a duplicate of this bug. ***
(In reply to comment #63) > Should the - be changed back as well? Yeah, I'll renominate this for 1.8b4 blocking, but I'm not myself so sure that it's a *must-have* for 1.5, as a good number of sites are using the <link rel> tag to indicate XML feeds.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Flags: blocking1.8b4? → blocking1.8b4-
Resolution: --- → WONTFIX
*** Bug 306488 has been marked as a duplicate of this bug. ***
I see no reason to differ between "bookmark types" (is it alive or dead?) at creation time. proposed workflow: 1.) User hit create bookmark a link (html, feed, mailto, whatever) 2.) Bookmark ist stored in the choosed folder 3.) if the user click (activate it) on the bookmark the URI is loaded and type is recognized 3.1.) if the URI point to a HTML file a new tab open and show the file 3.2.) if the URI point to a Feed the Living Bookmark Feature activate and show the feed messages as folder content 3.3.) if the URI is a mailto the mail program starts 3.4.) if the URI is whatever - whatever can interpret this uri starts and do its job.. (FTP, IRC, PDF Viewer, News Reader, Download Manager, etc...) 4.) After a Bookmark is hitted once the "type" of the bookmark get cached to speed up the processs next time. This way a user dont need to bother about URI type and can just use it. This way you dont need to check all links in the page for the type. This way you dont blow up UI with additional (unnessesary) choices. And this way you are flexible for new future content types. greets knt
(In reply to comment #67) > 3.2.) if the URI point to a Feed the Living Bookmark Feature activate and show > the feed messages as folder content While I like the design approach (a bookmark is a bookmark and let the system sort out the best way to handle it), IIRC the problem here is that detecting a feed is not an exactly trivial matter. It takes time and pre-processing of any file with a .rss, .rdf or .xml extension.
(In reply to comment #68) > While I like the design approach (a bookmark is a bookmark and let the system > sort out the best way to handle it), IIRC the problem here is that detecting a > feed is not an exactly trivial matter. It takes time and pre-processing of any > file with a .rss, .rdf or .xml extension. Not to mention, that I've already seen feeds with extensions like shtml, asp, jsp and even jhtml. If anything, we have to rely on content type, not extensions.
> While I like the design approach (a bookmark is a bookmark and let the system > sort out the best way to handle it), IIRC the problem here is that detecting a > feed is not an exactly trivial matter. Well, you are right. Its not trivial and it should not relay on extensions and in worst case it could take some more time to process. But is it a worse performace hit to take a small peek? Also It only occurs if the user hit a bookmark first, cause "real content type" can be cached as bookmark attribute. (its unlikly to change - right?) Is the mime-type "application/rdf+xml" defined in RFC 3870 optional or not generaly used? The mime-type is the piece of information that is designed to give this kind of informations! (btw.. why in god shake is it something ugly like "application/rdf+xml" and not "text/rdf"?) side note: look at this url www.digital-environment.net/mourning/Banner/banner.php It is an image (i guess a jpeg) but because no content-type is given firefox "fail" to show it but if you warp the url in a html img tag it works nicly again... So it seem firefox dont look at the content at all but relay completly on extension and/or mime type - why not in this RDF case to? "sorry - if you break the standard I can not give you the most effectiv workflow available" - sound okay for me :o basicly 2 steps to recognice content-type: 1) look at the mime-type of the file and decide what should be done with the file (standard mode). 2) if no content-type is given or the content type may not be specific enough (i.e. text/xml?) or the public usage of a content type differs from standard - check the first XXX bytes (i.e. check for the used namespace or common tags) of the content to be sure about content-type. (optional compatibility mode) I saw something called "URILoader" around - i am not sure cause i just start to look around in your pretty project - but the name told me that is exact the thing what should be used to decide what firefox should do with a given URI :D greets Knut p.s. sorry for my bad wording.. en is not relay a strong side of me :( hope you get the meaning - if not ask so i can clarify :D
> Is the mime-type "application/rdf+xml" defined in RFC 3870 optional or not > generaly used? > > The mime-type is the piece of information that is designed to give this kind of > informations! oh just noticed.. news feeds are not exatly RDF, but somewhere related.. RSS1.0 Spec says: "The current mime-type recommendation for an RSS 1.0 document is application/xml. However, work is currently being done to register a mime-type for RDF (and possibly RSS). The RDF (or preferably RSS) mime-type should be used once it has been registered." If this still true mime-type is not realy helpfull in this case :(
> Is the mime-type "application/rdf+xml" defined in RFC 3870 optional or not > generaly used? > > The mime-type is the piece of information that is designed to give this kind of > informations! oh just noticed.. news feeds are not exatly RDF, but somewhere related.. RSS1.0 Spec says: "The current mime-type recommendation for an RSS 1.0 document is application/xml. However, work is currently being done to register a mime-type for RDF (and possibly RSS). The RDF (or preferably RSS) mime-type should be used once it has been registered." RSS2.0 seems not to be a RDF application at all. For Atom Feeds the mime-type "application/atom+xml" is defined. So mime-type seems not to be realy helpfull in case of news feeds. wrong but working: dont trust the mime-type ;)
*** Bug 258824 has been marked as a duplicate of this bug. ***
*** Bug 311066 has been marked as a duplicate of this bug. ***
*** Bug 331727 has been marked as a duplicate of this bug. ***
This has been resolved by the new Feed Preview functionality. See http://wiki.mozilla.org/Feed_Handling for details.
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
You need to log in before you can comment on or make changes to this bug.