Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
True, there really is no need for it to be synchronous. 2010/1/10 Peter Kasting > On Sun, Jan 10, 2010 at 7:15 AM, Pierre-Antoine LaFayette < > pierre.lafaye...@gmail.com> wrote: > >> Is it illegal for the WebKit glue layer to send synchronous messages to >> the browser requesting the icon data URI? > > > I don't know, but in general sync messages suck. Why couldn't you use an > async message and just show the icon once it arrives? > > PK > -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Sun, Jan 10, 2010 at 7:15 AM, Pierre-Antoine LaFayette < pierre.lafaye...@gmail.com> wrote: > Is it illegal for the WebKit glue layer to send synchronous messages to the > browser requesting the icon data URI? I don't know, but in general sync messages suck. Why couldn't you use an async message and just show the icon once it arrives? PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Is it illegal for the WebKit glue layer to send synchronous messages to the
browser requesting the icon data URI?
2010/1/7 Darin Fisher
> It could... but, I though the conclusion was to avoid DOM UI for file://
> and ftp:// directory listings (for other reasons). In that case, we
> should be able to continue using the same UI. I think there is just the
> open question of how to provide icon resources to the page.
>
> -Darin
>
>
> On Thu, Jan 7, 2010 at 4:11 AM, Dean McNamee wrote:
>
>> Yeah, so my question was, does that mean test_shell would have a
>> separate mechanism (the current one?) for file:/// listings?
>>
>> On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher wrote:
>> > DOM UI implies chrome://, which is implemented by the
>> ChromeURLDataManager
>> > (in browser/dom_ui/). TestShell wouldn't be able to use that.
>> > -Darin
>> >
>> > On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee
>> wrote:
>> >>
>> >> I am pretty out of things these days, but will a DOM UI file://
>> >> listing work for test_shell?
>> >>
>> >> On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher
>> wrote:
>> >> > Right, that's the tricky part. You'd need to do something creative.
>> >> > -Darin
>> >> >
>> >> > On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette
>> >> > wrote:
>> >> >>
>> >> >> Okay. Yes we could use data URI, but where do we retrieve the icon
>> >> >> resources from at that level?
>> >> >>
>> >> >> 2010/1/6 Darin Fisher
>> >> >>>
>> >> >>> We can also use data: URLs to inject the icons into the HTML file
>> used
>> >> >>> to
>> >> >>> render the directory listings. We can do that at the time when the
>> >> >>> HTML
>> >> >>> file is generated.
>> >> >>> -Darin
>> >> >>>
>> >> >>>
>> >> >>> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin
>> wrote:
>> >>
>> >> I talked with Arv in person and I think I sufficiently convinced
>> him
>> >> that getting DOMUI security right is tricky. (Consider: XSSes in
>> the
>> >> FTP display code, and that ftp sites containing HTML pages must
>> not
>> >> have privs when displaying the HTML.) That may still mean that
>> DOMUI
>> >> is ok, but I would prefer to consider any other option available.
>> >>
>> >> One idea is to say "we don't care if any old page can > >> src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
>> >> Not sure.
>> >>
>> >> On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson
>> >> wrote:
>> >> > I think it should be OK to move these to DOMUI. NTP can also
>> link
>> >> > to
>> >> > local HTML files and we already mark the chrome protocol in such
>> a
>> >> > way
>> >> > that it cannot be accessed by any other scheme.
>> >> >
>> >> > erik
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
>> >> > wrote:
>> >> >> That's why I wanted to check before starting any work. So the
>> >> >> question is
>> >> >> now whether it we'd rather use a DOM UI page or create a
>> similar
>> >> >> API
>> >> >> that
>> >> >> would be used solely by file:// and ftp://. What is needed for
>> >> >> http://crbug.com/24421 is simply access to the favicon data
>> for
>> >> >> file
>> >> >> types.
>> >> >> I'm not sure if these are available through WebCore or not. The
>> >> >> drag
>> >> >> and
>> >> >> drop functionality required by http://crbug.com/27772 seems
>> like
>> >> >> it
>> >> >> would be
>> >> >> a lot of work without using a DOM UI page.
>> >> >> Any opinions on this part of my original post?:
>> >> >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui
>> >> >> page
>> >> >> couldn't
>> >> >> be generalized to
>> >> >> be used for these other directory listing pages?
>> >> >> It just seems to me that it would be rather redundant handle 3
>> >> >> separate
>> >> >> instances of a file browse HTML page (ftp://, file:// and
>> >> >> chrome://filebrowse) in 3 separate ways.
>> >> >> Thanks.
>> >> >> 2010/1/5 Evan Martin
>> >> >>>
>> >> >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy <
>> g...@chromium.org>
>> >> >>> wrote:
>> >> >>> > I don't think anyone has any objection to DOMUIifying those
>> >> >>> > pages,
>> >> >>> > and
>> >> >>> > I don't think it would be a large amount of work. The only
>> >> >>> > reason
>> >> >>> > they're not is that there hasn't been a reason to do so.
>> >> >>>
>> >> >>> DOM UI (at least when I last looked) just means that that
>> >> >>> renderer
>> >> >>> ("the page") gets extra privileges necessary for doing special
>> >> >>> browser
>> >> >>> calls, such as access to your browsing history for the History
>> >> >>> implementation.
>> >> >>>
>> >> >>> We went to some effort to keep these sorts of pages distinct
>> from
>> >> >>> ne
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
It could... but, I though the conclusion was to avoid DOM UI for file:// and
ftp:// directory listings (for other reasons). In that case, we should be
able to continue using the same UI. I think there is just the open question
of how to provide icon resources to the page.
-Darin
On Thu, Jan 7, 2010 at 4:11 AM, Dean McNamee wrote:
> Yeah, so my question was, does that mean test_shell would have a
> separate mechanism (the current one?) for file:/// listings?
>
> On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher wrote:
> > DOM UI implies chrome://, which is implemented by the
> ChromeURLDataManager
> > (in browser/dom_ui/). TestShell wouldn't be able to use that.
> > -Darin
> >
> > On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee wrote:
> >>
> >> I am pretty out of things these days, but will a DOM UI file://
> >> listing work for test_shell?
> >>
> >> On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher
> wrote:
> >> > Right, that's the tricky part. You'd need to do something creative.
> >> > -Darin
> >> >
> >> > On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette
> >> > wrote:
> >> >>
> >> >> Okay. Yes we could use data URI, but where do we retrieve the icon
> >> >> resources from at that level?
> >> >>
> >> >> 2010/1/6 Darin Fisher
> >> >>>
> >> >>> We can also use data: URLs to inject the icons into the HTML file
> used
> >> >>> to
> >> >>> render the directory listings. We can do that at the time when the
> >> >>> HTML
> >> >>> file is generated.
> >> >>> -Darin
> >> >>>
> >> >>>
> >> >>> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin
> wrote:
> >>
> >> I talked with Arv in person and I think I sufficiently convinced
> him
> >> that getting DOMUI security right is tricky. (Consider: XSSes in
> the
> >> FTP display code, and that ftp sites containing HTML pages must not
> >> have privs when displaying the HTML.) That may still mean that
> DOMUI
> >> is ok, but I would prefer to consider any other option available.
> >>
> >> One idea is to say "we don't care if any old page can >> src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
> >> Not sure.
> >>
> >> On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson
> >> wrote:
> >> > I think it should be OK to move these to DOMUI. NTP can also link
> >> > to
> >> > local HTML files and we already mark the chrome protocol in such
> a
> >> > way
> >> > that it cannot be accessed by any other scheme.
> >> >
> >> > erik
> >> >
> >> >
> >> >
> >> > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
> >> > wrote:
> >> >> That's why I wanted to check before starting any work. So the
> >> >> question is
> >> >> now whether it we'd rather use a DOM UI page or create a similar
> >> >> API
> >> >> that
> >> >> would be used solely by file:// and ftp://. What is needed for
> >> >> http://crbug.com/24421 is simply access to the favicon data for
> >> >> file
> >> >> types.
> >> >> I'm not sure if these are available through WebCore or not. The
> >> >> drag
> >> >> and
> >> >> drop functionality required by http://crbug.com/27772 seems
> like
> >> >> it
> >> >> would be
> >> >> a lot of work without using a DOM UI page.
> >> >> Any opinions on this part of my original post?:
> >> >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui
> >> >> page
> >> >> couldn't
> >> >> be generalized to
> >> >> be used for these other directory listing pages?
> >> >> It just seems to me that it would be rather redundant handle 3
> >> >> separate
> >> >> instances of a file browse HTML page (ftp://, file:// and
> >> >> chrome://filebrowse) in 3 separate ways.
> >> >> Thanks.
> >> >> 2010/1/5 Evan Martin
> >> >>>
> >> >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy >
> >> >>> wrote:
> >> >>> > I don't think anyone has any objection to DOMUIifying those
> >> >>> > pages,
> >> >>> > and
> >> >>> > I don't think it would be a large amount of work. The only
> >> >>> > reason
> >> >>> > they're not is that there hasn't been a reason to do so.
> >> >>>
> >> >>> DOM UI (at least when I last looked) just means that that
> >> >>> renderer
> >> >>> ("the page") gets extra privileges necessary for doing special
> >> >>> browser
> >> >>> calls, such as access to your browsing history for the History
> >> >>> implementation.
> >> >>>
> >> >>> We went to some effort to keep these sorts of pages distinct
> from
> >> >>> network content with the hope of reducing the security surface.
> >> >>> I
> >> >>> worry changing this for FTP would be going in the wrong
> >> >>> direction.
> >> >>>
> >> >>> It might make more sense to do something *like* DOM UI but with
> a
> >> >>> different API just to k
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Yeah, so my question was, does that mean test_shell would have a
separate mechanism (the current one?) for file:/// listings?
On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher wrote:
> DOM UI implies chrome://, which is implemented by the ChromeURLDataManager
> (in browser/dom_ui/). TestShell wouldn't be able to use that.
> -Darin
>
> On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee wrote:
>>
>> I am pretty out of things these days, but will a DOM UI file://
>> listing work for test_shell?
>>
>> On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher wrote:
>> > Right, that's the tricky part. You'd need to do something creative.
>> > -Darin
>> >
>> > On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette
>> > wrote:
>> >>
>> >> Okay. Yes we could use data URI, but where do we retrieve the icon
>> >> resources from at that level?
>> >>
>> >> 2010/1/6 Darin Fisher
>> >>>
>> >>> We can also use data: URLs to inject the icons into the HTML file used
>> >>> to
>> >>> render the directory listings. We can do that at the time when the
>> >>> HTML
>> >>> file is generated.
>> >>> -Darin
>> >>>
>> >>>
>> >>> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin wrote:
>>
>> I talked with Arv in person and I think I sufficiently convinced him
>> that getting DOMUI security right is tricky. (Consider: XSSes in the
>> FTP display code, and that ftp sites containing HTML pages must not
>> have privs when displaying the HTML.) That may still mean that DOMUI
>> is ok, but I would prefer to consider any other option available.
>>
>> One idea is to say "we don't care if any old page can > src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
>> Not sure.
>>
>> On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson
>> wrote:
>> > I think it should be OK to move these to DOMUI. NTP can also link
>> > to
>> > local HTML files and we already mark the chrome protocol in such a
>> > way
>> > that it cannot be accessed by any other scheme.
>> >
>> > erik
>> >
>> >
>> >
>> > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
>> > wrote:
>> >> That's why I wanted to check before starting any work. So the
>> >> question is
>> >> now whether it we'd rather use a DOM UI page or create a similar
>> >> API
>> >> that
>> >> would be used solely by file:// and ftp://. What is needed for
>> >> http://crbug.com/24421 is simply access to the favicon data for
>> >> file
>> >> types.
>> >> I'm not sure if these are available through WebCore or not. The
>> >> drag
>> >> and
>> >> drop functionality required by http://crbug.com/27772 seems like
>> >> it
>> >> would be
>> >> a lot of work without using a DOM UI page.
>> >> Any opinions on this part of my original post?:
>> >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui
>> >> page
>> >> couldn't
>> >> be generalized to
>> >> be used for these other directory listing pages?
>> >> It just seems to me that it would be rather redundant handle 3
>> >> separate
>> >> instances of a file browse HTML page (ftp://, file:// and
>> >> chrome://filebrowse) in 3 separate ways.
>> >> Thanks.
>> >> 2010/1/5 Evan Martin
>> >>>
>> >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy
>> >>> wrote:
>> >>> > I don't think anyone has any objection to DOMUIifying those
>> >>> > pages,
>> >>> > and
>> >>> > I don't think it would be a large amount of work. The only
>> >>> > reason
>> >>> > they're not is that there hasn't been a reason to do so.
>> >>>
>> >>> DOM UI (at least when I last looked) just means that that
>> >>> renderer
>> >>> ("the page") gets extra privileges necessary for doing special
>> >>> browser
>> >>> calls, such as access to your browsing history for the History
>> >>> implementation.
>> >>>
>> >>> We went to some effort to keep these sorts of pages distinct from
>> >>> network content with the hope of reducing the security surface.
>> >>> I
>> >>> worry changing this for FTP would be going in the wrong
>> >>> direction.
>> >>>
>> >>> It might make more sense to do something *like* DOM UI but with a
>> >>> different API just to keep things distinct. But then we
>> >>> reencounter
>> >>> the same sorts of problems we have with DOM UI, like for example
>> >>> if
>> >>> you click a link from an FTP site to an HTML file, how to prevent
>> >>> the
>> >>> FTP privileges from bleeding into the HTML file.
>> >>>
>> >>> I feel like Darin is the person who would best know how to
>> >>> address
>> >>> this.
>> >>> :)
>> >>
>> >>
>> >>
>> >> --
>> >> Pierre.
>> >>
>> >> --
>> >> Chromium Developers mailing list: chromium
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
DOM UI implies chrome://, which is implemented by the ChromeURLDataManager
(in browser/dom_ui/). TestShell wouldn't be able to use that.
-Darin
On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee wrote:
> I am pretty out of things these days, but will a DOM UI file://
> listing work for test_shell?
>
> On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher wrote:
> > Right, that's the tricky part. You'd need to do something creative.
> > -Darin
> >
> > On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette
> > wrote:
> >>
> >> Okay. Yes we could use data URI, but where do we retrieve the icon
> >> resources from at that level?
> >>
> >> 2010/1/6 Darin Fisher
> >>>
> >>> We can also use data: URLs to inject the icons into the HTML file used
> to
> >>> render the directory listings. We can do that at the time when the
> HTML
> >>> file is generated.
> >>> -Darin
> >>>
> >>>
> >>> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin wrote:
>
> I talked with Arv in person and I think I sufficiently convinced him
> that getting DOMUI security right is tricky. (Consider: XSSes in the
> FTP display code, and that ftp sites containing HTML pages must not
> have privs when displaying the HTML.) That may still mean that DOMUI
> is ok, but I would prefer to consider any other option available.
>
> One idea is to say "we don't care if any old page can src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
> Not sure.
>
> On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson
> wrote:
> > I think it should be OK to move these to DOMUI. NTP can also link to
> > local HTML files and we already mark the chrome protocol in such a
> way
> > that it cannot be accessed by any other scheme.
> >
> > erik
> >
> >
> >
> > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
> > wrote:
> >> That's why I wanted to check before starting any work. So the
> >> question is
> >> now whether it we'd rather use a DOM UI page or create a similar
> API
> >> that
> >> would be used solely by file:// and ftp://. What is needed for
> >> http://crbug.com/24421 is simply access to the favicon data for
> file
> >> types.
> >> I'm not sure if these are available through WebCore or not. The
> drag
> >> and
> >> drop functionality required by http://crbug.com/27772 seems like
> it
> >> would be
> >> a lot of work without using a DOM UI page.
> >> Any opinions on this part of my original post?:
> >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page
> >> couldn't
> >> be generalized to
> >> be used for these other directory listing pages?
> >> It just seems to me that it would be rather redundant handle 3
> >> separate
> >> instances of a file browse HTML page (ftp://, file:// and
> >> chrome://filebrowse) in 3 separate ways.
> >> Thanks.
> >> 2010/1/5 Evan Martin
> >>>
> >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy
> >>> wrote:
> >>> > I don't think anyone has any objection to DOMUIifying those
> pages,
> >>> > and
> >>> > I don't think it would be a large amount of work. The only
> reason
> >>> > they're not is that there hasn't been a reason to do so.
> >>>
> >>> DOM UI (at least when I last looked) just means that that renderer
> >>> ("the page") gets extra privileges necessary for doing special
> >>> browser
> >>> calls, such as access to your browsing history for the History
> >>> implementation.
> >>>
> >>> We went to some effort to keep these sorts of pages distinct from
> >>> network content with the hope of reducing the security surface. I
> >>> worry changing this for FTP would be going in the wrong direction.
> >>>
> >>> It might make more sense to do something *like* DOM UI but with a
> >>> different API just to keep things distinct. But then we
> reencounter
> >>> the same sorts of problems we have with DOM UI, like for example
> if
> >>> you click a link from an FTP site to an HTML file, how to prevent
> >>> the
> >>> FTP privileges from bleeding into the HTML file.
> >>>
> >>> I feel like Darin is the person who would best know how to address
> >>> this.
> >>> :)
> >>
> >>
> >>
> >> --
> >> Pierre.
> >>
> >> --
> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> View archives, change email options, or unsubscribe:
> >>http://groups.google.com/group/chromium-dev
> >>
> >
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Pierre.
> >
> >
> > --
> > Chromium Developers mailing list: chromiu
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I am pretty out of things these days, but will a DOM UI file://
listing work for test_shell?
On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher wrote:
> Right, that's the tricky part. You'd need to do something creative.
> -Darin
>
> On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette
> wrote:
>>
>> Okay. Yes we could use data URI, but where do we retrieve the icon
>> resources from at that level?
>>
>> 2010/1/6 Darin Fisher
>>>
>>> We can also use data: URLs to inject the icons into the HTML file used to
>>> render the directory listings. We can do that at the time when the HTML
>>> file is generated.
>>> -Darin
>>>
>>>
>>> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin wrote:
I talked with Arv in person and I think I sufficiently convinced him
that getting DOMUI security right is tricky. (Consider: XSSes in the
FTP display code, and that ftp sites containing HTML pages must not
have privs when displaying the HTML.) That may still mean that DOMUI
is ok, but I would prefer to consider any other option available.
One idea is to say "we don't care if any old page can >>> src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
Not sure.
On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson wrote:
> I think it should be OK to move these to DOMUI. NTP can also link to
> local HTML files and we already mark the chrome protocol in such a way
> that it cannot be accessed by any other scheme.
>
> erik
>
>
>
> On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
> wrote:
>> That's why I wanted to check before starting any work. So the
>> question is
>> now whether it we'd rather use a DOM UI page or create a similar API
>> that
>> would be used solely by file:// and ftp://. What is needed for
>> http://crbug.com/24421 is simply access to the favicon data for file
>> types.
>> I'm not sure if these are available through WebCore or not. The drag
>> and
>> drop functionality required by http://crbug.com/27772 seems like it
>> would be
>> a lot of work without using a DOM UI page.
>> Any opinions on this part of my original post?:
>> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page
>> couldn't
>> be generalized to
>> be used for these other directory listing pages?
>> It just seems to me that it would be rather redundant handle 3
>> separate
>> instances of a file browse HTML page (ftp://, file:// and
>> chrome://filebrowse) in 3 separate ways.
>> Thanks.
>> 2010/1/5 Evan Martin
>>>
>>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy
>>> wrote:
>>> > I don't think anyone has any objection to DOMUIifying those pages,
>>> > and
>>> > I don't think it would be a large amount of work. The only reason
>>> > they're not is that there hasn't been a reason to do so.
>>>
>>> DOM UI (at least when I last looked) just means that that renderer
>>> ("the page") gets extra privileges necessary for doing special
>>> browser
>>> calls, such as access to your browsing history for the History
>>> implementation.
>>>
>>> We went to some effort to keep these sorts of pages distinct from
>>> network content with the hope of reducing the security surface. I
>>> worry changing this for FTP would be going in the wrong direction.
>>>
>>> It might make more sense to do something *like* DOM UI but with a
>>> different API just to keep things distinct. But then we reencounter
>>> the same sorts of problems we have with DOM UI, like for example if
>>> you click a link from an FTP site to an HTML file, how to prevent
>>> the
>>> FTP privileges from bleeding into the HTML file.
>>>
>>> I feel like Darin is the person who would best know how to address
>>> this.
>>> :)
>>
>>
>>
>> --
>> Pierre.
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
>>>
>>
>>
>>
>> --
>> Pierre.
>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Right, that's the tricky part. You'd need to do something creative.
-Darin
On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette <
pierre.lafaye...@gmail.com> wrote:
> Okay. Yes we could use data URI, but where do we retrieve the icon
> resources from at that level?
>
> 2010/1/6 Darin Fisher
>
> We can also use data: URLs to inject the icons into the HTML file used to
>> render the directory listings. We can do that at the time when the HTML
>> file is generated.
>>
>> -Darin
>>
>>
>> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin wrote:
>>
>>> I talked with Arv in person and I think I sufficiently convinced him
>>> that getting DOMUI security right is tricky. (Consider: XSSes in the
>>> FTP display code, and that ftp sites containing HTML pages must not
>>> have privs when displaying the HTML.) That may still mean that DOMUI
>>> is ok, but I would prefer to consider any other option available.
>>>
>>> One idea is to say "we don't care if any old page can >> src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
>>> Not sure.
>>>
>>> On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson wrote:
>>> > I think it should be OK to move these to DOMUI. NTP can also link to
>>> > local HTML files and we already mark the chrome protocol in such a way
>>> > that it cannot be accessed by any other scheme.
>>> >
>>> > erik
>>> >
>>> >
>>> >
>>> > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
>>> > wrote:
>>> >> That's why I wanted to check before starting any work. So the question
>>> is
>>> >> now whether it we'd rather use a DOM UI page or create a similar API
>>> that
>>> >> would be used solely by file:// and ftp://. What is needed for
>>> >> http://crbug.com/24421 is simply access to the favicon data for file
>>> types.
>>> >> I'm not sure if these are available through WebCore or not. The drag
>>> and
>>> >> drop functionality required by http://crbug.com/27772 seems like it
>>> would be
>>> >> a lot of work without using a DOM UI page.
>>> >> Any opinions on this part of my original post?:
>>> >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page
>>> couldn't
>>> >> be generalized to
>>> >> be used for these other directory listing pages?
>>> >> It just seems to me that it would be rather redundant handle 3
>>> separate
>>> >> instances of a file browse HTML page (ftp://, file:// and
>>> >> chrome://filebrowse) in 3 separate ways.
>>> >> Thanks.
>>> >> 2010/1/5 Evan Martin
>>> >>>
>>> >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy
>>> wrote:
>>> >>> > I don't think anyone has any objection to DOMUIifying those pages,
>>> and
>>> >>> > I don't think it would be a large amount of work. The only reason
>>> >>> > they're not is that there hasn't been a reason to do so.
>>> >>>
>>> >>> DOM UI (at least when I last looked) just means that that renderer
>>> >>> ("the page") gets extra privileges necessary for doing special
>>> browser
>>> >>> calls, such as access to your browsing history for the History
>>> >>> implementation.
>>> >>>
>>> >>> We went to some effort to keep these sorts of pages distinct from
>>> >>> network content with the hope of reducing the security surface. I
>>> >>> worry changing this for FTP would be going in the wrong direction.
>>> >>>
>>> >>> It might make more sense to do something *like* DOM UI but with a
>>> >>> different API just to keep things distinct. But then we reencounter
>>> >>> the same sorts of problems we have with DOM UI, like for example if
>>> >>> you click a link from an FTP site to an HTML file, how to prevent the
>>> >>> FTP privileges from bleeding into the HTML file.
>>> >>>
>>> >>> I feel like Darin is the person who would best know how to address
>>> this.
>>> >>> :)
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Pierre.
>>> >>
>>> >> --
>>> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> >> View archives, change email options, or unsubscribe:
>>> >>http://groups.google.com/group/chromium-dev
>>> >>
>>> >
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>>http://groups.google.com/group/chromium-dev
>>>
>>
>>
>
>
> --
> Pierre.
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Okay. Yes we could use data URI, but where do we retrieve the icon resources
from at that level?
2010/1/6 Darin Fisher
> We can also use data: URLs to inject the icons into the HTML file used to
> render the directory listings. We can do that at the time when the HTML
> file is generated.
>
> -Darin
>
>
> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin wrote:
>
>> I talked with Arv in person and I think I sufficiently convinced him
>> that getting DOMUI security right is tricky. (Consider: XSSes in the
>> FTP display code, and that ftp sites containing HTML pages must not
>> have privs when displaying the HTML.) That may still mean that DOMUI
>> is ok, but I would prefer to consider any other option available.
>>
>> One idea is to say "we don't care if any old page can > src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
>> Not sure.
>>
>> On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson wrote:
>> > I think it should be OK to move these to DOMUI. NTP can also link to
>> > local HTML files and we already mark the chrome protocol in such a way
>> > that it cannot be accessed by any other scheme.
>> >
>> > erik
>> >
>> >
>> >
>> > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
>> > wrote:
>> >> That's why I wanted to check before starting any work. So the question
>> is
>> >> now whether it we'd rather use a DOM UI page or create a similar API
>> that
>> >> would be used solely by file:// and ftp://. What is needed for
>> >> http://crbug.com/24421 is simply access to the favicon data for file
>> types.
>> >> I'm not sure if these are available through WebCore or not. The drag
>> and
>> >> drop functionality required by http://crbug.com/27772 seems like it
>> would be
>> >> a lot of work without using a DOM UI page.
>> >> Any opinions on this part of my original post?:
>> >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page
>> couldn't
>> >> be generalized to
>> >> be used for these other directory listing pages?
>> >> It just seems to me that it would be rather redundant handle 3 separate
>> >> instances of a file browse HTML page (ftp://, file:// and
>> >> chrome://filebrowse) in 3 separate ways.
>> >> Thanks.
>> >> 2010/1/5 Evan Martin
>> >>>
>> >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy
>> wrote:
>> >>> > I don't think anyone has any objection to DOMUIifying those pages,
>> and
>> >>> > I don't think it would be a large amount of work. The only reason
>> >>> > they're not is that there hasn't been a reason to do so.
>> >>>
>> >>> DOM UI (at least when I last looked) just means that that renderer
>> >>> ("the page") gets extra privileges necessary for doing special browser
>> >>> calls, such as access to your browsing history for the History
>> >>> implementation.
>> >>>
>> >>> We went to some effort to keep these sorts of pages distinct from
>> >>> network content with the hope of reducing the security surface. I
>> >>> worry changing this for FTP would be going in the wrong direction.
>> >>>
>> >>> It might make more sense to do something *like* DOM UI but with a
>> >>> different API just to keep things distinct. But then we reencounter
>> >>> the same sorts of problems we have with DOM UI, like for example if
>> >>> you click a link from an FTP site to an HTML file, how to prevent the
>> >>> FTP privileges from bleeding into the HTML file.
>> >>>
>> >>> I feel like Darin is the person who would best know how to address
>> this.
>> >>> :)
>> >>
>> >>
>> >>
>> >> --
>> >> Pierre.
>> >>
>> >> --
>> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> >> View archives, change email options, or unsubscribe:
>> >>http://groups.google.com/group/chromium-dev
>> >>
>> >
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
--
Pierre.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
We can also use data: URLs to inject the icons into the HTML file used to
render the directory listings. We can do that at the time when the HTML
file is generated.
-Darin
On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin wrote:
> I talked with Arv in person and I think I sufficiently convinced him
> that getting DOMUI security right is tricky. (Consider: XSSes in the
> FTP display code, and that ftp sites containing HTML pages must not
> have privs when displaying the HTML.) That may still mean that DOMUI
> is ok, but I would prefer to consider any other option available.
>
> One idea is to say "we don't care if any old page can src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
> Not sure.
>
> On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson wrote:
> > I think it should be OK to move these to DOMUI. NTP can also link to
> > local HTML files and we already mark the chrome protocol in such a way
> > that it cannot be accessed by any other scheme.
> >
> > erik
> >
> >
> >
> > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
> > wrote:
> >> That's why I wanted to check before starting any work. So the question
> is
> >> now whether it we'd rather use a DOM UI page or create a similar API
> that
> >> would be used solely by file:// and ftp://. What is needed for
> >> http://crbug.com/24421 is simply access to the favicon data for file
> types.
> >> I'm not sure if these are available through WebCore or not. The drag and
> >> drop functionality required by http://crbug.com/27772 seems like it
> would be
> >> a lot of work without using a DOM UI page.
> >> Any opinions on this part of my original post?:
> >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page
> couldn't
> >> be generalized to
> >> be used for these other directory listing pages?
> >> It just seems to me that it would be rather redundant handle 3 separate
> >> instances of a file browse HTML page (ftp://, file:// and
> >> chrome://filebrowse) in 3 separate ways.
> >> Thanks.
> >> 2010/1/5 Evan Martin
> >>>
> >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy wrote:
> >>> > I don't think anyone has any objection to DOMUIifying those pages,
> and
> >>> > I don't think it would be a large amount of work. The only reason
> >>> > they're not is that there hasn't been a reason to do so.
> >>>
> >>> DOM UI (at least when I last looked) just means that that renderer
> >>> ("the page") gets extra privileges necessary for doing special browser
> >>> calls, such as access to your browsing history for the History
> >>> implementation.
> >>>
> >>> We went to some effort to keep these sorts of pages distinct from
> >>> network content with the hope of reducing the security surface. I
> >>> worry changing this for FTP would be going in the wrong direction.
> >>>
> >>> It might make more sense to do something *like* DOM UI but with a
> >>> different API just to keep things distinct. But then we reencounter
> >>> the same sorts of problems we have with DOM UI, like for example if
> >>> you click a link from an FTP site to an HTML file, how to prevent the
> >>> FTP privileges from bleeding into the HTML file.
> >>>
> >>> I feel like Darin is the person who would best know how to address
> this.
> >>> :)
> >>
> >>
> >>
> >> --
> >> Pierre.
> >>
> >> --
> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> View archives, change email options, or unsubscribe:
> >>http://groups.google.com/group/chromium-dev
> >>
> >
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Tue, Jan 5, 2010 at 2:50 PM, Evan Martin wrote:
> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy wrote:
> > I don't think anyone has any objection to DOMUIifying those pages, and
> > I don't think it would be a large amount of work. The only reason
> > they're not is that there hasn't been a reason to do so.
>
> DOM UI (at least when I last looked) just means that that renderer
> ("the page") gets extra privileges necessary for doing special browser
> calls, such as access to your browsing history for the History
> implementation.
>
> We went to some effort to keep these sorts of pages distinct from
> network content with the hope of reducing the security surface. I
> worry changing this for FTP would be going in the wrong direction.
>
Yes, exactly. Remember that ftp:// directories can be loaded in iframes by
web content. We don't want to grant any extra privileges to renderer
processes that display ftp:// content b/c those privileges could leak to
other content loaded by the same renderer if cross-site-scripting exploit
happens to exist.
I think there's a good opportunity to spiff up the directory listing
template to be nicer, but I think we have to avoid changing these directory
listings over to DOMUI.
-Darin
>
> It might make more sense to do something *like* DOM UI but with a
> different API just to keep things distinct. But then we reencounter
> the same sorts of problems we have with DOM UI, like for example if
> you click a link from an FTP site to an HTML file, how to prevent the
> FTP privileges from bleeding into the HTML file.
>
> I feel like Darin is the person who would best know how to address this.
> :)
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Tue, Jan 5, 2010 at 5:34 PM, Adam Barth wrote:
> Instead of DOMUI, why not use an extension to display the directory
> listing? You can put the icons in the CRX.
>
this would drastically inflate the size of the extension and wouldn't match
the system icon theme
>
> Adam
>
>
> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin wrote:
> > I talked with Arv in person and I think I sufficiently convinced him
> > that getting DOMUI security right is tricky. (Consider: XSSes in the
> > FTP display code, and that ftp sites containing HTML pages must not
> > have privs when displaying the HTML.) That may still mean that DOMUI
> > is ok, but I would prefer to consider any other option available.
> >
> > One idea is to say "we don't care if any old page can > src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
> > Not sure.
> >
> > On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson wrote:
> >> I think it should be OK to move these to DOMUI. NTP can also link to
> >> local HTML files and we already mark the chrome protocol in such a way
> >> that it cannot be accessed by any other scheme.
> >>
> >> erik
> >>
> >>
> >>
> >> On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
> >> wrote:
> >>> That's why I wanted to check before starting any work. So the question
> is
> >>> now whether it we'd rather use a DOM UI page or create a similar API
> that
> >>> would be used solely by file:// and ftp://. What is needed for
> >>> http://crbug.com/24421 is simply access to the favicon data for file
> types.
> >>> I'm not sure if these are available through WebCore or not. The drag
> and
> >>> drop functionality required by http://crbug.com/27772 seems like it
> would be
> >>> a lot of work without using a DOM UI page.
> >>> Any opinions on this part of my original post?:
> >>> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page
> couldn't
> >>> be generalized to
> >>> be used for these other directory listing pages?
> >>> It just seems to me that it would be rather redundant handle 3 separate
> >>> instances of a file browse HTML page (ftp://, file:// and
> >>> chrome://filebrowse) in 3 separate ways.
> >>> Thanks.
> >>> 2010/1/5 Evan Martin
>
> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy
> wrote:
> > I don't think anyone has any objection to DOMUIifying those pages,
> and
> > I don't think it would be a large amount of work. The only reason
> > they're not is that there hasn't been a reason to do so.
>
> DOM UI (at least when I last looked) just means that that renderer
> ("the page") gets extra privileges necessary for doing special browser
> calls, such as access to your browsing history for the History
> implementation.
>
> We went to some effort to keep these sorts of pages distinct from
> network content with the hope of reducing the security surface. I
> worry changing this for FTP would be going in the wrong direction.
>
> It might make more sense to do something *like* DOM UI but with a
> different API just to keep things distinct. But then we reencounter
> the same sorts of problems we have with DOM UI, like for example if
> you click a link from an FTP site to an HTML file, how to prevent the
> FTP privileges from bleeding into the HTML file.
>
> I feel like Darin is the person who would best know how to address
> this.
> :)
> >>>
> >>>
> >>>
> >>> --
> >>> Pierre.
> >>>
> >>> --
> >>> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >>> View archives, change email options, or unsubscribe:
> >>>http://groups.google.com/group/chromium-dev
> >>>
> >>
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> >http://groups.google.com/group/chromium-dev
> >
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Instead of DOMUI, why not use an extension to display the directory
listing? You can put the icons in the CRX.
Adam
On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin wrote:
> I talked with Arv in person and I think I sufficiently convinced him
> that getting DOMUI security right is tricky. (Consider: XSSes in the
> FTP display code, and that ftp sites containing HTML pages must not
> have privs when displaying the HTML.) That may still mean that DOMUI
> is ok, but I would prefer to consider any other option available.
>
> One idea is to say "we don't care if any old page can src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
> Not sure.
>
> On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson wrote:
>> I think it should be OK to move these to DOMUI. NTP can also link to
>> local HTML files and we already mark the chrome protocol in such a way
>> that it cannot be accessed by any other scheme.
>>
>> erik
>>
>>
>>
>> On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
>> wrote:
>>> That's why I wanted to check before starting any work. So the question is
>>> now whether it we'd rather use a DOM UI page or create a similar API that
>>> would be used solely by file:// and ftp://. What is needed for
>>> http://crbug.com/24421 is simply access to the favicon data for file types.
>>> I'm not sure if these are available through WebCore or not. The drag and
>>> drop functionality required by http://crbug.com/27772 seems like it would be
>>> a lot of work without using a DOM UI page.
>>> Any opinions on this part of my original post?:
>>> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't
>>> be generalized to
>>> be used for these other directory listing pages?
>>> It just seems to me that it would be rather redundant handle 3 separate
>>> instances of a file browse HTML page (ftp://, file:// and
>>> chrome://filebrowse) in 3 separate ways.
>>> Thanks.
>>> 2010/1/5 Evan Martin
On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy wrote:
> I don't think anyone has any objection to DOMUIifying those pages, and
> I don't think it would be a large amount of work. The only reason
> they're not is that there hasn't been a reason to do so.
DOM UI (at least when I last looked) just means that that renderer
("the page") gets extra privileges necessary for doing special browser
calls, such as access to your browsing history for the History
implementation.
We went to some effort to keep these sorts of pages distinct from
network content with the hope of reducing the security surface. I
worry changing this for FTP would be going in the wrong direction.
It might make more sense to do something *like* DOM UI but with a
different API just to keep things distinct. But then we reencounter
the same sorts of problems we have with DOM UI, like for example if
you click a link from an FTP site to an HTML file, how to prevent the
FTP privileges from bleeding into the HTML file.
I feel like Darin is the person who would best know how to address this.
:)
>>>
>>>
>>>
>>> --
>>> Pierre.
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I talked with Arv in person and I think I sufficiently convinced him
that getting DOMUI security right is tricky. (Consider: XSSes in the
FTP display code, and that ftp sites containing HTML pages must not
have privs when displaying the HTML.) That may still mean that DOMUI
is ok, but I would prefer to consider any other option available.
One idea is to say "we don't care if any old page can " to get a Photoshop icon.
Not sure.
On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson wrote:
> I think it should be OK to move these to DOMUI. NTP can also link to
> local HTML files and we already mark the chrome protocol in such a way
> that it cannot be accessed by any other scheme.
>
> erik
>
>
>
> On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
> wrote:
>> That's why I wanted to check before starting any work. So the question is
>> now whether it we'd rather use a DOM UI page or create a similar API that
>> would be used solely by file:// and ftp://. What is needed for
>> http://crbug.com/24421 is simply access to the favicon data for file types.
>> I'm not sure if these are available through WebCore or not. The drag and
>> drop functionality required by http://crbug.com/27772 seems like it would be
>> a lot of work without using a DOM UI page.
>> Any opinions on this part of my original post?:
>> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't
>> be generalized to
>> be used for these other directory listing pages?
>> It just seems to me that it would be rather redundant handle 3 separate
>> instances of a file browse HTML page (ftp://, file:// and
>> chrome://filebrowse) in 3 separate ways.
>> Thanks.
>> 2010/1/5 Evan Martin
>>>
>>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy wrote:
>>> > I don't think anyone has any objection to DOMUIifying those pages, and
>>> > I don't think it would be a large amount of work. The only reason
>>> > they're not is that there hasn't been a reason to do so.
>>>
>>> DOM UI (at least when I last looked) just means that that renderer
>>> ("the page") gets extra privileges necessary for doing special browser
>>> calls, such as access to your browsing history for the History
>>> implementation.
>>>
>>> We went to some effort to keep these sorts of pages distinct from
>>> network content with the hope of reducing the security surface. I
>>> worry changing this for FTP would be going in the wrong direction.
>>>
>>> It might make more sense to do something *like* DOM UI but with a
>>> different API just to keep things distinct. But then we reencounter
>>> the same sorts of problems we have with DOM UI, like for example if
>>> you click a link from an FTP site to an HTML file, how to prevent the
>>> FTP privileges from bleeding into the HTML file.
>>>
>>> I feel like Darin is the person who would best know how to address this.
>>> :)
>>
>>
>>
>> --
>> Pierre.
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I think it should be OK to move these to DOMUI. NTP can also link to
local HTML files and we already mark the chrome protocol in such a way
that it cannot be accessed by any other scheme.
erik
On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
wrote:
> That's why I wanted to check before starting any work. So the question is
> now whether it we'd rather use a DOM UI page or create a similar API that
> would be used solely by file:// and ftp://. What is needed for
> http://crbug.com/24421 is simply access to the favicon data for file types.
> I'm not sure if these are available through WebCore or not. The drag and
> drop functionality required by http://crbug.com/27772 seems like it would be
> a lot of work without using a DOM UI page.
> Any opinions on this part of my original post?:
> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't
> be generalized to
> be used for these other directory listing pages?
> It just seems to me that it would be rather redundant handle 3 separate
> instances of a file browse HTML page (ftp://, file:// and
> chrome://filebrowse) in 3 separate ways.
> Thanks.
> 2010/1/5 Evan Martin
>>
>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy wrote:
>> > I don't think anyone has any objection to DOMUIifying those pages, and
>> > I don't think it would be a large amount of work. The only reason
>> > they're not is that there hasn't been a reason to do so.
>>
>> DOM UI (at least when I last looked) just means that that renderer
>> ("the page") gets extra privileges necessary for doing special browser
>> calls, such as access to your browsing history for the History
>> implementation.
>>
>> We went to some effort to keep these sorts of pages distinct from
>> network content with the hope of reducing the security surface. I
>> worry changing this for FTP would be going in the wrong direction.
>>
>> It might make more sense to do something *like* DOM UI but with a
>> different API just to keep things distinct. But then we reencounter
>> the same sorts of problems we have with DOM UI, like for example if
>> you click a link from an FTP site to an HTML file, how to prevent the
>> FTP privileges from bleeding into the HTML file.
>>
>> I feel like Darin is the person who would best know how to address this.
>> :)
>
>
>
> --
> Pierre.
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
That's why I wanted to check before starting any work. So the question is
now whether it we'd rather use a DOM UI page or create a similar API that
would be used solely by file:// and ftp://. What is needed for
http://crbug.com/24421 is simply access to the favicon data for file types.
I'm not sure if these are available through WebCore or not. The drag and
drop functionality required by http://crbug.com/27772 seems like it would be
a lot of work without using a DOM UI page.
Any opinions on this part of my original post?:
Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't
be generalized to
be used for these other directory listing pages?
It just seems to me that it would be rather redundant handle 3 separate
instances of a file browse HTML page (ftp://, file:// and
chrome://filebrowse) in 3 separate ways.
Thanks.
2010/1/5 Evan Martin
> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy wrote:
> > I don't think anyone has any objection to DOMUIifying those pages, and
> > I don't think it would be a large amount of work. The only reason
> > they're not is that there hasn't been a reason to do so.
>
> DOM UI (at least when I last looked) just means that that renderer
> ("the page") gets extra privileges necessary for doing special browser
> calls, such as access to your browsing history for the History
> implementation.
>
> We went to some effort to keep these sorts of pages distinct from
> network content with the hope of reducing the security surface. I
> worry changing this for FTP would be going in the wrong direction.
>
> It might make more sense to do something *like* DOM UI but with a
> different API just to keep things distinct. But then we reencounter
> the same sorts of problems we have with DOM UI, like for example if
> you click a link from an FTP site to an HTML file, how to prevent the
> FTP privileges from bleeding into the HTML file.
>
> I feel like Darin is the person who would best know how to address this.
> :)
>
--
Pierre.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy wrote:
> I don't think anyone has any objection to DOMUIifying those pages, and
> I don't think it would be a large amount of work. The only reason
> they're not is that there hasn't been a reason to do so.
DOM UI (at least when I last looked) just means that that renderer
("the page") gets extra privileges necessary for doing special browser
calls, such as access to your browsing history for the History
implementation.
We went to some effort to keep these sorts of pages distinct from
network content with the hope of reducing the security surface. I
worry changing this for FTP would be going in the wrong direction.
It might make more sense to do something *like* DOM UI but with a
different API just to keep things distinct. But then we reencounter
the same sorts of problems we have with DOM UI, like for example if
you click a link from an FTP site to an HTML file, how to prevent the
FTP privileges from bleeding into the HTML file.
I feel like Darin is the person who would best know how to address this. :)
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. On Tue, Jan 5, 2010 at 1:04 PM, Pierre-Antoine LaFayette wrote: > Apparently Google Groups doesn't add the [chromium-dev] in the subject line > when you post from the web app... > > 2010/1/1 plafayette >> >> http://crbug.com/24421 and http://crbug.com/27772 seem to hint that >> these directory listing pages would benefit from being handled at a >> higher level than the WebKit Glue Layer (or the net module in the case >> of file:///), namely as a DOM ui page. Is there any reason why >> ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to >> be used for these other directory listing pages? I haven't looked too >> deeply into what amount of work this would require. Is this a >> reasonable solution for these issues? >> >> Thanks, >> Pierre. > > > -- > Pierre. > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Apparently Google Groups doesn't add the [chromium-dev] in the subject line when you post from the web app... 2010/1/1 plafayette > http://crbug.com/24421 and http://crbug.com/27772 seem to hint that > these directory listing pages would benefit from being handled at a > higher level than the WebKit Glue Layer (or the net module in the case > of file:///), namely as a DOM ui page. Is there any reason why > ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to > be used for these other directory listing pages? I haven't looked too > deeply into what amount of work this would require. Is this a > reasonable solution for these issues? > > Thanks, > Pierre. -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
http://crbug.com/24421 and http://crbug.com/27772 seem to hint that these directory listing pages would benefit from being handled at a higher level than the WebKit Glue Layer (or the net module in the case of file:///), namely as a DOM ui page. Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? I haven't looked too deeply into what amount of work this would require. Is this a reasonable solution for these issues? Thanks, Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
