[chromium-dev] Re: Google Blogoscoped author tries out Chrome app shortcuts
For reference, here now is the .reg file that will also work with previously associated files all solved now! Windows Registry Editor Version 5.00 [-HKEY_LOCAL_MACHINE\Software\Classes\.myextension] [-HKEY_CURRENT_USER\Software\Classes\.myextension] [-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer \FileExts\.myextension] [HKEY_CLASSES_ROOT\.myextension] @=myextension_auto_file [HKEY_CLASSES_ROOT\myextension_auto_file] @=Web Search [HKEY_CLASSES_ROOT\myextension_auto_file\shell] [HKEY_CLASSES_ROOT\myextension_auto_file\shell\open] [HKEY_CLASSES_ROOT\myextension_auto_file\shell\open\command] @=\C:\\Users\\johndoe\\AppData\\Local\\Google\\Chrome\\Application\ \chrome.exe\ --app=\http://netpadd/#%1\; --~--~-~--~~~---~--~~ 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: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors
For the record, I build on win7 (both x86 and x64) on vs2008 without problem here. M-A On Tue, Oct 6, 2009 at 9:21 PM, vha14 vuh...@gmail.com wrote: Still having the same issue after following John's suggestions. Being forced to use a separate cygwin's bash.exe. On Oct 2, 12:16 am, Abubakar abubak...@gmail.com wrote: cygwin is supposed to be inside the chrome source that u download. Not to be done anything about it separately. On Fri, Oct 2, 2009 at 4:05 AM, Dan Kegel d...@kegel.com wrote: It's not supposed to be that way... maybe we need to check in a new cygwin. On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote: So it looks like I need to install Cygwin separately before I can build Chrome? If so this should be added to the Windows build instruction page. On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote: I run Cygwin Bash Shell not from Command Prompt: moha...@mohamed-pc ~$ bash -Mohamed On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote: Hi Mohamed, can you run bash.exe from cmd? I get the following error: E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin \binbash 9 [main] bash 8384 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 211065 [main] bash 8384 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 229623 [main] bash 8384 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote: Windows 7 64bit works fine here (using the default settings from dev.chromium.org) Make sure you have access to the folder your writing to. Some folders require admin mode. -Mohamed On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote: Detailed error message: 1-- Build started: Project: js2c, Configuration: Debug Win32 -- 1js2c 2-- Build started: Project: cygwin, Configuration: Debug Win32 -- 2setup_mount 1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 1 3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 2The operation completed successfully. 2The operation completed successfully. 1Project : error PRJ0002 : Error result 35584 returned from 'C: \Windows\SysWow64\cmd.exe'. Content of bash.exe.stackdump: E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore bash.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30 eax= ebx= ecx=61106EC8 edx= esi=611021A0 edi=0045A3E0 ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball \chromium\s rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0028CBC8 0043AE30 (0003, 02361C00, 02360090, 772F) 0028CD68 610060D8 (, 0028CDA0, 61005450, 0028CDA0) 61005450 61004416 (009C, A02404C7, E8611021, FF48) 431390 [main] bash 8296 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VI OLATION 509897 [main] bash 8296 _cygtls::handle_exceptions: Error while dumping state ( probably corrupted stack) --~--~-~--~~~---~--~~ 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: buildbot failure in Chromium on Linux Perf, revision 0
A fix just got in this morning that will hopefully fix recent buildbot spamming habits. It'll still send emails to chromium-dev@ but only when it's actually closing the tree. There was a mismatch between the rules used to close the tree and the rules used to send an email. I'll let you guess which rules were the more lax. :) Sorry for the noise. M-A On Wed, Oct 7, 2009 at 12:37 AM, build...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/ Automatically closing tree for compile on Linux Perf http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/2843 Revision: Blame list: Linux Perf Build 2843http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/2843 The web-page 'force build' button (clobbered) was pressed by rafaelw: update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/2843/steps/shell/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/2843/steps/gclient/logs/stdio compile failed stdiohttp://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/2843/steps/compile/logs/stdio --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Mac] Tab animation improvements under heavy stress
I've spent some time banging my head against this issue on Mac where when we open a ton of tabs at the same time (15+, eg, mashing down cmd-t or opening all bookmarks as tabs) it looks janky because the tabs animate independently. As a result, we end up with the surfacing tabs stuck at various points in their animations until everything catches up, with this odd lumpy camel/snake effect. I tried a whole bunch of things with canceling pending animations when new tabs were created and only had marginal luck. My latest results no longer have the camel effect, but now we end up with small gaps at the end as new tabs are created a few pixels off from the previous tab. Everything eventually snaps into place, but I'm not sure if I've made things any better or worse. The time to create a new tab is unaffected. One (perhaps?) positive change I've made is that tabs now submarine more vertically than before since their width is correctly sized before they are animated (before it was doing width and origin animations). Others, of course, may disagree and think it looks horrible. I'm down to the point where I'm tweaking knobs in a vacuum. I can't tell if I've done anything worth checking in, so I'm taking a breather and asking folks to try the (rather simple) CL here: http://codereview.chromium.org/243049/show Luckily, this latest revision has only a couple of well-isolated blocks, so if we wanted to we could even check it in and then go remove it later if anyone complained. What do people think? -- 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: How to deal with flaky unit tests
On Tue, Oct 6, 2009 at 10:52 PM, Darin Fisher da...@chromium.org wrote: If a test sometimes crashes or hangs, it'll still be disabled, right? Yes. But if it's a ui_tests that crashes chrome.exe (and not ui_tests.exe), we can still mark it as flaky. Nicolas -darin On Tue, Oct 6, 2009 at 5:02 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, We currently have more than 50 unit tests that are disabled. Most of them because they were flaky. Disabling tests is bad because we lose complete coverage on them, so I implemented a way to mark tests as flaky. The same way you disable a test with DISABLED_ at the beginning of its name, you can now mark is as flaky with FLAKY_. The behavior is exactly the same as any other running tests. You will still be able to see when it fails (and why). The only difference is that if only FLAKY_ tests failed, the buildbot/trybots won't consider it as a failure. On the waterfall, it will show the box as orange with the list of all flaky tests that failed (pending one more buildbot restart). On the console view it will stay green. But.. this is not a toy. Flaky tests are bad. We should mark tests flaky only if we really have to, and if you do, please make sure to file a P1 bug. Set the owner of the bug to whoever regressed the test. If you can't find who regressed the test, assign it to the person who originally wrote the test. Once we start tagging the flaky tests, we will monitor the flakiness dashboard and make sure that a test that is no longer flaky has its FLAKY_ tag removed. Let me know if you have questions. Thanks Nicolas --~--~-~--~~~---~--~~ 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: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 6:49 PM, John Abd-El-Malek j...@chromium.org wrote: It's about getting rid of nasty problems like the browser process crashing every startup because of a corrupt database and decreasing browser process crashes in general. I am pretty sure that the sqlite wrapper and sanity checking work that's going on is a better fix than moving to a different process. Not only is it lower overhead, but we'd have to write error-handling code _anyway_ since the sqlite process could crash/fail, so IMO it's extra overhead that doesn't buy us anything. Not that you're not welcome to try doing it, but I wouldn't waste the time. 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: Scalability
On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 11:09 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Tue, Oct 06, 2009 at 09:19:49PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson ja...@mandelson.org
wrote:
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org
wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int,
int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
Ah, you're doing a debug build then? I have only tested release recently.
I'll poke at a debug build tomorrow and try to sort it out ...
Hm ... debug build is also fine for me and I'm building with the
same gyp variables as you (except that I also have gcc_version=44).
If you stick your build into verbose mode can you see if it is linking
librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
regyping etc. will encourage it to do that.
PS. I'm on r28124
I switched to --mode=Release, got strict-aliasing warnings^Werrors, stuck
on -Wno-strict-aliasing, and it landed back in
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
Running gclient runhooks had no effect here.
Building with --verbose shows the very long link line attached, which
has [nN][aA][cC][lL] only in -lnacl.
This problem only seems to happen with the scons shared build. The
make build does not have this problem so there seems to be something
different about how the dependencies are being generated with the make
versus scons gyp backends.
So the executive summary of the current situation is this:
1. Both libbrowser.so and librenderer.so call RegisterInternalNaClPlugin
2. RegisterInternalNaClPlugin lives in libnpGoogleNaClPluginChrome.a
3. libnpGoogleNaClPluginChrome.a is listed as a dependency of
libnacl.so (but it doesn't actually seem to be)
4. librenderer depends on nacl but nacl doesn't export its own
dependency on libnpGoogleNaClPluginChrome either
5. libbrowser doesn't depend on nacl which doesn't really help either.
In order to fix this, we really want to say that anything that
actually uses 'RegisterInternalNaClPlugin' should be linked against
libnpGoogleNaClPluginChrome.a. It is preferable to link the final
executable target with that rather than other intermediate
libraries like libbrowser and librenderer to avoid situations like
issue 5933.
One option (which works at least for the linux scons shared build
chrome target) is to remove
'../native_client/src/trusted/plugin/plugin_chrome.gyp:npGoogleNaClPluginChrome'
from the nacl dependencies and add it to the chrome dependencies in
chrome.gyp. It might also have to be specified manually for other
users of libbrowser and librenderer but that seems messy. I have only
tested this with the shared linux scons build btw.
Perhaps a gyp expert could suggest a better way?
Thanks!
PS. I haven't looked into why the make build gets this stuff right.
I'd guess it is over-specifying dependencies versus what is actually
declared in the gyp files?
--Craig
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] detecting tabs using a lot of CPU?
Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] UI across multiple platforms
Because we have different frontend codebases on different platforms, it's important that we strive to maintain feature parity between them. For this reason whenever we implement a modification to the UI in substance (e.g. add a feature, change a behavior) we should make sure to file a bug for the other platforms as well (or implement it there if you're capable). We should probably have some sort of platform parity label in the bug tracker so we can track these divergences. -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: detecting tabs using a lot of CPU?
Yes, please! However, I would get that dialog about 1000 times a day: http://crbug.com/22948 Linus On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: UI across multiple platforms
FWIW, on extensions, what we have been finding works is to file separate bugs for each platform's UI implementation. It is just too much code to track with one bug. You end up with these mega bugs that never close. We label each bug OS-whatever the case may be - a On Wed, Oct 7, 2009 at 10:01 AM, Ben Goodger (Google) b...@chromium.org wrote: Because we have different frontend codebases on different platforms, it's important that we strive to maintain feature parity between them. For this reason whenever we implement a modification to the UI in substance (e.g. add a feature, change a behavior) we should make sure to file a bug for the other platforms as well (or implement it there if you're capable). We should probably have some sort of platform parity label in the bug tracker so we can track these divergences. -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: UI across multiple platforms
That sounds like the best plan to me. This way there can be separate owners. -Ben On Wed, Oct 7, 2009 at 10:04 AM, Aaron Boodman a...@chromium.org wrote: FWIW, on extensions, what we have been finding works is to file separate bugs for each platform's UI implementation. It is just too much code to track with one bug. You end up with these mega bugs that never close. We label each bug OS-whatever the case may be - a On Wed, Oct 7, 2009 at 10:01 AM, Ben Goodger (Google) b...@chromium.org wrote: Because we have different frontend codebases on different platforms, it's important that we strive to maintain feature parity between them. For this reason whenever we implement a modification to the UI in substance (e.g. add a feature, change a behavior) we should make sure to file a bug for the other platforms as well (or implement it there if you're capable). We should probably have some sort of platform parity label in the bug tracker so we can track these divergences. -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: detecting tabs using a lot of CPU?
maybe instead of a dialog, we can have some kind of a non-modal badness indicator?-darin On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: UI across multiple platforms
Also, it would be great if you found someone willing to implement the modification on other platforms if you're not going to do it yourself. This helps to get feedback early from other platforms (where the modification might not make sense) and it makes sure the bug doesn't sit there without an owner. On Wed, Oct 7, 2009 at 10:04 AM, Aaron Boodman a...@chromium.org wrote: FWIW, on extensions, what we have been finding works is to file separate bugs for each platform's UI implementation. It is just too much code to track with one bug. You end up with these mega bugs that never close. We label each bug OS-whatever the case may be - a On Wed, Oct 7, 2009 at 10:01 AM, Ben Goodger (Google) b...@chromium.org wrote: Because we have different frontend codebases on different platforms, it's important that we strive to maintain feature parity between them. For this reason whenever we implement a modification to the UI in substance (e.g. add a feature, change a behavior) we should make sure to file a bug for the other platforms as well (or implement it there if you're capable). We should probably have some sort of platform parity label in the bug tracker so we can track these divergences. -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: detecting tabs using a lot of CPU?
+1 to glowing hot idea! :DG On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
http://tinderbox.mozilla.org/1afi003r.gif On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
It's better to be non-animated. Remember,ichrome is using too much CPU already. Second; the user is doing something, he doesn't want to be distracted with information unrelated to his current task. If the user finds himself waiting on his current tab, his eyes will probably see a tab being slightly burnt and will wonder what is happening. :) M-A On Wed, Oct 7, 2009 at 1:13 PM, Darin Fisher da...@chromium.org wrote: http://tinderbox.mozilla.org/1afi003r.gif On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
You could replace the favicon with a spinning clock or something. It might also be interesting to provide indicators for high memory usage (or perhaps if the recent memory growth is high), or IPC issues. Then again, many users might prefer not to have their tabs attracting attention needlessly. I mostly don't care whether a tab is using lots of CPU. -scott On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
We had also discussed putting icons indicating audio into tabs. That sounds crowded with icons, though: imaginably a game could have facicon, Unicode symbols, CPU load, audio, and the x displayed. I worry there just aren't enough pixels to display all the relevant information. On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] SVN Stable Tree Path for 3.0.195.25
Hey Guys, what is difference between these releases 3.0.190.2 3.0.195.25 i can get to SVN source tree to read access for code tree 3.0.190.2 using the following svn repository url http://src.chromium.org/svn/releases/3.0.190.2/src/ i want to make sure i am getting the latest stable source tree , is there a better svn url to get latest 3.0.195.25. please advise. Thanks, Amit. --~--~-~--~~~---~--~~ 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: SVN Stable Tree Path for 3.0.195.25
The latest source is in trunk, not a specific release branch. -- Elliot On Tue, Oct 6, 2009 at 12:34 PM, Amit Kishnani akish...@adobe.com wrote: Hey Guys, what is difference between these releases 3.0.190.2 3.0.195.25 i can get to SVN source tree to read access for code tree 3.0.190.2 using the following svn repository url http://src.chromium.org/svn/releases/3.0.190.2/src/ i want to make sure i am getting the latest stable source tree , is there a better svn url to get latest 3.0.195.25. please advise. Thanks, Amit. --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
Most kiosk applications I have developed never leave their designated pages anyway. There are no 'offsite' links or anything. Thus the content is fully controlled. Downloads would not have to be disabled for me. The only 2 key options I would personally want for a kiosk mode, are fullscreen (not maximized, literally fullscreen) launching from commandline, and no status bubble on links and such. Almost all other things I need adjusted (such as context menu and such) can be handled easily with javascript. On Sep 25, 7:32 am, Adam Barth aba...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.org wrote: Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? We could also turn off other features that don't make sense for kiosks, like downloading files. Adam --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
I'm not convinced that we should bother users with this kind of stuff. If an advanced user want to see what's consuming resources, they can open the task manager. If we want this for debugging, perhaps it should live behind a flag. It would be cool if some kind combo of dev tools + extensions could allow developers to be notified of conditions like this. On Wed, Oct 7, 2009 at 10:35 AM, Evan Martin e...@chromium.org wrote: We had also discussed putting icons indicating audio into tabs. That sounds crowded with icons, though: imaginably a game could have facicon, Unicode symbols, CPU load, audio, and the x displayed. I worry there just aren't enough pixels to display all the relevant information. On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
It'd be nice to have a non-distracting visual indicator, but to play the devil's advocate... What about intentionally CPU intensive sites that use canvas, video, WebGL? What about scenarios where it's a plugin that's gone haywire? Could this be accomplished by an extension that displays a little CPU graph? On Wed, Oct 7, 2009 at 10:35 AM, Evan Martin e...@chromium.org wrote: We had also discussed putting icons indicating audio into tabs. That sounds crowded with icons, though: imaginably a game could have facicon, Unicode symbols, CPU load, audio, and the x displayed. I worry there just aren't enough pixels to display all the relevant information. On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: SVN Stable Tree Path for 3.0.195.25
Hey Elliot, thanks for quick turnaround. the trunk (svn) : http://src.chromium.org/svn/trunk/src/chrome/VERSION is MAJOR=4 MINOR=0 BUILD=222 PATCH=1 but I am looking for stable channel - 3.0.195.125 release instead of dev channel, please let me know if there is svn repository link with that version stamp. Thanks! Amit. -Original Message- From: e...@google.com [mailto:e...@google.com] On Behalf Of Elliot Glaysher (Chromium) Sent: Wednesday, October 07, 2009 10:41 AM To: Amit Kishnani Cc: Chromium-dev Subject: Re: [chromium-dev] SVN Stable Tree Path for 3.0.195.25 The latest source is in trunk, not a specific release branch. -- Elliot On Tue, Oct 6, 2009 at 12:34 PM, Amit Kishnani akish...@adobe.com wrote: Hey Guys, what is difference between these releases 3.0.190.2 3.0.195.25 i can get to SVN source tree to read access for code tree 3.0.190.2 using the following svn repository url http://src.chromium.org/svn/releases/3.0.190.2/src/ i want to make sure i am getting the latest stable source tree , is there a better svn url to get latest 3.0.195.25. please advise. Thanks, Amit. --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
On Wed, Oct 7, 2009 at 11:34 AM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: We just noticed that the Chromium Helper.app cannot locate the ffmpeg binaries (libav*.dylib) in Mac Chromium. This leads to the video feature being disabled. :( Where should the ffmpeg binaries go? Should they be put alongside the binary in the Chromium Helper.app/Contents/MacOS? If we do this, I think it will break --single-process mode unless we keep a copy of the binary in both spots (which is ugly). If it helps, I believe --single-process is disabled for Google Chrome builds -- maybe a non issue and simply an inconvenience to us working on Mac video? Is there a shared location that both application bundles will be able to search for the ffmpeg binaries? -Albert P.S. The reason this wasn't noticed earlier is that all the video devs have been executing the app either by setting DYLD_LIBRARY_PATH in their environment manually, or via Xcode -- which sets DYLD_LIBRARY_PATH to include the output directory, again allowing for resolution of the ffmpeg binaries. Using --single-process also avoids this issue since it doesn't use Chromium Helper. *sigh* --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [mac] Chromium Helper + ffmpeg binary location == no video
We just noticed that the Chromium Helper.app cannot locate the ffmpeg binaries (libav*.dylib) in Mac Chromium. This leads to the video feature being disabled. :( Where should the ffmpeg binaries go? Should they be put alongside the binary in the Chromium Helper.app/Contents/MacOS? If we do this, I think it will break --single-process mode unless we keep a copy of the binary in both spots (which is ugly). Is there a shared location that both application bundles will be able to search for the ffmpeg binaries? -Albert P.S. The reason this wasn't noticed earlier is that all the video devs have been executing the app either by setting DYLD_LIBRARY_PATH in their environment manually, or via Xcode -- which sets DYLD_LIBRARY_PATH to include the output directory, again allowing for resolution of the ffmpeg binaries. Using --single-process also avoids this issue since it doesn't use Chromium Helper. *sigh* --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
On Wed, Oct 7, 2009 at 11:36 AM, Andrew Scherkus scher...@chromium.orgwrote: On Wed, Oct 7, 2009 at 11:34 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: We just noticed that the Chromium Helper.app cannot locate the ffmpeg binaries (libav*.dylib) in Mac Chromium. This leads to the video feature being disabled. :( Where should the ffmpeg binaries go? Should they be put alongside the binary in the Chromium Helper.app/Contents/MacOS? If we do this, I think it will break --single-process mode unless we keep a copy of the binary in both spots (which is ugly). If it helps, I believe --single-process is disabled for Google Chrome builds -- maybe a non issue and simply an inconvenience to us working on Mac video? Yeah, if we don't care about single-process, we can just move the binaries, and things becomes happy. However, it'd be nice not to lose --single-process. -Albert --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
On Wed, Oct 7, 2009 at 11:13 AM, Andrew Scherkus scher...@chromium.orgwrote: It'd be nice to have a non-distracting visual indicator, but to play the devil's advocate... What about intentionally CPU intensive sites that use canvas, video, WebGL? What about scenarios where it's a plugin that's gone haywire? Could this be accomplished by an extension that displays a little CPU graph? I would love to see this as an extension-- just like the graph that Procexp.exe or the Windows Task Manager puts in the tray, only per tab in the location bar (getting its data from the Chrome Task Manager). Is that information available to extensions? On a grander scale, it would be great to also have a button to suspend a renderer process if I'm not using it at the moment. I'm sure there's a ton of complicated issues there, though-- it might suspend several seemingly unrelated tabs, the page(s) may have network requests in progress, Flash or a plugin could be to blame, etc, etc. Charlie On Wed, Oct 7, 2009 at 10:35 AM, Evan Martin e...@chromium.org wrote: We had also discussed putting icons indicating audio into tabs. That sounds crowded with icons, though: imaginably a game could have facicon, Unicode symbols, CPU load, audio, and the x displayed. I worry there just aren't enough pixels to display all the relevant information. On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on XP Tests (dbg)(1), revision 28278
Automatically closing tree for unit_tests on XP Tests (dbg)(1) http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests%20%28dbg%29%281%29/builds/13361 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests%20%28dbg%29%281%29 --= Automatically closing tree for unit_tests on XP Tests (dbg)(1) =-- Revision: 28278 Blame list: timste...@google.com Buildbot waterfall: http://build.chromium.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: Why SOCK_SEQPACKET?
On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote: Why will it certainly not work? From what (little) I understand, SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably one could simulate that over SOCK_STREAM? There are multiple, concurrent writers to the socket. If you make assumptions about the kernel's behaviour, you might be able to come up with a workable framing protocol, but it's much better to use the correct socket type. If anyone gets the chance, I would happily pre-LGTM a change that stuffs some comments near this code explaining the reasoning for this. --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
On Wed, Oct 7, 2009 at 21:25, Jeremy Orlow jor...@chromium.org wrote: I could't imagine many users understanding a feature like this much less finding it particularly useful. That's right, an average user would be only confused. Just exposing this info (cpu-hungriness) to extensions seems interesting. What are the use cases? Well, I just didn't notice that the tab was using a lot of cpu (idle GMail tab). The system was responsive, as well as the browser itself and all tabs. But when you have other cpu-intensive tasks running in the background (and I had) such a tab drains the resources. The technical side (exposing the info to extensions) doesn't seem too hard. I'm thinking about implementing it. I'm not sure about the UI. For me it could be even something on the extension shelf (support for that already exists). Then it would be nice if I could kill the renderer process using too much resources, or even restart it. --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
My preference would be to place them inside Chromium Framework.framework, then. If you need to, you can put them inside Chromium Helper.app/Contents/MacOS instead, but I'm trying really hard to minimize the amount of stuff inside the app and the helper app. You can get the framework as a bundle from mac_util::MainAppBundle() since r28262. If you put the dylibs in the framework and they depend on one another, you may need to switch them to refer to each other using @loader_path instead of @executable_path. Mark scherkus wrote: On Wed, Oct 7, 2009 at 12:17 PM, Mark Mentovai m...@chromium.org wrote: Which processes need to load these libraries? Render process. Are these libraries loaded at launch time or by dlopen? dlopen() Mark --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
On Wed, Oct 7, 2009 at 12:25 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 7, 2009 at 11:45 AM, Charles Reis cr...@chromium.org wrote: On Wed, Oct 7, 2009 at 11:13 AM, Andrew Scherkus scher...@chromium.orgwrote: It'd be nice to have a non-distracting visual indicator, but to play the devil's advocate... What about intentionally CPU intensive sites that use canvas, video, WebGL? What about scenarios where it's a plugin that's gone haywire? Could this be accomplished by an extension that displays a little CPU graph? I would love to see this as an extension-- just like the graph that Procexp.exe or the Windows Task Manager puts in the tray, only per tab in the location bar (getting its data from the Chrome Task Manager). Is that information available to extensions? On a grander scale, it would be great to also have a button to suspend a renderer process if I'm not using it at the moment. I'm sure there's a ton of complicated issues there, though-- it might suspend several seemingly unrelated tabs, the page(s) may have network requests in progress, Flash or a plugin could be to blame, etc, etc. I could't imagine many users understanding a feature like this much less finding it particularly useful. What are the use cases? Only power users, which is why I think such a button only belongs in an extension. (Sorry if that part wasn't clear.) Basically, I tend to have lots of tabs open, but I'm only using a small set at any time. That means I often find myself annoyed that Gmail or other CPU-heavy tabs are chewing up resources (or are making Hulu videos choppy) while I'm not using them. I end up having to kill the CPU-heavy tabs, but then I lose my context, as well as the visual reminder to get back to it later. This button would let the user pause CPU-heavy tabs without losing that context. This is mainly a problem on my laptop, where battery life is also important. Charlie Charlie On Wed, Oct 7, 2009 at 10:35 AM, Evan Martin e...@chromium.org wrote: We had also discussed putting icons indicating audio into tabs. That sounds crowded with icons, though: imaginably a game could have facicon, Unicode symbols, CPU load, audio, and the x displayed. I worry there just aren't enough pixels to display all the relevant information. On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: SVN Stable Tree Path for 3.0.195.25
(adding people more familiar with the release process...) On Wed, Oct 7, 2009 at 20:16, Amit Kishnani akish...@adobe.com wrote: Hey Elliot, thanks for quick turnaround. the trunk (svn) : http://src.chromium.org/svn/trunk/src/chrome/VERSION is MAJOR=4 MINOR=0 BUILD=222 PATCH=1 but I am looking for stable channel - 3.0.195.125 release instead of dev channel, please let me know if there is svn repository link with that version stamp. Thanks! Amit. -Original Message- From: e...@google.com [mailto:e...@google.com] On Behalf Of Elliot Glaysher (Chromium) Sent: Wednesday, October 07, 2009 10:41 AM To: Amit Kishnani Cc: Chromium-dev Subject: Re: [chromium-dev] SVN Stable Tree Path for 3.0.195.25 The latest source is in trunk, not a specific release branch. -- Elliot On Tue, Oct 6, 2009 at 12:34 PM, Amit Kishnani akish...@adobe.com wrote: Hey Guys, what is difference between these releases 3.0.190.2 3.0.195.25 i can get to SVN source tree to read access for code tree 3.0.190.2 using the following svn repository url http://src.chromium.org/svn/releases/3.0.190.2/src/ i want to make sure i am getting the latest stable source tree , is there a better svn url to get latest 3.0.195.25. please advise. Thanks, Amit. --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
Pawel, I was responding to the idea of suspending a tab. I agree that exposing this information to extensions wouldn't be too hard and could be quite useful. On Wed, Oct 7, 2009 at 12:37 PM, Charles Reis cr...@chromium.org wrote: On Wed, Oct 7, 2009 at 12:25 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 7, 2009 at 11:45 AM, Charles Reis cr...@chromium.org wrote: On Wed, Oct 7, 2009 at 11:13 AM, Andrew Scherkus scher...@chromium.orgwrote: It'd be nice to have a non-distracting visual indicator, but to play the devil's advocate... What about intentionally CPU intensive sites that use canvas, video, WebGL? What about scenarios where it's a plugin that's gone haywire? Could this be accomplished by an extension that displays a little CPU graph? I would love to see this as an extension-- just like the graph that Procexp.exe or the Windows Task Manager puts in the tray, only per tab in the location bar (getting its data from the Chrome Task Manager). Is that information available to extensions? On a grander scale, it would be great to also have a button to suspend a renderer process if I'm not using it at the moment. I'm sure there's a ton of complicated issues there, though-- it might suspend several seemingly unrelated tabs, the page(s) may have network requests in progress, Flash or a plugin could be to blame, etc, etc. I could't imagine many users understanding a feature like this much less finding it particularly useful. What are the use cases? Only power users, which is why I think such a button only belongs in an extension. (Sorry if that part wasn't clear.) Basically, I tend to have lots of tabs open, but I'm only using a small set at any time. That means I often find myself annoyed that Gmail or other CPU-heavy tabs are chewing up resources (or are making Hulu videos choppy) while I'm not using them. I end up having to kill the CPU-heavy tabs, but then I lose my context, as well as the visual reminder to get back to it later. This button would let the user pause CPU-heavy tabs without losing that context. This is mainly a problem on my laptop, where battery life is also important. That makes sense, but I suspect the cost would be fairly significant (even if it's just an extension API) compared to the benefit users would get. One random, related idea: if a page is in the background, maybe we should be rate limiting their timers? Charlie Charlie On Wed, Oct 7, 2009 at 10:35 AM, Evan Martin e...@chromium.org wrote: We had also discussed putting icons indicating audio into tabs. That sounds crowded with icons, though: imaginably a game could have facicon, Unicode symbols, CPU load, audio, and the x displayed. I worry there just aren't enough pixels to display all the relevant information. On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: detecting tabs using a lot of CPU?
On Wed, Oct 7, 2009 at 12:35 PM, Charles Reis cr...@google.com wrote: Only power users, which is why I think such a button only belongs in an extension. (Sorry if that part wasn't clear.) Basically, I tend to have lots of tabs open, but I'm only using a small set at any time. That means I often find myself annoyed that Gmail or other CPU-heavy tabs are chewing up resources (or are making Hulu videos choppy) while I'm not using them. I end up having to kill the CPU-heavy tabs, but then I lose my context, as well as the visual reminder to get back to it later. This button would let the user pause CPU-heavy tabs without losing that context. This is mainly a problem on my laptop, where battery life is also important. You could imagine stuffing a kill -STOP item into the context menu on the task manager. Unlikely that'd live in a user-facing Chrome though. --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
What is @loader_path relative off of? On Wed, Oct 7, 2009 at 12:35 PM, Mark Mentovai m...@chromium.org wrote: My preference would be to place them inside Chromium Framework.framework, then. If you need to, you can put them inside Chromium Helper.app/Contents/MacOS instead, but I'm trying really hard to minimize the amount of stuff inside the app and the helper app. You can get the framework as a bundle from mac_util::MainAppBundle() since r28262. If you put the dylibs in the framework and they depend on one another, you may need to switch them to refer to each other using @loader_path instead of @executable_path. Mark scherkus wrote: On Wed, Oct 7, 2009 at 12:17 PM, Mark Mentovai m...@chromium.org wrote: Which processes need to load these libraries? Render process. Are these libraries loaded at launch time or by dlopen? dlopen() Mark --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html sorta relative to the thing loading this TVL On Wed, Oct 7, 2009 at 3:52 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: What is @loader_path relative off of? On Wed, Oct 7, 2009 at 12:35 PM, Mark Mentovai m...@chromium.org wrote: My preference would be to place them inside Chromium Framework.framework, then. If you need to, you can put them inside Chromium Helper.app/Contents/MacOS instead, but I'm trying really hard to minimize the amount of stuff inside the app and the helper app. You can get the framework as a bundle from mac_util::MainAppBundle() since r28262. If you put the dylibs in the framework and they depend on one another, you may need to switch them to refer to each other using @loader_path instead of @executable_path. Mark scherkus wrote: On Wed, Oct 7, 2009 at 12:17 PM, Mark Mentovai m...@chromium.org wrote: Which processes need to load these libraries? Render process. Are these libraries loaded at launch time or by dlopen? dlopen() Mark --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
Albert J. Wong wrote: What is @loader_path relative off of? @loader_path is the directory that contains whatever is being loaded. While loading the main executable, @loader_path is equivalent to @executable_path. If your three dylibs refer to one another and are always in the same directory, they can refer to one another by @loader_path/libwhatever.dylib. Mark --~--~-~--~~~---~--~~ 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: Local State / Preferences distinction
Actually, the original distinction was stuff that could be shared across computers and stuff that couldn't be shared (i.e., local state). I think originally this was for the difference between stuff that a mounted home directory would sync and stuff that wouldn't sync. In practice, I think it's used for both, which is all the more reason to merge them. On Wed, Oct 7, 2009 at 12:46 PM, Evan Stade est...@chromium.org wrote: I was looking at http://crbug.com/19061, which is a bug Tony filed to merge the Local State and Preferences files. Both files hold user preferences, but the idea is that Local State holds prefs that are common to all user profiles, and Preferences is unique to each user (thus it is in the Default/ user profile directory). We don't actually support using multiple user profiles though, it seems. The win for combining them is to remove another file read on startup. Also, the distinction is confusing and some stuff is arguably in the wrong place (e.g. browser window dimensions are in Local State). However, the loss is that we will lose the ability to have multiple user profiles in one user data directory (don't know what our plans are for this, if any). This patch is pretty large so I'd like some feedback before starting it. -- Evan Stade --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] The Great Webkit Comparison Table
On quirksmode, sponsored by Google, apparently: http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ 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: Local State / Preferences distinction
On Wed, Oct 7, 2009 at 12:52 PM, Tony Chang t...@chromium.org wrote: Actually, the original distinction was stuff that could be shared across computers and stuff that couldn't be shared (i.e., local state). I think originally this was for the difference between stuff that a mounted home directory would sync and stuff that wouldn't sync. In practice, I think it's used for both, which is all the more reason to merge them. This comes up with the quasi-defunct profile system. Local State is supposed to be cross-profile, while the stuff in Default is your profile data. The safe browsing data in Local State should always stay with the safe browsing files, which currently stay in user-data-dir. I suspect the metrics stuff should also be cross profile. Do we need this profile support? The interface has been hidden behind a command line flag enable-udd-profiles. Is it time to rip all of this profile stuff out? Brett --~--~-~--~~~---~--~~ 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: Local State / Preferences distinction
The quasi-defunct profile system that uses the enable-udd-profiles still has a separate Local State file and safe browsing databases because it used different user data directory (udd). This change seems orthogonal to the profile system as it is currently implemented. We can resplit the Preferences file in the future if needed (and once the actual split is clear or needed). On Wed, Oct 7, 2009 at 1:16 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Oct 7, 2009 at 12:52 PM, Tony Chang t...@chromium.org wrote: Actually, the original distinction was stuff that could be shared across computers and stuff that couldn't be shared (i.e., local state). I think originally this was for the difference between stuff that a mounted home directory would sync and stuff that wouldn't sync. In practice, I think it's used for both, which is all the more reason to merge them. This comes up with the quasi-defunct profile system. Local State is supposed to be cross-profile, while the stuff in Default is your profile data. The safe browsing data in Local State should always stay with the safe browsing files, which currently stay in user-data-dir. I suspect the metrics stuff should also be cross profile. Do we need this profile support? The interface has been hidden behind a command line flag enable-udd-profiles. Is it time to rip all of this profile stuff out? Brett --~--~-~--~~~---~--~~ 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: Local State / Preferences distinction
On Wed, Oct 7, 2009 at 1:26 PM, Tony Chang t...@chromium.org wrote: The quasi-defunct profile system that uses the enable-udd-profiles still has a separate Local State file and safe browsing databases because it used different user data directory (udd). This change seems orthogonal to the profile system as it is currently implemented. We can resplit the Preferences file in the future if needed (and once the actual split is clear or needed). I couldn't figure out how it works, but it looks like the UDD profile switching is broken on WIndows (the submenu doesn't even pop anything up for me) and the code I was thinking of in the ProfileManager seems to never be used. This mess makes me very sad. Brett --~--~-~--~~~---~--~~ 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: Chrome Layout Tests Task Force status updates 10/6
The thing about the media layout tests is ~2 weeks ago all of them were failing. We've flipped switched to get them running and even after disabling a bunch due to flakiness we're still ahead -- just need to keep up the fixes. Andrew On Wed, Oct 7, 2009 at 9:36 AM, Peter Kasting pkast...@chromium.org wrote: BTW, I'm really sad that during my two days of sheriffing I added like 100 new lines to the test expectations file -- basically something new failed once every couple of minutes. There's still tons of flakiness. I tried to send mail about some of the bigger buckets but it was all over the place :( 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] buildbot failure in Chromium on Linux Builder (ChromeOS), revision 28326
Automatically closing tree for compile on Linux Builder (ChromeOS) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/4193 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29 --= Automatically closing tree for compile on Linux Builder (ChromeOS) =-- Revision: 28325, 28326 Blame list: d...@chromium.org,rafa...@chromium.org Buildbot waterfall: http://build.chromium.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: detecting tabs using a lot of CPU?
Umm... shouldn't we be looking into why the tab is taking so much CPU? :) For example, back in April I saw a similar thing happen on Facebook and with WinDbg found that WebKit was simply running in an infinite loop. The WebKit team jumped on this and submitted a fix just 2 days after I reported it ( https://bugs.webkit.org/show_bug.cgi?id=25312). - Finnur. On Wed, Oct 7, 2009 at 12:47, Evan Martin e...@chromium.org wrote: On Wed, Oct 7, 2009 at 12:35 PM, Charles Reis cr...@google.com wrote: Only power users, which is why I think such a button only belongs in an extension. (Sorry if that part wasn't clear.) Basically, I tend to have lots of tabs open, but I'm only using a small set at any time. That means I often find myself annoyed that Gmail or other CPU-heavy tabs are chewing up resources (or are making Hulu videos choppy) while I'm not using them. I end up having to kill the CPU-heavy tabs, but then I lose my context, as well as the visual reminder to get back to it later. This button would let the user pause CPU-heavy tabs without losing that context. This is mainly a problem on my laptop, where battery life is also important. You could imagine stuffing a kill -STOP item into the context menu on the task manager. Unlikely that'd live in a user-facing Chrome though. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] gclient sync getting stuck
I'm trying to run gclient sync, and it seems to get stuck on updating
webkit:
dhcp-172-31-134-235:Chromium nickbaum$ gclient sync
running 'svn update /Users/Shared/Chromium/src-internal' in
'/Users/Shared/Chromium'
At revision 3449.
running 'svn update
/Users/Shared/Chromium/src/chrome/personalization/sync' in
'/Users/Shared/Chromium'
At revision 3449.
running 'svn update /Users/Shared/Chromium/src/third_party/WebKit
--revision 27313' in '/Users/Shared/Chromium'
The CPU for Terminal is at 0. gclient cleanup actually gives me an error:
running 'svn cleanup' in
'/Users/Shared/Chromium/src/third_party/pywebsocket'
Traceback (most recent call last):
File /Users/nickbaum/depot_tools/gclient.py, line 1192, in module
result = Main(sys.argv)
File /Users/nickbaum/depot_tools/gclient.py, line 1187, in Main
return DispatchCommand(command, options, args)
File /Users/nickbaum/depot_tools/gclient.py, line 1113, in
DispatchCommand
return command_map[command](options, args)
File /Users/nickbaum/depot_tools/gclient.py, line 896, in DoCleanup
return client.RunOnDeps('cleanup', args)
File /Users/nickbaum/depot_tools/gclient.py, line 700, in RunOnDeps
scm.RunCommand(command, self._options, args, file_list)
File /Users/nickbaum/depot_tools/gclient_scm.py, line 91, in RunCommand
return getattr(self, command)(options, args, file_list)
File /Users/nickbaum/depot_tools/gclient_scm.py, line 194, in cleanup
RunSVN(command, os.path.join(self._root_dir, self.relpath))
File /Users/nickbaum/depot_tools/gclient_scm.py, line 519, in RunSVN
gclient_utils.SubprocessCall(c, in_directory)
File /Users/nickbaum/depot_tools/gclient_utils.py, line 175, in
SubprocessCall
SubprocessCallAndFilter(command, in_directory, True, True, fail_status)
File /Users/nickbaum/depot_tools/gclient_utils.py, line 207, in
SubprocessCallAndFilter
shell=(sys.platform == 'win32'), stdout=subprocess.PIPE)
File
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/subprocess.py,
line 593, in __init__
errread, errwrite)
File
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/subprocess.py,
line 1079, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory:
'/Users/Shared/Chromium/src/third_party/pywebsocket'
Any suggestions before I delete the webkit and third party directories and
try from scratch?
Thanks,
-Nick
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Mac10.5 Tests, revision 28352
Automatically closing tree for unit_tests on Mac10.5 Tests http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Tests/builds/6250 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Mac10.5%20Tests --= Automatically closing tree for unit_tests on Mac10.5 Tests =-- Revision: 28350, 28351, 28352 Blame list: m...@chromium.org,sh...@chromium.org,t...@chromium.org Buildbot waterfall: http://build.chromium.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] GYP and cross-compiling
If you don't care about gyp or cross-compiling, you can skip this message. I've been experimenting with adding host support for cross-compiling into gyp. By this, I mean being able to use the cross-compiler to build Chrome, but still using the host compiler for build tools. Regular Chrome, with v8 snapshotting and nacl disabled doesn't currently need this but for example if you enable nacl, or compile the chromeos version you end up building tools necessary to generate headers or source files needed for the target (e.g. protocol buffer compiler). Currently if you use a cross-compiler, those tools are built for the target, so you can't run them. What I've done is tweak the make generator to add an option on every target to compile it for host, target or both. Here are the CLs: - chrome side: http://codereview.chromium.org/265031 - gyp side: http://codereview.chromium.org/271019 Basically on the make generator side, every rule can be duplicated, for the host version and the target version, based on a parameter on the gyp rule (default is target only). Furthermore, cflags, ldflags and libraries are cut into a common part, a host-specific part and a target-specific part. It keeps target objects and host objects in separate trees. It's very crude, but it solves the problem for the protobuf compiler, which is promising. Also, it makes the changes to the gyp definitions extremely simple an non-intrusive (see chrome-side patch) - one of the simplest methods I've ever seen for this sort of things. I think this solution should also fix the nacl issues. I'm not yet sure about v8 snapshotting. Several issues: 1- It's basically a big hack. The level of control between host and target compiles boils down to compile and link flags (and compiler/linker). No way to have different dependencies, different files to compile etc. 2- Generally, target rules depend on other target rules, host rules depend on other host rules. The way you make the bridge (when you need a target rule to depend on executing the host tool) is by having the host tool installed at a particular location, and have the target rule depend on that file (which is the way the protobuf compiler is called now, but that's very limited). 3- Well, it only works for the make build. The current patch probably breaks the scons one. XCode and MSVS should be mostly unaffected - but won't supposrt this, which I don't think is a big deal. Anyway I'm looking for feedback on the above, and guidance on the following: What I'd like to do is find a way to keep a similar syntax for host vs target selection, but change the way cflags etc. differences are dealt with into something that looks more like conditions which would allow more control over deps, sources, etc. which would make it I think a very powerful and general way of dealing with this whole thing. To you gyp gurus, do you see a simple way of doing this ? Thanks, Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium Builder (dbg), revision 28369
Automatically closing tree for compile on Chromium Builder (dbg) http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/11678 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29 --= Automatically closing tree for compile on Chromium Builder (dbg) =-- Revision: 28368, 28369 Blame list: a...@chromium.org,ma...@chromium.org Buildbot waterfall: http://build.chromium.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: GYP and cross-compiling
It seems like another approach would be to use the target types to indicate if the library or executable is for the host or native (ie-add types for host vs. target), then you could use target_conditions to have different flags. TVL On Wed, Oct 7, 2009 at 10:06 PM, Antoine Labour pi...@google.com wrote: If you don't care about gyp or cross-compiling, you can skip this message. I've been experimenting with adding host support for cross-compiling into gyp. By this, I mean being able to use the cross-compiler to build Chrome, but still using the host compiler for build tools. Regular Chrome, with v8 snapshotting and nacl disabled doesn't currently need this but for example if you enable nacl, or compile the chromeos version you end up building tools necessary to generate headers or source files needed for the target (e.g. protocol buffer compiler). Currently if you use a cross-compiler, those tools are built for the target, so you can't run them. What I've done is tweak the make generator to add an option on every target to compile it for host, target or both. Here are the CLs: - chrome side: http://codereview.chromium.org/265031 - gyp side: http://codereview.chromium.org/271019 Basically on the make generator side, every rule can be duplicated, for the host version and the target version, based on a parameter on the gyp rule (default is target only). Furthermore, cflags, ldflags and libraries are cut into a common part, a host-specific part and a target-specific part. It keeps target objects and host objects in separate trees. It's very crude, but it solves the problem for the protobuf compiler, which is promising. Also, it makes the changes to the gyp definitions extremely simple an non-intrusive (see chrome-side patch) - one of the simplest methods I've ever seen for this sort of things. I think this solution should also fix the nacl issues. I'm not yet sure about v8 snapshotting. Several issues: 1- It's basically a big hack. The level of control between host and target compiles boils down to compile and link flags (and compiler/linker). No way to have different dependencies, different files to compile etc. 2- Generally, target rules depend on other target rules, host rules depend on other host rules. The way you make the bridge (when you need a target rule to depend on executing the host tool) is by having the host tool installed at a particular location, and have the target rule depend on that file (which is the way the protobuf compiler is called now, but that's very limited). 3- Well, it only works for the make build. The current patch probably breaks the scons one. XCode and MSVS should be mostly unaffected - but won't supposrt this, which I don't think is a big deal. Anyway I'm looking for feedback on the above, and guidance on the following: What I'd like to do is find a way to keep a similar syntax for host vs target selection, but change the way cflags etc. differences are dealt with into something that looks more like conditions which would allow more control over deps, sources, etc. which would make it I think a very powerful and general way of dealing with this whole thing. To you gyp gurus, do you see a simple way of doing this ? Thanks, Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] How expensive is setting a crash key for breakpad?
In fixing a Mac bug, I recently added a layer to intercept -[NSApplication sendAction:to:from:] and make sure a certain message wasn't forwarded if the target was known to be freed. Since this is sort of a core function for event dispatch, now we're seeing crashdumps with my new method on the stack. I don't think it's a new problem. In researching it, I realize that it maybe gives us a hook for tracking down some very random browser crashers we see, where there's a stack of generic Cocoa methods. I could register a crash key which would report the action that is being sent, and the class of the sender. If there is anything interesting which could be derived about the potentially-freed target, that could be reported, too. AFAICT, it's a matter of calling SetCrashKeyValue() and ClearCrashKeyValue() at the appropriate spots. AFAICT, we don't dynamically call SetCrashKeyValue() anywhere, we mostly just call it a couple times at startup. Is the approach I suggest feasible? -scott PS: The kind of backtrace I'm speaking of are those associated with http://crbug.com/13111 . They used to look like: 0x9518c688 [libobjc.A.dylib+ 0x00015688] objc_msgSend 0x953fddcb [AppKit + 0x00111dcb] -[NSControl sendAction:to:] 0x953fdc51 [AppKit + 0x00111c51] -[NSCell _sendActionFrom:] 0x953fd2aa [AppKit + 0x001112aa] -[NSCell trackMouse:inRect:ofView:untilMouseUp:] 0x953fcafd [AppKit + 0x00110afd] -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] 0x953fc3b7 [AppKit + 0x001103b7] -[NSControl mouseDown:] 0x953faaf6 [AppKit + 0x0010eaf6] -[NSWindow sendEvent:] 0x953c76a4 [AppKit + 0x000db6a4] -[NSApplication sendEvent:] 0x95324fe6 [AppKit + 0x00038fe6] -[NSApplication run] 0x02517eb2 [Google Chrome Framework- message_pump_mac.mm:482] base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) 0x02517f97 [Google Chrome Framework- message_pump_mac.mm:146] base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) 0x025148f3 [Google Chrome Framework- message_loop.cc:199] MessageLoop::Run() 0x0218a0da [Google Chrome Framework- browser_main.cc:152] BrowserMain(MainFunctionParams const) 0x020cadcf [Google Chrome Framework- chrome_dll_main.cc:603] ChromeMain 0x1fc5 [Google Chrome + 0x0fc5] Now they'll have a line like this at the top: 0x000ec978 [Google Chrome Framework- chrome_application_mac.mm:83] -[CrApplication sendAction:to:from:] That's where I can hook in to record a bit for breakpad. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
