On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson <[email protected]> wrote: > I have already added an API for PageActions and have a working RSS > PageAction extension, which does feed auto-detection on the page. Now it is > time to look into Feed previews. > I have spoken briefly to AdamB and EvanM about feed previews and both > suggested modelling this after the view-source implementation. It was also > suggested to add a scheme for this (like we do with view-source), such as > view-feed: or feed: > I know there has been some work on this front before, although the status of > that is not clear to me -- except that it was disabled at some point (or > removed from the codebase?). I would love to see what was done back then, if > anyone knows more. A cursory look through the code indicated that mime type > sniffing for feed is done. I've heard there is also some remaining work > required for sanitizing the feeds before showing, but besides the above > there is not much more I know at this point in time.
Feed previews only ever got to the state of "we know this page is a feed, so right <here> is where we'd stick in the template". Actually, the old file has somehow evaded deletion: webkit/glue/resources/feed.html . Here are some things to consider: - Parsing feeds is an absolute nightmare. See e.g. http://diveintomark.org/archives/2004/02/04/incompatible-rss . You definitely want to at least do it in the renderer process. Ideally it'd be from JavaScript -- you might then be able to borrow the parsing code from Mozilla(?) -- but I guess that may reject invalid XML, which there is (or at least used to be) a ton of. Maybe we don't care and XSL is sufficient. Definitely look at the Mozilla implementation. - You should be careful about HTML content. Say site A publishes a feed, and site B publishes a feed that mixes posts from A in among others. If A puts <script> tags in their feed, you don't want to run those scripts on B's origin when you attempt to preview the feed on B. (Normally, this kind of untrusted input handling is B's problem, but that's not how the feed world works.) Ideally, you could work around this by somehow not having an origin *at all* when displaying a feed -- abarth would know more about this than I would. - Some existing practice on the web is to use "feed://hostname/etc.xml", which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. - The feed-sniffing code we have is probably not very good and may currently be disabled. Eye it with suspicion. This page (sorry for the non-public URL) summarizes the behaviors of various browsers in various circumstances: http://www/~evanm/projects/chrome/feeds/ http://www/~evanm/projects/chrome/xml/ I'd suggest starting with getting view-feed: to do the right thing when it's handed something correct, and then worry about fleshing out all the sniffing/redirecting/etc. second. I'd be happy to review any changes you make in this area. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
