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 <[email protected]>

> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy <[email protected]> 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: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev

Reply via email to