Re: [chromium-dev] Question about GraphicsContext clipOut() function
The clipOut function works like a normal clip() except, instead of clipping against the rect/path parameter, it removes the rect/path from the current drawing, i.e. clips it out. 2010/1/11 hap 497 hap...@gmail.com Hi, Can you please help me understand clipOut() function supposed to do? My understanding is GraphicsContext::clip() function is setting the clipping rectangle of the graphics context, only operations within the clipping rectangle will be shown. But what is the purpose of clipOut() function? Thanks in advance for any help. Regards, -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] displaying unparseable ftp directory listings as-is
I am looking into an issue involving adding icons for to the ftp directory listing page, can you point me to where this code is handled? I know that the HTML template is generated in ftp_directory_listing_response_delegate.cc. I'm trying to see if its okay to request icon data from the Browser from within the WebKit glue layer. Thanks. 2010/1/11 Paweł Hajdan, Jr. phajdan...@chromium.org Is there any security risks with passing raw ftp listings to the renderer in case we can't parse them? We already have a check in the code so that we will only make a data connection to the server we have the control connection with. If it's ok to do so, I'd also like to include some message encouraging the user to submit a bug report like hey, Chrome FTP listing parser is not compatible with this site. That would really help with compatibility. The new listing parser is doing quite well, but I think it's still not compatible enough to entirely replace the Mozilla code. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
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, 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 de...@chromium.org 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 da...@chromium.org 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 de...@chromium.org 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 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 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 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 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 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 a...@chromium.org 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 pierre.lafaye...@gmail.com 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 e...@chromium.org 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 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: chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
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 icon data URI? I don't know, but in general sync messages suck. Why couldn't you use an async message and just show the icon once it arrives? PK -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
Bash won't let me do this: $ mkdir https: mkdir: cannot create directory `https:': No such file or directory $ mkdir https: mkdir: cannot create directory `https:': No such file or director 2010/1/9 Victor Khimenko k...@google.com On Sat, Jan 9, 2010 at 2:55 PM, Antoine Labour pi...@google.com wrote: I'm not sure I understand the security risk... If an attacker is able to write files on my disk I have a lot more things to worry about than my browser spoofing urls. Are you sure? The idea is the same as with $PATH attack. Sure, some systems don't even need . in PATH to call programs from current dir by default, but it does make it good idea. In any case you can always OpenURL(string(file://) + urlencode(file_or_url)) instead of OpenLocalFile What will this change? There are sad but fundamental truth about POSIX filenames: ANY string without embedded NUL characters can be valid filename. There are some limitations (MAX_PATH, max number of slashes in some systems, etc), but they are minor. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
Actually it was Cygwin on Windows Vista (GNU bash, version 3.2.49(22)-release (i686-pc-cygwin) Copyright (C) 2007 Free Software Foundation, Inc.). However this isn't very important with regards to the point you're trying to make. I was just curious. 2010/1/9 Victor Khimenko k...@google.com What OS is it? What FS ? I've checked with GHardy - everything works just fine. You can create filenames with :, , , etc. Anything except / but then it's compensated by the fact that duplicated slashes are ignored. Cygwin works too (starting from version 1.7 where support for POSIX FS namespace was added) even if it's pretty irrelevant to Chrome discussion... On Sat, Jan 9, 2010 at 5:28 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Bash won't let me do this: $ mkdir https: mkdir: cannot create directory `https:': No such file or directory $ mkdir https: mkdir: cannot create directory `https:': No such file or director 2010/1/9 Victor Khimenko k...@google.com On Sat, Jan 9, 2010 at 2:55 PM, Antoine Labour pi...@google.com wrote: I'm not sure I understand the security risk... If an attacker is able to write files on my disk I have a lot more things to worry about than my browser spoofing urls. Are you sure? The idea is the same as with $PATH attack. Sure, some systems don't even need . in PATH to call programs from current dir by default, but it does make it good idea. In any case you can always OpenURL(string(file://) + urlencode(file_or_url)) instead of OpenLocalFile What will this change? There are sad but fundamental truth about POSIX filenames: ANY string without embedded NUL characters can be valid filename. There are some limitations (MAX_PATH, max number of slashes in some systems, etc), but they are minor. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
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 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 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 a...@chromium.org 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 pierre.lafaye...@gmail.com 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 e...@chromium.org 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
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 e...@chromium.org 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 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Chromium Tech Talks
Thanks for doing this! 2009/12/8 Jeremy Orlow jor...@chromium.org On Tue, Dec 8, 2009 at 11:25 AM, Jeremy Orlow jor...@chromium.org wrote: Last Friday we recorded 4 tech talks based on the feedback we got on what topics would be interestingand here they are! http://www.youtube.com/watch?v=JFzC_Gx76E8 Darin Fisher talks about the recently upstreamed Chromium WebKit API. http://www.youtube.com/watch?v=bO3XEBuIDns Pam Greene talks about how WebKit Layout Tests are used within Chromium. http://www.youtube.com/watch?v=A5-aXfSt-RA Brett Wilson talks about the painting process in Chromium. Brett starts from the render tree in WebKit, across the IPC boundaries, and all the way to your screen. He also details many of the differences in painting between platforms. http://www.youtube.com/watch?v=IpcOXzIsSlo A deep dive into the guts of WebKit. Eric Seidel explains the process from loading the resources, building the DOM tree, and the various trees involved in rendering. I can't tell you how impressed I was with all of the talks. I learned a couple things from even the talks that covered material I thought I knew well. Enjoy! J P.S. All the talks (past and present) can be found here: http://sites.google.com/a/chromium.org/dev/developers/tech-talk-videos -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Running page cycler tests locally
Yes, I actually did figure out that the acid3 data could be used as sample test data for page_cycler if you mkdir $CHROME/src/data/page_cycler/moz/ and copy the src/tools/page_cycler/acid3 stuff into that directory. 2009/11/12 Chase Phillips c...@google.com On Thu, Nov 12, 2009 at 2:20 PM, Peter Kasting pkast...@google.comwrote: On Thu, Nov 12, 2009 at 2:17 PM, plafayette pierre.lafaye...@gmail.comwrote: I've built page_cycler on Windows and it's asking for a test data folder with the path $CHROME/src/data/page_cycler. Is the data available under the chrome source tree? I can't seem to find it and I don't have it excluded in my .gclient file. This data is not publicly available, sorry. It would be great (and helpful to more browser vendors than just Google) to have a high-quality, redistributable data set for testing page loading. Unfortunately, this would require getting content authors to contribute their content along with sufficient rights to distribute it publicly. Generally this is very difficult. Just noting along with Peter's comments that if you want an example of something like what our page cycler tests currently perform, see src/tools/page_cycler/acid3/start.html. Reviewing the acid3 page cycler might give you a good starting place for building your own private page cycler tests until some well known and well understood public page cyclers become available. Chase -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Tech talk topics
+1 for WebKit talks. I think the painting phase and it's Chromium port would be a very interesting topic. Things like the GraphicsContext interface and the GraphicsContextSkia implementation. What is required for a GraphicsContext port? What is the bottleneck in the paint process (e.g. the Skia blit ops)? 2009/11/5 Jeremy Orlow jor...@chromium.org Thanks for the suggestions so far! Here's what I've seen so far: WebKit API - Darin? Eric's WebKit talk LayoutTests - Pam? Bindings - Andrew? Keep the ideas coming. If we get more than we want to tackle we can always vote on which would be most helpful to the community, but all the ones I've heard so far sound very valuable. J On Thu, Nov 5, 2009 at 3:29 PM, Andrew Scherkus scher...@chromium.orgwrote: Something that would have been immensely helpful to me when I started was a talk explaining the interaction between the javascript bindings, HTMLFooElement classes and RenderFoo classes. I'd volunteer, but I still don't know enough about this stuff myself -- other than when Foo == Media :) Andrew On Thu, Nov 5, 2009 at 3:24 PM, Mohamed Mansour m...@chromium.org wrote: +1 on the WebKit tech talks. And maybe on on the WebKitAPI infrastructure that darin organized. - Mohamed Mansour On Thu, Nov 5, 2009 at 5:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Extracting Webkit Test Shell and its dependencies
I wanted to create a source tree separate from chrome that contains the test_shell project and any other projects it needs within chromium, nothing more. E.g. base, net, webkit etc. Wasn't sure if there is an easy way to figure out all the other projects it depends on. Actually I realized that what I really wanted was simply DumpRenderTree since I need to run layout tests on the Android platform. Fortunately Android has a java test app (LayoutTestsAutoRunner.java) that seems like it should do what I need. I'm just having a hell of a time trying to get it to run even on the Android emulator. But that's really a question for the Android team. Thanks. 2009/10/2 Bradley Nelson bradnel...@google.com Also you should get webkit/tools/tests_shell.sln -BradN On Thu, Oct 1, 2009 at 10:45 AM, Peter Kasting pkast...@google.comwrote: On Wed, Sep 30, 2009 at 4:06 AM, plafayette pierre.lafaye...@gmail.comwrote: Is there a good, and less painful, way to extract test_shell into its own project? I don't understand. test_shell already is its own project (.vcproj). PK -- Pierre. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
