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
