On Thu, May 7, 2009 at 12:03 AM, Adam Barth wrote:
> On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman wrote:
>> What about a setup where the content rendered in the tab area is
>> running on chrome://, but contains a frame that hosts the actual feed
>> running on http://foo.com?
>
> Sure, we could
I see. That probably simplifies things. Hmm...
-Darin
On Wed, May 6, 2009 at 10:51 PM, Adam Barth wrote:
> I don't think we want these feed previews to run with foo.com's
> authority. I'd rather they ran with no one's authority.
>
> Adam
>
>
> On Wed, May 6, 2009 at 8:42 PM, Darin Fisher wr
chrome:// pages cannot load HTTP-based sub-resources. We don't want to
taint the processes that render Chrome UI.
-Darin
On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman wrote:
> Let's say the feed is http://foo.com/feed.xml
>
> What about a setup where the content rendered in the tab area is
>
Minor comment, but I assume you will be triggering the feed-preview
when people click on a link to the feed as well.
Many sites have an RSS link to the feed's XML file because it is
previewable in many browsers without autodiscovery.
Currently, Chrome shows unformated XML. Doing CTRL-U after shows
On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman wrote:
> What about a setup where the content rendered in the tab area is
> running on chrome://, but contains a frame that hosts the actual feed
> running on http://foo.com?
Sure, we could do that. Or even better is if the outer page is a
chrome-e
Let's say the feed is http://foo.com/feed.xml
What about a setup where the content rendered in the tab area is
running on chrome://, but contains a frame that hosts the actual feed
running on http://foo.com? The subscribe UI runs on the other page, so
it is the only thing that needs elevated priv
Regardless of whose authority they run at, it is somewhat desirable to
have the feed URL display in the address bar, since that's the content
that's being loaded.
I would like to keep the flow in page as much as possible. We should
be able to come up with some solution here that doesn't involve
e
On Wed, May 6, 2009 at 8:45 PM, Mike Beltzner wrote:
> FWIW, Firefox has had several security issues crop up with the mixed-content
> feed preview implementation. Placing privileged controls so close to web
> content should be avoided, IMO, if you want to keep this from being a
> problem for Chro
I don't think we want these feed previews to run with foo.com's
authority. I'd rather they ran with no one's authority.
Adam
On Wed, May 6, 2009 at 8:42 PM, Darin Fisher wrote:
> WebKit does not support nested schemes. It would fail in so many places to
> recognize that the authority of such
On 6-May-09, at 9:56 PM, Adam Barth wrote:
> From a security point of view, we'd ideally like to render feeds with
> JavaScript and plug-ins disabled, as well as in a noAccess
> SecurityOrigin. This is easier if the feed preview lives in its own
> scheme. I'm happy to help out with the security
WebKit does not support nested schemes. It would fail in so many places to
recognize that the authority of such an URL is actually foo.com.
(However, we could perhaps support this as we do view-source, where WebKit
never actually sees the view-source URL.)
-Darin
On Wed, May 6, 2009 at 6:56 PM,
I think Darin had some strong opinions about whether we should do
nested schemes like feed-view:http://foo.com/bar.
>From a security point of view, we'd ideally like to render feeds with
JavaScript and plug-ins disabled, as well as in a noAccess
SecurityOrigin. This is easier if the feed preview
On Wed, May 6, 2009 at 6:13 PM, Evan Martin wrote:
> - 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 h
Why bother with view-feed://? Why not just have the feed be styled
more nicely, similar to the way that XML is styled more nicely by
default in most browsers?
- a
On Wed, May 6, 2009 at 6:13 PM, Evan Martin wrote:
>
> On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson
> wrote:
>> I have alre
On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson 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 pr
The way that makes most sense to me to implement this in the
extensions system is:
a) In C++ use content sniffing to make sure that the content type is
always correct for feeds
b) Add a feature to content scripts in extensions, so that they can
match by content type
c) Have a content script that
16 matches
Mail list logo
