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 <[email protected]> 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 <[email protected]> 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 > > <[email protected]> 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 <[email protected]> > >>> > >>> 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 <[email protected]> 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 <img > >>>> 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 <[email protected]> > 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 > >>>> > <[email protected]> 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 <[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 > >>>> >> > >>>> > > >>>> > >>>> -- > >>>> Chromium Developers mailing list: [email protected] > >>>> View archives, change email options, or unsubscribe: > >>>> http://groups.google.com/group/chromium-dev > >>> > >> > >> > >> > >> -- > >> Pierre. > > > > > > -- > > Chromium Developers mailing list: [email protected] > > View archives, change email options, or unsubscribe: > > http://groups.google.com/group/chromium-dev > > >
-- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
