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