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