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 da...@chromium.org
It could... but, I though the conclusion was to avoid DOM UI for file://
and ftp:// directory listings (for other reasons). In that case,
On Sun, Jan 10, 2010 at 7:15 AM, Pierre-Antoine LaFayette
pierre.lafaye...@gmail.com wrote:
Is it illegal for the WebKit glue layer to send synchronous messages to the
browser requesting the icon data URI?
I don't know, but in general sync messages suck. Why couldn't you use an
async
True, there really is no need for it to be synchronous.
2010/1/10 Peter Kasting pkast...@google.com
On Sun, Jan 10, 2010 at 7:15 AM, Pierre-Antoine LaFayette
pierre.lafaye...@gmail.com wrote:
Is it illegal for the WebKit glue layer to send synchronous messages to
the browser requesting the
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 da...@chromium.org wrote:
DOM UI implies chrome://, which is implemented by the ChromeURLDataManager
(in browser/dom_ui/).
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
Okay. Yes we could use data URI, but where do we retrieve the icon resources
from at that level?
2010/1/6 Darin Fisher da...@chromium.org
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
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
pierre.lafaye...@gmail.com 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
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 da...@chromium.org 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
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 de...@chromium.org wrote:
I am pretty out of things these days, but will a DOM UI file://
listing work
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.
On Tue, Jan 5, 2010 at 1:04 PM, Pierre-Antoine LaFayette
pierre.lafaye...@gmail.com wrote:
Apparently
On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org 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
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
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
pierre.lafaye...@gmail.com wrote:
That's why
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
Instead of DOMUI, why not use an extension to display the directory
listing? You can put the icons in the CRX.
Adam
On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote:
I talked with Arv in person and I think I sufficiently convinced him
that getting DOMUI security right is
On Tue, Jan 5, 2010 at 5:34 PM, Adam Barth aba...@chromium.org wrote:
Instead of DOMUI, why not use an extension to display the directory
listing? You can put the icons in the CRX.
this would drastically inflate the size of the extension and wouldn't match
the system icon theme
Adam
On Tue, Jan 5, 2010 at 2:50 PM, Evan Martin e...@chromium.org wrote:
On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org 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
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 e...@chromium.org wrote:
I talked with Arv in person and I think I
http://crbug.com/24421 and http://crbug.com/27772 seem to hint that
these directory listing pages would benefit from being handled at a
higher level than the WebKit Glue Layer (or the net module in the case
of file:///), namely as a DOM ui page. Is there any reason why
ChromiumOS'
19 matches
Mail list logo
