[chromium-dev] Re: Is there any logging to print out messaging between Browser and Renderer
You can set the environmental variable in XCode by double clicking on the executable target. I'm not sure the logging code is enabled on OSX, the right place to look would be in chrome/common/ipc_channel_posix.cc, search for IPC_MESSAGE_LOG_ENABLED. If that's compiled in, then if the env variable is set as jam says, you should get message logging. Best regards, Jeremy On Wed, Jun 10, 2009 at 10:46 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: On Wed, Jun 10, 2009 at 8:56 PM, John Abd-El-Malekj...@chromium.org wrote: about:ipc is only implemented on Windows. For Mac/Linux, you need to set the CHROME_IPC_LOGGING environment variable. All the messages will be dumped to stderr. I have added 'export CHROME_IPC_LOGGING=1' in my .profile on Macos. Reboot my machine. And 'build and debug' my chrome xocde project under Xcode. Load Google.com But I only see the following in my XCode Console View: [366:17667:919320584122:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:17667:919332572808:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:17667:919406692781:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:17667:919545318766:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:17667:919545477665:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:2067:1055305882028:ERROR:/Users/samuel/chromium/src/chrome/browser/tab_contents/ tab_contents_view_mac.mm(117)] Not implemented reached in virtual void TabContentsViewMac::SizeContents(const gfx::Size) [366:17667:1056204955438:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:17667:1056365389566:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:17667:1056370011421:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:17667:1056456409105:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:17667:1056456929069:WARNING:/Users/samuel/chromium/src/chrome/browser/renderer_host/resource_dispatcher_host.cc(608)] Canceling a request that wasn't found [366:2067:1060039015993:ERROR:/Users/samuel/chromium/src/chrome/common/temp_scaffolding_stubs.cc(277)] Not implemented reached in static void HungRendererDialog::HideForTabContents(TabContents*) LEAK: 5 CachedResource LEAK: 166 WebCoreNode Leak 1 JS wrappers. On Wed, Jun 10, 2009 at 8:34 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: Thank you. I try and successfully build chromium on MacOS using XCode. Then I do a 'build and Go (debug)'. In one tab , I load www.google.com and then do a search for 'test'. In another tab, I enter 'about:ipc' but it shows nothing. Am I missing something? Thank you. On Wed, Jun 10, 2009 at 8:02 PM, Eric Romanero...@chromium.org wrote: Even better, use a DEBUG build of chromium and navigate to about:ipc. This opens a window that logs all of the IPC messages being made. On Wed, Jun 10, 2009 at 7:34 PM, Mohamed Mansourm...@chromium.org wrote: You can pass in --log-level=N to the command line, where N is 0 = INFO 1 = WARNING 2 = ERROR 3 = FATAL The default login level is set to 1 which is WARNING. -- Mohamed Mansour On Wed, Jun 10, 2009 at 10:24 PM, Meryl Silverburgh silverburgh.me...@gmail.com wrote: Hi, Is there any logging to print out messaging between Browser and Renderer processes? If yes, can you please tell me how to enable it? And where does the log go? Thank you. --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
I've fixed this flickering problem by calling ::SetClassLong(hwnd, GCL_HCURSOR, NULL) within my OnMouseEntered and then I reset it back to the original class cursor in OnMouseExited. Not sure if this is a reasonable solution or if you even think this is a problem. If so, I can file a bug report and submit this change for review. Cheers, Daniel On Jun 10, 10:08 pm, Daniel Cowx daniel.c...@gmail.com wrote: Actually, I see this flickering on a plain old view::Link as well. You can see it if you move the cursor back and forth on say the open source software link on the Chromium About dialog. On Jun 10, 9:42 pm, Ben Goodger (Google) b...@chromium.org wrote: I don't know, check WidgetWin. I would be slightly surprised though... we use GetCursorForPoint in a couple of places and haven't had issues... -Ben On Wed, Jun 10, 2009 at 9:39 PM, Daniel Cowxdaniel.c...@gmail.com wrote: Hi Ben, I'm getting the flickering even when I dont have any children in my view. I tried overridding GetViewForPoint for my view class and returning this, but I still get this flicker (with or without the label and bitmap being present). According to MSDN @http://msdn.microsoft.com/en-us/library/ms648393(VS.85).aspx snip make sure the class cursor for the specified window's class is set to NULL. If the class cursor is not NULL, the system restores the class cursor each time the mouse is moved. /snip Could this be the culprit? On Jun 10, 9:05 pm, Ben Goodger (Google) b...@chromium.org wrote: You want to override GetViewForPoint on the container view and return this, rather than allowing the default implementation of the function to propagate into the base class impl. The reason you're getting flicker is that the default impl of RootView::UpdateCursor calls GetViewForPoint which ends up asking both the label and the text and the container view for the cursor, so its constantly getting reset as you move your mouse over it. -Ben On Wed, Jun 10, 2009 at 8:55 PM, Daniel Cowxdaniel.c...@gmail.com wrote: I've got a composite view that consists of a SkBitmap and views::Label. I'd like to use IDC_HAND (hand cursor) for this composite view so I've overridden view::GetCursorForPoint(...) Though this kinda works, it causes the cursor to jitter/flicker as it calls this function repeatedly based on the current cursor coordinates within the view. How can I implement the desired functionality without this flickering? I've also tried overriding view::OnMouseEntered() and view::OnMouseExited() and manually calling ::SetCursor() to no avail. Can someone please shed some light. Thanks, Daniel --~--~-~--~~~---~--~~ 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: Any way to compile webkit faster
Mohamed, if you wish i can share with you the tricks i do on my machine they make the difference of even building chrome.exe from 10 mins to less than 1 (after a small source code change) all this on my very very slow machine i wrote a small exe program which parses the .vsprops and ..vcproj so regardless of which props the project uses you get all the benefits you get /MP you get incremental linking (no Comdat folding and no opt:ref) no warning from the linker for /NOWIN98 (or however it is called) there are some catches as you will get more tree conflicts when you sync, but you can always delete your .vcproj,.vsprops file and sync --force the speed gains are truly amazing (at least 10x when you modify source code, because of the incremental link) there are other ugly parts to it but if you want it, i can send you the exe or the source code so you can use it on your machine this is all tested to never produce any problem (so far) on VS2008 SP1 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Makefile build broken
At least for me, I'm hitting an error with generate_stubs.py. Will
try to figure out the proper fix, in the mean time I fixed up the
paths manually and ran the following from my source root. I was able
to successfully build. This is for a debug build, replace Debug w/
Release for a release build.
python third_party/ffmpeg/generate_stubs.py -i out/Debug/obj/gen -o
out/Debug/obj/gen/ffmpeg/third_party/ffmpeg -t posix_stubs -e
third_party/ffmpeg/ffmpeg_stub_headers.fragment -s ffmpeg_stubs -p
third_party/ffmpeg
third_party/ffmpeg/{avcodec-52.sigs,avformat-52.sigs,avutil-50.sigs}
-- dean
--~--~-~--~~~---~--~~
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: Naming things _views
Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben --~--~-~--~~~---~--~~ 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: Any way to compile webkit faster
Do you think it will also work for Visual Studio 2005 and Windows Vista? ☆PhistucK On Thu, Jun 11, 2009 at 12:39, nakro yoav.zilberb...@gmail.com wrote: Mohamed, if you wish i can share with you the tricks i do on my machine they make the difference of even building chrome.exe from 10 mins to less than 1 (after a small source code change) all this on my very very slow machine i wrote a small exe program which parses the .vsprops and ..vcproj so regardless of which props the project uses you get all the benefits you get /MP you get incremental linking (no Comdat folding and no opt:ref) no warning from the linker for /NOWIN98 (or however it is called) there are some catches as you will get more tree conflicts when you sync, but you can always delete your .vcproj,.vsprops file and sync --force the speed gains are truly amazing (at least 10x when you modify source code, because of the incremental link) there are other ugly parts to it but if you want it, i can send you the exe or the source code so you can use it on your machine this is all tested to never produce any problem (so far) on VS2008 SP1 --~--~-~--~~~---~--~~ 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: Makefile build broken
On Thu, Jun 11, 2009 at 2:39 AM, Dean McNameede...@chromium.org wrote: At least for me, I'm hitting an error with generate_stubs.py. Will try to figure out the proper fix, in the mean time I fixed up the paths manually and ran the following from my source root. I was able to successfully build. This is for a debug build, replace Debug w/ Release for a release build. Tony and awong were talking about this last night, but I don't know what the resolution was (I suspect none). If this is still busted: it's time to revert. Better inconvenience one person than screw up the morning for many. AGL --~--~-~--~~~---~--~~ 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: Linux build totally busted.
Yes, it was my patch, it is completely my fault, I take all the blame.. I'm very sorry about that... The patch had been reviewed but through another revision that was mentioned in the comments... I should have put a link to it as opposed to only the revision ID (I'm used to internal tools that inserts the link automagically so I only put the rev number). The problem is that after a merge conflict, I completely forgot to rebuild on Mac and Linux (which I have been doing regularly for over a month for this specific patch that has been opened forever and it wasn't trivial to do so) and so I broke the build last night (well, night in EDT). I quickly found the problem and fixed is and tried to build it on Linux but V8 didn't want to build after many re-sync and clobbers, I had not clue what was happening there, so I sent it to the try server and it built find, so I committed the re-landing... I know... I should not rely on the try server, but I have tried this patch many many times on all platforms and never had a problem... I tried again this morning and I had to create a whole new view of the repos to be able to properly build. The current problem is easy to fix, it is a last minute check that I added in platform independent code in reply to a code review suggestion and it didn't trigger on Windows (so I didn't see the error when I tested the platform independent code) and for some reason it started triggering on Linux after the last time I tried to run on Linux... It was a simply typo of an embedded for loop index that was causing a protective _DEBUG only DCHECK to fire... I could fix it easily this morning... But I'm not going to try this patch again soon, cause I noticed that it didn't completely solve the performance problem I was trying to solve... So I don't feel too good about it... (anybody has a *Harakiri* sword to spare? :-)... I'm very sorry that I caused so much trouble, and I will be much more careful next time... I'm hope you will all have a very good day anyway... :-) BYE SAD (the-developer-formerly-known-as-MAD :-) On Thu, Jun 11, 2009 at 7:30 AM, Dean McNamee de...@chromium.org wrote: Reoccuring lesson, when you're looking for a shotty change, look for the ones with the worst commit messages: Of course I overlooked the change 50 times because the message tells you absolutely nothing, doesn't have a review URL, etc. I don't feel like figuring out what is wrong with this patch, I will TBR a revert right now. Insert typical complaints about writing Linux specific code, clearly not testing it at all, and wasting a bunch of peoples time. commit 7c4e9d282fb3af3ea5c732d37908a133662e02e2 Author: m...@google.com m...@google.com @0039d316-1c4b-4281-b951-d872f2087c98 Date: Thu Jun 11 01:08:27 2009 + Relanding reverted patch 18090. git-svn-id: svn://chrome-svn/chrome/trunk/s...@18130 0039d316-1c4b-4281-b951-d872f2087c98 On Thu, Jun 11, 2009 at 1:17 PM, Dean McNameede...@chromium.org wrote: One of the ideas would be to bisect the archived builds (http://build.chromium.org/buildbot/continuous/linux/LATEST/). I am also working on hunting this down. I'll let you know when/if I find anything. Thanks for the great help -- dean On Thu, Jun 11, 2009 at 1:15 PM, Craig Schlentercraig.schlen...@gmail.com wrote: It might not be r18131 ... I compiled head without 18131 and even though it looked like that helped earlier, it's broken again now. Interestingly when opening new tabs, only some of them are broken which is probably why I thought it was ok earlier ... will leave something bisecting in the backround but it's a rather long cycle time on my laptop to do each build. --Craig On Thu, Jun 11, 2009 at 12:42 PM, Craig Schlentercraig.schlen...@gmail.com wrote: Hi Dean I am seeing the same thing ... it seems to be r18131 that is at fault. I have not tracked it down further than that ... Shared build is also bust. See attached patch ... dunno if that's the right fix. --Craig On Thu, Jun 11, 2009 at 11:58 AM, Dean McNameede...@chromium.org wrote: Something related to images, or resources, or decoders, or painting, or something. Multiple reports of everything being complete broken. Screenshot of my recent build attached. -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Poting Chromium and security
Hey all, Dean reminded me that because we are developing Chrome for multiple platforms, there will be differences between the various ports that may affect the security of our code. E.g. if we use different implementations of image decoders on different ports, Chromium as a whole will have more surface area for attackers to find bugs in. It also means we have more code to maintain, so there are good reasons to avoid this whenever possible. Another problem with having different code for different platforms is that we will need to do security tests on each platforms separately to make sure none of the code has vulnerabilities. Finally, a vulnerability in the code of one port may not exist in another if they are implemented differently. All in all this means that it would be very useful to maintain a list of implementation and design differences between the various ports. I am looking for practical and efficient ways to create and maintain such a list. Ideally, it should be easy/mandatory to update the list to prevent it from ever becoming out-dated. Any thoughts/suggestions? Thanks, BJ Berend-Jan SkyLined Wever (skyli...@google.com) Security Software Engineer Google NL B.V. Reg: C. Debussylaan 34, 15th floor 1082 MD A'dam 34198589 NL VAT / Tax ID:- 812788515 B01 --~--~-~--~~~---~--~~ 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: Makefile build broken
The make file generator has a bug. I started to work on fixing the build last night but it's not finished and I'm not sure how long it will take me this morning. I think it's a little unfair to revert even though all the buildbots are green (since there's no make buildbot and we can use the scons build instead). Alternately, if this file is not going to change often, maybe we can just check the generated file into the tree? Albert, what do you think? I estimate that about 5-7 people on the linux team use the make build these days. On Thu, Jun 11, 2009 at 8:29 AM, Adam Langleya...@chromium.org wrote: On Thu, Jun 11, 2009 at 2:39 AM, Dean McNameede...@chromium.org wrote: At least for me, I'm hitting an error with generate_stubs.py. Will try to figure out the proper fix, in the mean time I fixed up the paths manually and ran the following from my source root. I was able to successfully build. This is for a debug build, replace Debug w/ Release for a release build. Tony and awong were talking about this last night, but I don't know what the resolution was (I suspect none). If this is still busted: it's time to revert. Better inconvenience one person than screw up the morning for many. AGL --~--~-~--~~~---~--~~ 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: 2 problems with extension development
Well, the issue with loading views first is that when you open a new window, that would create new views. In the extension we've implemented, the background page iterates through the views whenever it needs to update them. Alternatively, we may want to implement onViewCreated events so it's easier to keep track of them (but that might be more brittle). -Nick On Thu, Jun 11, 2009 at 9:16 AM, Nebojša Ćirić nci...@gmail.com wrote: I am somewhat confused wrt. loading sequence. If background page main task is to load data once for all views, and then to update them, shouldn't then views be loaded first (toolstrips etc.)? *background_page*: ... 1. gather data once ... 2. update all views // if loads first, no other views are going to be in the list ... *all other views*: ... o. have a function that would update view once called from background page ... Or do you expect views to poll background page? Cira 2009/6/10 Aaron Boodman a...@chromium.org I agree the background page should load first. What's happening right now is that ExtensionProcessManager monitors EXTENSIONS_LOADED, just like everyone else (including Browser) so they get loaded about the same time. It looks like currently the background page starts first, because it was registered first, but it's basically a race. - a 2009/6/10 Nick Baum nickb...@chromium.org: This might be the same problem I ran into when writing my extension: because the bg page and toolstrips don't load in a predictable order, you're not guaranteed to catch all views if you do getViews() right as the page loads. If the background page was guaranteed to load first, the toolstrips could all make sure to find it when they loaded. -Nick 2009/6/10 Aaron Boodman a...@chromium.org On Wed, Jun 10, 2009 at 3:17 PM, Nebojša Ćirićnci...@gmail.com wrote: What about the second issue? Shouldn't iterating over background page views return toolstrip views, instead of background page itself (and no toolstrip views)? I'll try it again just to make sure I didn't make an obvious mistake... This method should return all running HTML pages in your extension -- this includes the background page, any toolstrips, and any tabs that are showing HTML from the extension. If it's not doing that, it's a bug. - a --~--~-~--~~~---~--~~ 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: Makefile build broken
On Thu, Jun 11, 2009 at 8:52 AM, Tony Changt...@chromium.org wrote: Albert, what do you think? I estimate that about 5-7 people on the linux team use the make build these days. I reverted in r18168. It sucks that there's no try or builders for the make build, but it's what everyone uses these days. AGL --~--~-~--~~~---~--~~ 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: Makefile build broken
On Thu, Jun 11, 2009 at 12:48 PM, Adam Langley a...@chromium.org wrote: On Thu, Jun 11, 2009 at 8:52 AM, Tony Changt...@chromium.org wrote: Albert, what do you think? I estimate that about 5-7 people on the linux team use the make build these days. I reverted in r18168. It sucks that there's no try or builders for the make build, but it's what everyone uses these days. If the times are really better, we can change the default in gyp, someone just needs to update the buildbot scripts accordingly. TVL AGL --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
On Thu, Jun 11, 2009 at 12:26 AM, Daniel Cowx daniel.c...@gmail.com wrote: I've fixed this flickering problem by calling ::SetClassLong(hwnd, GCL_HCURSOR, NULL) within my OnMouseEntered and then I reset it back to the original class cursor in OnMouseExited. Not sure if this is a reasonable solution or if you even think this is a problem. If so, I can file a bug report and submit this change for review. Would it be better to just do this in your class' constructor? Also if there are problems like this with existing classes please file bugs, and since you have some idea of the fix consider fixing them. Maybe one of the base view classes should do this fix? PK --~--~-~--~~~---~--~~ 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: Naming things _views
sure why not... the _platform suffix is supposed to be for files in a location where multiple platfomrs are built. -Ben On Thu, Jun 11, 2009 at 2:47 AM, Dean McNameede...@chromium.org wrote: Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben --~--~-~--~~~---~--~~ 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: 2 problems with extension development
I think views are going to have to sometimes check in with the background page on creation. But since the background page is meant to hold on the core logic of your extension, it makes much more sense to me have its lifetime bookend all other parts of the extension. - a On Thu, Jun 11, 2009 at 9:16 AM, Nebojša Ćirićnci...@gmail.com wrote: I am somewhat confused wrt. loading sequence. If background page main task is to load data once for all views, and then to update them, shouldn't then views be loaded first (toolstrips etc.)? background_page: ... 1. gather data once ... 2. update all views // if loads first, no other views are going to be in the list ... all other views: ... o. have a function that would update view once called from background page ... Or do you expect views to poll background page? Cira 2009/6/10 Aaron Boodman a...@chromium.org I agree the background page should load first. What's happening right now is that ExtensionProcessManager monitors EXTENSIONS_LOADED, just like everyone else (including Browser) so they get loaded about the same time. It looks like currently the background page starts first, because it was registered first, but it's basically a race. - a 2009/6/10 Nick Baum nickb...@chromium.org: This might be the same problem I ran into when writing my extension: because the bg page and toolstrips don't load in a predictable order, you're not guaranteed to catch all views if you do getViews() right as the page loads. If the background page was guaranteed to load first, the toolstrips could all make sure to find it when they loaded. -Nick 2009/6/10 Aaron Boodman a...@chromium.org On Wed, Jun 10, 2009 at 3:17 PM, Nebojša Ćirićnci...@gmail.com wrote: What about the second issue? Shouldn't iterating over background page views return toolstrip views, instead of background page itself (and no toolstrip views)? I'll try it again just to make sure I didn't make an obvious mistake... This method should return all running HTML pages in your extension -- this includes the background page, any toolstrips, and any tabs that are showing HTML from the extension. If it's not doing that, it's a bug. - a --~--~-~--~~~---~--~~ 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: Adding Mac OS X Spellchecker to Chromium
Use of OS X spellchecker integration in our multi process model probably should be the primary goal here to begin with. If that is achieved, the other stuff (auto spell correct, automatically setting the dictionary etc) should not be too problematic. Note that the actual replacement for auto-correct is done in WebCore (WebKit) - Chrome just provides the decision as to whether to auto- correct it or not. So, as you pointed out, our method SpellcheckWord, instead of using Hunspell, can ask OS X SpellCheck API to provide the decision. The multi-process model is automatically taken care of here from existing design, since any query for spellchecking comes to the spellchecker in the browser process - and the browser process can talk to the OS X API I guess. Same goes for generic spell checking. There is some integration with Chrome UI where one can set the spellcheck dictionary languages, enable/disable spellchecking/auto- correct. Again, all these decisions eventually seep down to the spellchecker residing in the browser process, and as far as you are concerned, the SpellCheckWord and GetAutoCorrectWord methods should continue asking OS X for the spelling decisions, now based on the new language, or not, depending on the setting. If OS X does not support some languages, this can be dealt with easily. You can make a list of languages that OS X supports, and based on that, either ask OS X spellcheck API, or simply initialize Hunspell in SpellChecker when the language is changed. The Profile, which initializes spellchecker, can be blissfully unaware of this, as it does not care how you are providing the spellchecking as long as the spellchecker object exists, and is providing decisions. I am not exactly sure how automatically setting dictionary language will work out, as it has not been implemented yet. But you can get to that later - my thought is, it should be on similar lines, where you have to only worry about spellchecker.cc. -Sid On Jun 10, 8:29 pm, Ben Goodger (Google) b...@chromium.org wrote: +Sid I think it's worth understanding the API requirements of the new features. I know nothing about Spellchecking though. Maybe Sid can add more? -Ben On Wed, Jun 10, 2009 at 8:14 PM, Nick Baumnickb...@chromium.org wrote: In particular, Ben is referring to the automatic spelling correction that Sid is implementing. Off the top of my head, I can think of a few different ways this could fit in: We can implement Sid's auto-correction on top of native spellcheck, just like today it's implemented on top of Hunspell. OS X will provide similar (though not identical) functionality, and we deem this good enough. We decide native integration is more important than feature parity. As we add more smarts to the spellchecker, we'd need to keep re-evaluating. Thoughts? -Nick On Wed, Jun 10, 2009 at 2:38 PM, Ben Goodger (Google) b...@chromium.org wrote: For whoever is coordinating this effort, please sync up with Nick Baum on spell checking. He has some additional considerations in mind we should make sure we understand what's possible here. -Ben On Wed, Jun 10, 2009 at 2:36 PM, Mike Pinkertonpinker...@chromium.org wrote: I think we're all on the same page. I pushed Paul to consider having both in his initial design since I forgot about the ability to add additional dictionaries. I'm glad others are in support of that as the way to get additional language support as opposed to trying to shim both implementations together. I agree with Jeremy, let's focus on the OSX spellchecker and ignore hunspell for now. Additionally, let's aim for the OS X spelling dialog if we can do it, regardless of whether or not win/linux can do it. On Wed, Jun 10, 2009 at 11:59 AM, Thomas Van Lententhoma...@chromium.org wrote: On Wed, Jun 10, 2009 at 2:38 PM, p_W paulwoolcoc...@gmail.com wrote: Forgive my (possibly) stupid concern here, but a few months ago there was some talk about this, and about how integrating with the OS's spellchecker was the preferred route as it allowed users to use their dictionary customizations over all their applications. Here is link to the discussion: http://groups.google.com/group/chromium-dev/browse_thread/thread/3183... Any thoughts about this? Uh, that's what this thread is about, his project is to switch to using the os one instead. And Jeremy was commenting that he doesn't need to support both, just switch to the native. Or am I reading this differently? TVL On Jun 9, 9:00 pm, Jeremy Moskovich jer...@chromium.org wrote: A couple more things: * I think ultimately we should support the grammar checker, but at first just getting spellchecking to work would be great! * +1 for supporting the Cocoa gui for spellchecking paragraphs, see the 2nd paragraph bellow for more thoughts on this. Matching Linux Windows functionality is a non-goal
[chromium-dev] Re: Any way to compile webkit faster
By last gyp Sverrir, do you mean the modules in chrome.sln switching over, or the ones in webkit?There was one generated set of targets in webkit.gyp, that we ended up adding a makefile emission option for. It was just too slow with rules (all the overhead of crossing over into cygwin per file). There are some rules in chrome.gyp that might have similar properties and would benefit from turning on the makefile option for those rules. -BradN On Thu, Jun 11, 2009 at 7:40 AM, Sverrir Á. Berg sver...@chromium.orgwrote: Just wanted to echo Mohamed's findings. My build has been very slow the past two weeks. I'm using VS2008 and I have not used /MP recently. I have a top of the line machine (xw6600 Quad Core 8G mem, Intel SSD) and building chrome.exe after a sync/clean takes approx 40 minutes. I think this started approximately around the last gyp change... Sverrir On Thu, Jun 11, 2009 at 6:03 AM, nakro yoav.zilberb...@gmail.com wrote: most of it will, but i never tried it however, i saw here in this forum ppl complaining that /MP on 2005 creates corrupted .PDB (the debug info) files so i don't know, but the incremental linking should work if you wish you can PM me and i will send you whatever you want (even the tool i wrote to make Cl.exe run in IDLE_PRIORITY_CLASS so i don't die while code compiles) but i just warn you that these things are not supported by chrome so do it at your own risk --~--~-~--~~~---~--~~ 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: Naming things _views
So the class name is the same too in this case? (InfoBubble and InfoBubble) Erik On Thu, Jun 11, 2009 at 10:46 AM, Ben Goodger (Google) b...@chromium.orgwrote: sure why not... the _platform suffix is supposed to be for files in a location where multiple platfomrs are built. -Ben On Thu, Jun 11, 2009 at 2:47 AM, Dean McNameede...@chromium.org wrote: Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben --~--~-~--~~~---~--~~ 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: Makefile build broken
sorry for the bustage. I had assumed the make file was still a toy with only 2-3 people using it (not many linux chrome folks where I am). Thanks for rolling it back Adam. I'll probably just submit the generated files as tony suggested. -Albert On Thu, Jun 11, 2009 at 9:51 AM, Thomas Van Lenten thoma...@chromium.orgwrote: On Thu, Jun 11, 2009 at 12:48 PM, Adam Langley a...@chromium.org wrote: On Thu, Jun 11, 2009 at 8:52 AM, Tony Changt...@chromium.org wrote: Albert, what do you think? I estimate that about 5-7 people on the linux team use the make build these days. I reverted in r18168. It sucks that there's no try or builders for the make build, but it's what everyone uses these days. If the times are really better, we can change the default in gyp, someone just needs to update the buildbot scripts accordingly. TVL AGL --~--~-~--~~~---~--~~ 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: Naming things _views
Well, class name is supposed to match the file name in Google style. -Ben On Thu, Jun 11, 2009 at 11:22 AM, Erik Kayerik...@chromium.org wrote: So the class name is the same too in this case? (InfoBubble and InfoBubble) Erik On Thu, Jun 11, 2009 at 10:46 AM, Ben Goodger (Google) b...@chromium.org wrote: sure why not... the _platform suffix is supposed to be for files in a location where multiple platfomrs are built. -Ben On Thu, Jun 11, 2009 at 2:47 AM, Dean McNameede...@chromium.org wrote: Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben --~--~-~--~~~---~--~~ 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: Makefile build broken
On Thu, Jun 11, 2009 at 11:49 AM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: I'll probably just submit the generated files as tony suggested. Check with Tony, but I think I just reviewed a GYP change which will make (forgive the pun) it work again. AGL --~--~-~--~~~---~--~~ 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: Text editing freezing jank?
On Thu, Jun 11, 2009 at 12:17 PM, Nick Baum nickb...@chromium.org wrote: Has anyone else run into this behavior in Chrome, in Gmail or elsewhere? Any suggestions for next steps to track this down? I suggest searching the bug database. You will find this: http://crbug.com/12785 PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Exclude Tab Bar Area
Is this possible in chrome currently (perhaps some theme hack would allow this??) or through and extension? I want to exclude the tab bar from using some space near the window controls in the upper left corner of the window. This space is permanently occupied by winamp on my system (set to always on top). So If I have tabs spanning the title bar, some are blocked by winamp. see this image (picasaweb): http://lh3.ggpht.com/_WL2DyBcS1cw/SjFVU9X6-CI/AKs/EGtobJR828k/s800/Capture.PNG please advise. --~--~-~--~~~---~--~~ 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: Exclude Tab Bar Area
There's no easy way to do this today. Erik On Thu, Jun 11, 2009 at 12:52 PM, Peter peter.j.obr...@gmail.com wrote: Is this possible in chrome currently (perhaps some theme hack would allow this??) or through and extension? I want to exclude the tab bar from using some space near the window controls in the upper left corner of the window. This space is permanently occupied by winamp on my system (set to always on top). So If I have tabs spanning the title bar, some are blocked by winamp. see this image (picasaweb): http://lh3.ggpht.com/_WL2DyBcS1cw/SjFVU9X6-CI/AKs/EGtobJR828k/s800/Capture.PNG please advise. --~--~-~--~~~---~--~~ 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: Exclude Tab Bar Area
I have the same issue with the Windows language bar and the SCIM toolbar, I don't think there's really any way to fix this though. On Thu, Jun 11, 2009 at 1:52 PM, Peterpeter.j.obr...@gmail.com wrote: Is this possible in chrome currently (perhaps some theme hack would allow this??) or through and extension? I want to exclude the tab bar from using some space near the window controls in the upper left corner of the window. This space is permanently occupied by winamp on my system (set to always on top). So If I have tabs spanning the title bar, some are blocked by winamp. see this image (picasaweb): http://lh3.ggpht.com/_WL2DyBcS1cw/SjFVU9X6-CI/AKs/EGtobJR828k/s800/Capture.PNG please advise. -- Stefan Nuxoll ste...@nuxoll.eu.org --~--~-~--~~~---~--~~ 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: Text editing freezing jank?
Doh, thanks! -Nick On Thu, Jun 11, 2009 at 12:18 PM, Peter Kasting pkast...@google.com wrote: On Thu, Jun 11, 2009 at 12:17 PM, Nick Baum nickb...@chromium.org wrote: Has anyone else run into this behavior in Chrome, in Gmail or elsewhere? Any suggestions for next steps to track this down? I suggest searching the bug database. You will find this: http://crbug.com/12785 PK --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
On Thu, Jun 11, 2009 at 9:58 AM, Peter Kasting pkast...@google.com wrote: Also if there are problems like this with existing classes please file bugs, and since you have some idea of the fix consider fixing them. It looks like maybe this problem occurs when mousing over text in the Omnibox -- on Vista my cursor seems to flicker between the pointer and the I-beam. Ben, do you see this? This seems like a regression (and a pretty noticeable one). Will file if you confirm. PK --~--~-~--~~~---~--~~ 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: Text editing freezing jank?
If anyone sees this somewhere other than Gmail replies, please comment on the bug. On Thu, Jun 11, 2009 at 1:00 PM, Nick Baum nickb...@chromium.org wrote: Doh, thanks! -Nick On Thu, Jun 11, 2009 at 12:18 PM, Peter Kasting pkast...@google.comwrote: On Thu, Jun 11, 2009 at 12:17 PM, Nick Baum nickb...@chromium.orgwrote: Has anyone else run into this behavior in Chrome, in Gmail or elsewhere? Any suggestions for next steps to track this down? I suggest searching the bug database. You will find this: http://crbug.com/12785 PK --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
On Thu, Jun 11, 2009 at 2:38 PM, Ben Goodger (Google) b...@chromium.orgwrote: Is the default cursor config in the window class even necessary? Isn't the default pointer the arrow anyway? Maybe we could just remove it from WindowWin. As long as Windows doesn't make the mouse cursor disappear by default when doing that, I say let's do it. Want me to file something, or you want to just patch this? PK --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
It's worth a shot. We should make sure this is one of the WNDCLASSEX fields that when not set causes the window not to be created, obviously! -Ben On Thu, Jun 11, 2009 at 2:40 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jun 11, 2009 at 2:38 PM, Ben Goodger (Google) b...@chromium.org wrote: Is the default cursor config in the window class even necessary? Isn't the default pointer the arrow anyway? Maybe we could just remove it from WindowWin. As long as Windows doesn't make the mouse cursor disappear by default when doing that, I say let's do it. Want me to file something, or you want to just patch this? PK --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
On Thu, Jun 11, 2009 at 2:48 PM, Ben Goodger (Google) b...@chromium.orgwrote: Daniel, do you want to try making this change instead? It'll be pretty obvious to you if it doesn't work. Filed as crbug.com/13926 . We should try and find if we set a value in the WindowWin or WidgetWin (or somewhere) window creation calls and just ditch it. Daniel, feel free to whip up a patch, if it works Ben or I can review. PK --~--~-~--~~~---~--~~ 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: How to change the cursor smoothly for a view
It's in the class registration function in widget_win.cc -Ben On Thu, Jun 11, 2009 at 2:52 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jun 11, 2009 at 2:48 PM, Ben Goodger (Google) b...@chromium.org wrote: Daniel, do you want to try making this change instead? It'll be pretty obvious to you if it doesn't work. Filed as crbug.com/13926 . We should try and find if we set a value in the WindowWin or WidgetWin (or somewhere) window creation calls and just ditch it. Daniel, feel free to whip up a patch, if it works Ben or I can review. PK --~--~-~--~~~---~--~~ 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: Naming things _views
FWIW, we don't use _cocoa or _mac in browser/cocoa at all, assuming it was implied. I assumed gtk was doing the same. On Thu, Jun 11, 2009 at 11:53 AM, Ben Goodger (Google)b...@chromium.org wrote: Well, class name is supposed to match the file name in Google style. -Ben On Thu, Jun 11, 2009 at 11:22 AM, Erik Kayerik...@chromium.org wrote: So the class name is the same too in this case? (InfoBubble and InfoBubble) Erik On Thu, Jun 11, 2009 at 10:46 AM, Ben Goodger (Google) b...@chromium.org wrote: sure why not... the _platform suffix is supposed to be for files in a location where multiple platfomrs are built. -Ben On Thu, Jun 11, 2009 at 2:47 AM, Dean McNameede...@chromium.org wrote: Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Resurrecting the JSC build.
Team, Now that we're unforked, we want to concentrate on eliminating layout test failures. Through the magic of the WebKit merge, we've accumulated quite a few. Today, we expect around 400 failures, which is not a good number by any stretch. As one of the ways to help determine the source of the failures, I propose that we resurrect the JSC build (and builder), so that we can say with a fair degree of certainty if the cause is in the V8 bindings. Those of you who were involved in maintaining a JSC build of Chromium before may experience painful flashbacks and shortness of breath. My hope is that this time around we should have easier time, since we're unforked and the Script* abstractions are pretty well-defined to keep most of the nasties at bay. Additionally, having gyp is certainly a super-great help. Based on the IM/hallway conversation, Dave Levin, Dmitry Titov, myself and possibly a few others might be interested in helping out with the project. We don't want this to be more than a 10% effort on our parts. Since we hope to have a JSC build bot and ideally a canary bot, we may need some help from the infrastructure gods. So, do you think that resurrecting the JSC build is a: a) terrible idea b) great idea c) whatcha talking bout, Willis? :DG --~--~-~--~~~---~--~~ 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: Resurrecting the JSC build.
IIRC from the Mac porting effort (a year ago now), the JSC build relies significantly on objective-C dom bindings which we neither want to use nor are easy to get working in our build system. We jettisoned them for a reason and my guess is that it would be a non-trivial effort to re-instate them (if at all, things were pretty scary before). Not trying to shirk work or responsibility, just pointing out there be dragons there and my +2 Sword of Build Wrangling is in the shop for repair. On Thu, Jun 11, 2009 at 4:06 PM, Dimitri Glazkovdglaz...@google.com wrote: Team, Now that we're unforked, we want to concentrate on eliminating layout test failures. Through the magic of the WebKit merge, we've accumulated quite a few. Today, we expect around 400 failures, which is not a good number by any stretch. As one of the ways to help determine the source of the failures, I propose that we resurrect the JSC build (and builder), so that we can say with a fair degree of certainty if the cause is in the V8 bindings. Those of you who were involved in maintaining a JSC build of Chromium before may experience painful flashbacks and shortness of breath. My hope is that this time around we should have easier time, since we're unforked and the Script* abstractions are pretty well-defined to keep most of the nasties at bay. Additionally, having gyp is certainly a super-great help. Based on the IM/hallway conversation, Dave Levin, Dmitry Titov, myself and possibly a few others might be interested in helping out with the project. We don't want this to be more than a 10% effort on our parts. Since we hope to have a JSC build bot and ideally a canary bot, we may need some help from the infrastructure gods. So, do you think that resurrecting the JSC build is a: a) terrible idea b) great idea c) whatcha talking bout, Willis? :DG -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Resurrecting the JSC build.
Kind of tangential, but having a JSC build today would mean that on linux we could build a 64bit version of chromium so we can test IMEs sooner on our 64bit workstations. On Thu, Jun 11, 2009 at 4:06 PM, Dimitri Glazkovdglaz...@google.com wrote: Team, Now that we're unforked, we want to concentrate on eliminating layout test failures. Through the magic of the WebKit merge, we've accumulated quite a few. Today, we expect around 400 failures, which is not a good number by any stretch. As one of the ways to help determine the source of the failures, I propose that we resurrect the JSC build (and builder), so that we can say with a fair degree of certainty if the cause is in the V8 bindings. Those of you who were involved in maintaining a JSC build of Chromium before may experience painful flashbacks and shortness of breath. My hope is that this time around we should have easier time, since we're unforked and the Script* abstractions are pretty well-defined to keep most of the nasties at bay. Additionally, having gyp is certainly a super-great help. Based on the IM/hallway conversation, Dave Levin, Dmitry Titov, myself and possibly a few others might be interested in helping out with the project. We don't want this to be more than a 10% effort on our parts. Since we hope to have a JSC build bot and ideally a canary bot, we may need some help from the infrastructure gods. So, do you think that resurrecting the JSC build is a: a) terrible idea b) great idea c) whatcha talking bout, Willis? :DG --~--~-~--~~~---~--~~ 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: Resurrecting the JSC build.
I think such a build would be useful for performance testing of the rest of our infrastructure. It also makes having a webkit.org chromium-webkit build easier. I'm not sure how hard maintaining such a build would be with the new gyp goodness. -eric On Thu, Jun 11, 2009 at 4:06 PM, Dimitri Glazkovdglaz...@google.com wrote: Team, Now that we're unforked, we want to concentrate on eliminating layout test failures. Through the magic of the WebKit merge, we've accumulated quite a few. Today, we expect around 400 failures, which is not a good number by any stretch. As one of the ways to help determine the source of the failures, I propose that we resurrect the JSC build (and builder), so that we can say with a fair degree of certainty if the cause is in the V8 bindings. Those of you who were involved in maintaining a JSC build of Chromium before may experience painful flashbacks and shortness of breath. My hope is that this time around we should have easier time, since we're unforked and the Script* abstractions are pretty well-defined to keep most of the nasties at bay. Additionally, having gyp is certainly a super-great help. Based on the IM/hallway conversation, Dave Levin, Dmitry Titov, myself and possibly a few others might be interested in helping out with the project. We don't want this to be more than a 10% effort on our parts. Since we hope to have a JSC build bot and ideally a canary bot, we may need some help from the infrastructure gods. So, do you think that resurrecting the JSC build is a: a) terrible idea b) great idea c) whatcha talking bout, Willis? :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Throttling URLRequestFileJobs rate?
I'm working on getting the Intl2 test set from the page cycler up and running on the Mac, which currently crashes very quickly. It turns out that one of the test pages has hundreds of images on it, and we simultaneously make hundreds of URLRequestFileJobs to load them. Each of those uses a SharedMemory for communication, each of which requires a file descriptor. This test page generates enough requests at once that we blow out the file descriptor limit (which defaults to 256 on the Mac) and fall apart. It's tempting to say that we should just a) bump up the limit, and b) make failure to create a SharedMemory non-fatal At least some degree of b) is probably a good idea, but it's not entirely clear that we *want* all the layers involved to silently accept failure. Even if we do, local pages with more images than whatever limit we set in a) won't load correctly, and making that limit too high can get ugly. A seemingly better option would be to limit the number of simultaneous URLRequestFileJobs we will allow. I assume we have plumbing in place to deal with limiting the number of simultaneous URLRequestJobs we make per server; is it flexible enough that it could be extended to handle file URLs as well? If so, is there any reason that would be a bad idea? (And can someone point me to the relevant code?) -Stuart --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
In my experience, taking code which assumes a low number of file descriptors and just ramping up the file descriptor limits to accommodate a particular case doesn't work out well. You end up finding out that there are three or four other edge cases which cause problems, things like O(N^2) code paths, or other places where people assume there will only be 2 to 4 file descriptors. If we were some other kind of program, like a database server, well, darn well we had better make it work. But we aren't that kind of program. -scott On Thu, Jun 11, 2009 at 5:23 PM, Jeremy Orlow jor...@google.com wrote: On Thu, Jun 11, 2009 at 5:13 PM, Stuart Morgan stuartmor...@chromium.org wrote: I'm working on getting the Intl2 test set from the page cycler up and running on the Mac, which currently crashes very quickly. It turns out that one of the test pages has hundreds of images on it, and we simultaneously make hundreds of URLRequestFileJobs to load them. Each of those uses a SharedMemory for communication, each of which requires a file descriptor. This test page generates enough requests at once that we blow out the file descriptor limit (which defaults to 256 on the Mac) and fall apart. It's tempting to say that we should just a) bump up the limit, and b) make failure to create a SharedMemory non-fatal At least some degree of b) is probably a good idea, but it's not entirely clear that we *want* all the layers involved to silently accept failure. Even if we do, local pages with more images than whatever limit we set in a) won't load correctly, and making that limit too high can get ugly. A seemingly better option would be to limit the number of simultaneous URLRequestFileJobs we will allow. Personally this seems like the only sane way to do it. Even if you bump the limits, you will hit pretty major slow downs in most OS's (last time I saw anyone try). I assume we have plumbing in place to deal with limiting the number of simultaneous URLRequestJobs we make per server; is it flexible enough that it could be extended to handle file URLs as well? If so, is there any reason that would be a bad idea? (And can someone point me to the relevant code?) -Stuart --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
On Thu, Jun 11, 2009 at 5:13 PM, Stuart Morganstuartmor...@chromium.org wrote: I'm working on getting the Intl2 test set from the page cycler up and running on the Mac, which currently crashes very quickly. It turns out that one of the test pages has hundreds of images on it, and we simultaneously make hundreds of URLRequestFileJobs to load them. Each of those uses a SharedMemory for communication, each of which requires a file descriptor. This test page generates enough requests at once that we blow out the file descriptor limit (which defaults to 256 on the Mac) and fall apart. It's tempting to say that we should just a) bump up the limit, and b) make failure to create a SharedMemory non-fatal At least some degree of b) is probably a good idea, but it's not entirely clear that we *want* all the layers involved to silently accept failure. Even if we do, local pages with more images than whatever limit we set in a) won't load correctly, and making that limit too high can get ugly. FYI, the extension system uses URLRequestFileJob extensively. So I don't think any solution that could lead to silent failures is acceptable. Rate-limiting seems better. - a --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
On Thu, Jun 11, 2009 at 5:13 PM, Stuart Morgan stuartmor...@chromium.orgwrote: I'm working on getting the Intl2 test set from the page cycler up and running on the Mac, which currently crashes very quickly. It turns out that one of the test pages has hundreds of images on it, and we simultaneously make hundreds of URLRequestFileJobs to load them. Each of those uses a SharedMemory for communication, each of which requires a file descriptor. This test page generates enough requests at once that we blow out the file descriptor limit (which defaults to 256 on the Mac) and fall apart. It's tempting to say that we should just a) bump up the limit, and b) make failure to create a SharedMemory non-fatal At least some degree of b) is probably a good idea, but it's not entirely clear that we *want* all the layers involved to silently accept failure. Even if we do, local pages with more images than whatever limit we set in a) won't load correctly, and making that limit too high can get ugly. A seemingly better option would be to limit the number of simultaneous URLRequestFileJobs we will allow. I assume we have plumbing in place to deal with limiting the number of simultaneous URLRequestJobs we make per server; is it flexible enough that it could be extended to handle file URLs as well? If so, is there any reason that would be a bad idea? (And can someone point me to the relevant code?) -Stuart Hmm... we have a couple limiters already: 1- FileStream uses a thread pool to read files asynchronously to the caller. That thread pool is limited in size. 2- ResourceDispatcherHost limits the number of data payloads it will send to a renderer at any given time. It looks for ACKs from the renderer, and if it does not get them fast enough, then it backs off. It seems like this issue, since it is about the shared memory used for streaming resources to a renderer, is not particular to file://. It could happen with http:// as well assuming we had a fast enough network or a janky enough local system, right? -Darin --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
On Thu, Jun 11, 2009 at 7:45 PM, Darin Fisher da...@chromium.org wrote: On Thu, Jun 11, 2009 at 5:13 PM, Stuart Morgan stuartmor...@chromium.orgwrote: I'm working on getting the Intl2 test set from the page cycler up and running on the Mac, which currently crashes very quickly. It turns out that one of the test pages has hundreds of images on it, and we simultaneously make hundreds of URLRequestFileJobs to load them. Each of those uses a SharedMemory for communication, each of which requires a file descriptor. This test page generates enough requests at once that we blow out the file descriptor limit (which defaults to 256 on the Mac) and fall apart. It's tempting to say that we should just a) bump up the limit, and b) make failure to create a SharedMemory non-fatal At least some degree of b) is probably a good idea, but it's not entirely clear that we *want* all the layers involved to silently accept failure. Even if we do, local pages with more images than whatever limit we set in a) won't load correctly, and making that limit too high can get ugly. A seemingly better option would be to limit the number of simultaneous URLRequestFileJobs we will allow. I assume we have plumbing in place to deal with limiting the number of simultaneous URLRequestJobs we make per server; is it flexible enough that it could be extended to handle file URLs as well? If so, is there any reason that would be a bad idea? (And can someone point me to the relevant code?) -Stuart Hmm... we have a couple limiters already: 1- FileStream uses a thread pool to read files asynchronously to the caller. That thread pool is limited in size. 2- ResourceDispatcherHost limits the number of data payloads it will send to a renderer at any given time. It looks for ACKs from the renderer, and if it does not get them fast enough, then it backs off. It seems like this issue, since it is about the shared memory used for streaming resources to a renderer, is not particular to file://. It could happen with http:// as well assuming we had a fast enough network or a janky enough local system, right? -Darin I meant to add: so tweaking #2 would probably work here. -Darin --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
On Thu, Jun 11, 2009 at 7:45 PM, Darin Fisherda...@chromium.org wrote: It seems like this issue, since it is about the shared memory used for streaming resources to a renderer, is not particular to file://. It could happen with http:// as well assuming we had a fast enough network or a janky enough local system, right? I was assuming that in most cases the max-connections-per-server would tend to prevent us from getting to that point, but it's probably possible given the right circumstances. -Stuart --~--~-~--~~~---~--~~ 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: Throttling URLRequestFileJobs rate?
On Thu, Jun 11, 2009 at 8:03 PM, Michael Nordmanmicha...@google.com wrote: Sounds like the underlying issue is not the number of requests (or type of request), but the number of SharedMemory instances in use on behalf of request handling at any one time. True; I'll take a look at how else SharedMemory is used, and where I can introduce delays/blocking without causing problems for handling of other in-flight requests. Also, 256 is a pretty low limit. Dialing it up a few notches (say to 1024) to improve the performance of a better overall solution certainly isn't an issue. -Stuart --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
