[chromium-dev] Re: new Linux custom frame

[Evan Martin]

mmoss politely informed me off-list that the dev channel release will
have the proper padding.  Please disregard my last message.  :)

On Thu, Aug 6, 2009 at 10:42 AM, Evan Martin wrote:
> Yes, it's too bad that our dev channel release got bad padding on the
> buttons.  I've seen a few comments online to the effect of "this is so
> ugly how can I turn it off".  I fear people will turn it off then and
> not discover it has improved since.
>
> I think we're gonna tweak them one more time before we stop touching
> them, though.
>
> On Thu, Aug 6, 2009 at 10:29 AM, Paweł Hajdan
> Jr. wrote:
>> I just saw the new Linux custom frame buttons when compiled today from
>> trunk. With the new increased padding it looks really well. I like 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: gyp failing while triggering gclient sync in linux with git

[Mohamed Mansour]

What is stopping us doing "Massive" line endings commit for all the files in
our repository in src/chrome.
+1 on the presubmit check! Is there a way to force Visual Studio "Solutions"
or "Projects" to always save line endings in LF generated via gyp.

-- Mohamed Mansour


On Fri, Aug 7, 2009 at 1:48 AM, Bradley Nelson wrote:

> Yeah we should certainly handle this better.This was a known thing, but
> I've called it out in this gyp issue:
> http://code.google.com/p/gyp/issues/detail?id=38
>
> I do like have consistent line endings, but the error message leaves
> something to be desired (not to mention being different on each platform
> :-).
> Shouldn't be a big deal to fix.
>
> -BradN
>
>
> On Thu, Aug 6, 2009 at 10:39 PM, Evan Martin  wrote:
>
>> I am a little surprised that Python's "eval" isn't line-ending agnostic.
>> This thread
>>
>> http://mail.python.org/pipermail/pythonmac-sig/2004-September/011638.html
>> suggests it doesn't like \r even on Windows and offers a simple
>> workaround when reading the file:
>>  '\n'.join(s.splitlines())
>>
>> On Thu, Aug 6, 2009 at 9:28 PM, Bradley Nelson
>> wrote:
>> > Yes Mohamed, please do. Which files had the dos line endings?
>> > We should really add a presubmit check...
>> > -BradN
>> >
>> > On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour <
>> m0.interact...@gmail.com>
>> > wrote:
>> >>
>> >> Ah thank you Dan! It worked! I guess I should commit the line ending
>> then?
>> >> -- Mohamed Mansour
>> >>
>> >>
>> >> On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel  wrote:
>> >>>
>> >>> Please check to make sure the python scripts have UNIX
>> >>> line endings, not DOS ones.
>> >>
>> >>
>> >>
>> >
>> >
>> > >> >
>> >
>>
>
>

--~--~-~--~~~---~--~~
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 failing while triggering gclient sync in linux with git

[Bradley Nelson]

Yeah we should certainly handle this better.This was a known thing, but I've
called it out in this gyp issue:
http://code.google.com/p/gyp/issues/detail?id=38

I do like have consistent line endings, but the error message leaves
something to be desired (not to mention being different on each platform
:-).
Shouldn't be a big deal to fix.

-BradN


On Thu, Aug 6, 2009 at 10:39 PM, Evan Martin  wrote:

> I am a little surprised that Python's "eval" isn't line-ending agnostic.
> This thread
>  http://mail.python.org/pipermail/pythonmac-sig/2004-September/011638.html
> suggests it doesn't like \r even on Windows and offers a simple
> workaround when reading the file:
>  '\n'.join(s.splitlines())
>
> On Thu, Aug 6, 2009 at 9:28 PM, Bradley Nelson
> wrote:
> > Yes Mohamed, please do. Which files had the dos line endings?
> > We should really add a presubmit check...
> > -BradN
> >
> > On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour <
> m0.interact...@gmail.com>
> > wrote:
> >>
> >> Ah thank you Dan! It worked! I guess I should commit the line ending
> then?
> >> -- Mohamed Mansour
> >>
> >>
> >> On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel  wrote:
> >>>
> >>> Please check to make sure the python scripts have UNIX
> >>> line endings, not DOS ones.
> >>
> >>
> >>
> >
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
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 debug "Aw, Snap!" error

[Evan Martin]

http://code.google.com/p/chromium/wiki/LinuxDebugging has a section on
debugging renderers.  I'd try the --single-process trick I just added
to it.  (Despite the page having Linux in the title the gdb tips
mostly apply to a Mac as well.)

On Thu, Aug 6, 2009 at 9:43 PM, n179911 wrote:
>
> Hi,
>
> When I load a page on chromium that I run on debugger,I get 'Aw, Snap!
> Something went wrong while displaying this webpage.' error.
>
> And I see this in the console:
> WebCore::FrameView::paintContents(WebCore::GraphicsContext*, const
> WebCore::IntRect&))
> LEAK: 1899 RenderObject
> LEAK: 1 Page
> LEAK: 19 Frame
> LEAK: 1 SubresourceLoader
> LEAK: 141 CachedResource
> LEAK: 4197 WebCoreNode
> [1487:2067:12214450218929:ERROR:../chrome/common/temp_scaffolding_stubs.h(75)]
> Not implemented reached in bool
> printing::PrintViewManager::OnRenderViewGone(RenderViewHost*)
>
> My question is how can i debug problem like this? Is there a stack
> trace or core dump for situation like this?
>
> 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: gyp failing while triggering gclient sync in linux with git

[Evan Martin]

I am a little surprised that Python's "eval" isn't line-ending agnostic.
This thread
  http://mail.python.org/pipermail/pythonmac-sig/2004-September/011638.html
suggests it doesn't like \r even on Windows and offers a simple
workaround when reading the file:
  '\n'.join(s.splitlines())

On Thu, Aug 6, 2009 at 9:28 PM, Bradley Nelson wrote:
> Yes Mohamed, please do. Which files had the dos line endings?
> We should really add a presubmit check...
> -BradN
>
> On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour 
> wrote:
>>
>> Ah thank you Dan! It worked! I guess I should commit the line ending then?
>> -- Mohamed Mansour
>>
>>
>> On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel  wrote:
>>>
>>> Please check to make sure the python scripts have UNIX
>>> line endings, not DOS ones.
>>
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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 debug "Aw, Snap!" error

[Dan Kegel]

On Thu, Aug 6, 2009 at 9:43 PM, n179911 wrote:
> When I load a page on chromium that I run on debugger,I get 'Aw, Snap!

What page?

> My question is how can i debug problem like this? Is there a stack
> trace or core dump for situation like this?

If you installed the dev channel version from
http://dev.chromium.org/getting-involved/dev-channel
and you checked the 'send feedback' button,
we'll get a crash log.   We look at the top N
crashes every dev channel release and try to
fix them.

(You can even put messages in the environment,
e.g. by starting chrome with
  FOOBAR="every time I click on the frobnicator, it crashes!"
my_email=n179...@gmail.com google-chrome
but we won't see them unless we happen to be
looking at that exact crash report, and happen to run strings on
the minidump :-)
- Dan

--~--~-~--~~~---~--~~
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 to debug "Aw, Snap!" error

[n179911]

Hi,

When I load a page on chromium that I run on debugger,I get 'Aw, Snap!
Something went wrong while displaying this webpage.' error.

And I see this in the console:
WebCore::FrameView::paintContents(WebCore::GraphicsContext*, const
WebCore::IntRect&))
LEAK: 1899 RenderObject
LEAK: 1 Page
LEAK: 19 Frame
LEAK: 1 SubresourceLoader
LEAK: 141 CachedResource
LEAK: 4197 WebCoreNode
[1487:2067:12214450218929:ERROR:../chrome/common/temp_scaffolding_stubs.h(75)]
Not implemented reached in bool
printing::PrintViewManager::OnRenderViewGone(RenderViewHost*)

My question is how can i debug problem like this? Is there a stack
trace or core dump for situation like this?

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: gyp failing while triggering gclient sync in linux with git

[Bradley Nelson]

Yes Mohamed, please do. Which files had the dos line endings?We should
really add a presubmit check...

-BradN


On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour wrote:

> Ah thank you Dan! It worked! I guess I should commit the line ending then?
> -- Mohamed Mansour
>
>
>
> On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel  wrote:
>
>> Please check to make sure the python scripts have UNIX
>> line endings, not DOS ones.
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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 failing while triggering gclient sync in linux with git

[Mohamed Mansour]

Ah thank you Dan! It worked! I guess I should commit the line ending then?
-- Mohamed Mansour


On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel  wrote:

> Please check to make sure the python scripts have UNIX
> line endings, not DOS ones.
>

--~--~-~--~~~---~--~~
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 failing while triggering gclient sync in linux with git

[Mohamed Mansour]

I don't believe I have any GYP_* env set:

m...@m0-desktop:~/chrome/src$ echo $PATH
~/chrome/depot_tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games


I don't have a directory called ~/.gyp/

m...@m0-desktop:~/chrome/src$ echo $PATH
~/chrome/depot_tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games


I got version 579

m...@m0-desktop:~/chrome/src/tools/gyp$ svn infoPath: .
URL: http://gyp.googlecode.com/svn/trunk
Repository Root: http://gyp.googlecode.com/svn
Repository UUID: 78cadc50-ecff-11dd-a971-7dbc132099af
Revision: 579
Node Kind: directory
Schedule: normal
Last Changed Author: gspen...@google.com
Last Changed Rev: 579
Last Changed Date: 2009-08-05 12:49:34 -0400 (Wed, 05 Aug 2009)


I really don't understand what is wrong.

-- Mohamed Mansour



On Fri, Aug 7, 2009 at 12:08 AM, Thomas Van Lenten 
 wrote:

> What version of GYP do you have in tools?
> Do you have any GYP_* env var set?
>
> Do you have anything in ~/.gyp/*
>
> TVL
>
>
> On Thu, Aug 6, 2009 at 11:58 PM, Mohamed Mansour  > wrote:
>
>> Tonight I was trying to sync my project so I did "git pull" and it worked
>> fine, then I did "gclient sync" as well as --force. But gyp is failing:
>>
>> m...@m0-desktop:~/chrome/src$ gclient sync found .git directory;
>> skipping src
>>
>>  running '/usr/bin/python src/tools/gyp/gyp_chromium' in
>> '/home/m0/chrome'
>> Updating projects from gyp files...
>> Traceback (most recent call last):
>>   File "src/tools/gyp/gyp_chromium", line 34, in 
>> sys.exit(gyp.main(args))
>>   File "src/tools/gyp/pylib/gyp/__init__.py", line 262, in main
>> params)
>>   File "src/tools/gyp/pylib/gyp/__init__.py", line 75, in Load
>> depth, generator_input_info)
>>   File "src/tools/gyp/pylib/gyp/input.py", line 1644, in Load
>> LoadTargetBuildFile(build_file, data, aux_data, variables, includes,
>> depth)
>>   File "src/tools/gyp/pylib/gyp/input.py", line 280, in
>> LoadTargetBuildFile
>> includes, depth)
>>   File "src/tools/gyp/pylib/gyp/input.py", line 280, in
>> LoadTargetBuildFile
>> includes, depth)
>>   File "src/tools/gyp/pylib/gyp/input.py", line 224, in
>> LoadTargetBuildFile
>> includes, True)
>>   File "src/tools/gyp/pylib/gyp/input.py", line 129, in LoadOneBuildFile
>> build_file_data = eval(build_file_contents, {'__builtins__': None},
>> None)
>>   File "/home/m0/chrome/src/chrome/third_party/hunspell/hunspell.gyp",
>> line 4
>>
>> ^
>> SyntaxError: invalid syntax
>> failed to run command: /usr/bin/python src/tools/gyp/gyp_chromium
>>
>>
>> I made sure I have no local changes (fresh out of git)
>>
>> m...@m0-desktop:~/chrome/src$ git log
>> commit 0954eb9b2987d50c54cb9c62ba3dfdeec1f1b01b
>> Author: gspen...@google.com > @0039d316-1c4b-4281-b951-d872f2087c98>
>> Date:   Fri Aug 7 03:38:01 2009 +
>>
>> This adds a stub for the mac installer so that the gyp generation
>> won't fail on Macs.
>> Review URL: http://codereview.chromium.org/165109
>>
>> git-svn-id: svn://svn.chromium.org/chrome/trunk/s...@22717
>>  0039d316-1c4b-4281-b951-d872f2087c98
>>
>>
>> But I still get the error. My "git status" is:
>>
>> m...@m0-desktop:~/chrome/src$ git status
>>
>> # On branch trunk# Untracked files:
>> #   (use "git add ..." to include in what will be committed)
>> #
>> # chrome/test/data/layout_tests/LayoutTests/
>> # valgrind-20090715/
>> # valgrind.tmp/
>> nothing added to commit but untracked files present (use "git add" to
>> track)
>>
>>
>> I really don't understand why it is happening, I diffed my hunspell.gyp
>> wrt to the version online and they are identical.
>>
>> Any help is appreciated, I would like to work a bit this weekend but
>> valgrind requires linux and I can't seem to gclient sync it :/
>>
>>
>> Thanks!
>>
>> -- Mohamed Mansour
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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 failing while triggering gclient sync in linux with git

[Dan Kegel]

Please check to make sure the python scripts have UNIX
line endings, not DOS ones.

--~--~-~--~~~---~--~~
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 failing while triggering gclient sync in linux with git

[Thomas Van Lenten]

What version of GYP do you have in tools?
Do you have any GYP_* env var set?

Do you have anything in ~/.gyp/*

TVL


On Thu, Aug 6, 2009 at 11:58 PM, Mohamed Mansour
wrote:

> Tonight I was trying to sync my project so I did "git pull" and it worked
> fine, then I did "gclient sync" as well as --force. But gyp is failing:
>
> m...@m0-desktop:~/chrome/src$ gclient sync found .git directory;
> skipping src
>
>  running '/usr/bin/python src/tools/gyp/gyp_chromium' in
> '/home/m0/chrome'
> Updating projects from gyp files...
> Traceback (most recent call last):
>   File "src/tools/gyp/gyp_chromium", line 34, in 
> sys.exit(gyp.main(args))
>   File "src/tools/gyp/pylib/gyp/__init__.py", line 262, in main
> params)
>   File "src/tools/gyp/pylib/gyp/__init__.py", line 75, in Load
> depth, generator_input_info)
>   File "src/tools/gyp/pylib/gyp/input.py", line 1644, in Load
> LoadTargetBuildFile(build_file, data, aux_data, variables, includes,
> depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
> includes, depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
> includes, depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 224, in LoadTargetBuildFile
> includes, True)
>   File "src/tools/gyp/pylib/gyp/input.py", line 129, in LoadOneBuildFile
> build_file_data = eval(build_file_contents, {'__builtins__': None},
> None)
>   File "/home/m0/chrome/src/chrome/third_party/hunspell/hunspell.gyp", line
> 4
>
> ^
> SyntaxError: invalid syntax
> failed to run command: /usr/bin/python src/tools/gyp/gyp_chromium
>
>
> I made sure I have no local changes (fresh out of git)
>
> m...@m0-desktop:~/chrome/src$ git log
> commit 0954eb9b2987d50c54cb9c62ba3dfdeec1f1b01b
> Author: gspen...@google.com  @0039d316-1c4b-4281-b951-d872f2087c98>
> Date:   Fri Aug 7 03:38:01 2009 +
>
> This adds a stub for the mac installer so that the gyp generation won't
> fail on Macs.
> Review URL: http://codereview.chromium.org/165109
>
> git-svn-id: 
> svn://svn.chromium.org/chrome/trunk/s...@227170039d316-1c4b-4281-b951-d872f2087c98
>
>
> But I still get the error. My "git status" is:
>
> m...@m0-desktop:~/chrome/src$ git status
>
> # On branch trunk# Untracked files:
> #   (use "git add ..." to include in what will be committed)
> #
> # chrome/test/data/layout_tests/LayoutTests/
> # valgrind-20090715/
> # valgrind.tmp/
> nothing added to commit but untracked files present (use "git add" to
> track)
>
>
> I really don't understand why it is happening, I diffed my hunspell.gyp wrt
> to the version online and they are identical.
>
> Any help is appreciated, I would like to work a bit this weekend but
> valgrind requires linux and I can't seem to gclient sync it :/
>
>
> Thanks!
>
> -- Mohamed Mansour
>
> >
>

--~--~-~--~~~---~--~~
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 failing while triggering gclient sync in linux with git

[Jeremy Orlow]

Can you check out another client and see if that fixes it for you?

On Thu, Aug 6, 2009 at 8:58 PM, Mohamed Mansour wrote:

> Tonight I was trying to sync my project so I did "git pull" and it worked
> fine, then I did "gclient sync" as well as --force. But gyp is failing:
>
> m...@m0-desktop:~/chrome/src$ gclient sync found .git directory;
> skipping src
>
>  running '/usr/bin/python src/tools/gyp/gyp_chromium' in
> '/home/m0/chrome'
> Updating projects from gyp files...
> Traceback (most recent call last):
>   File "src/tools/gyp/gyp_chromium", line 34, in 
> sys.exit(gyp.main(args))
>   File "src/tools/gyp/pylib/gyp/__init__.py", line 262, in main
> params)
>   File "src/tools/gyp/pylib/gyp/__init__.py", line 75, in Load
> depth, generator_input_info)
>   File "src/tools/gyp/pylib/gyp/input.py", line 1644, in Load
> LoadTargetBuildFile(build_file, data, aux_data, variables, includes,
> depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
> includes, depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
> includes, depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 224, in LoadTargetBuildFile
> includes, True)
>   File "src/tools/gyp/pylib/gyp/input.py", line 129, in LoadOneBuildFile
> build_file_data = eval(build_file_contents, {'__builtins__': None},
> None)
>   File "/home/m0/chrome/src/chrome/third_party/hunspell/hunspell.gyp", line
> 4
>
> ^
> SyntaxError: invalid syntax
> failed to run command: /usr/bin/python src/tools/gyp/gyp_chromium
>
>
> I made sure I have no local changes (fresh out of git)
>
> m...@m0-desktop:~/chrome/src$ git log
> commit 0954eb9b2987d50c54cb9c62ba3dfdeec1f1b01b
> Author: gspen...@google.com  @0039d316-1c4b-4281-b951-d872f2087c98>
> Date:   Fri Aug 7 03:38:01 2009 +
>
> This adds a stub for the mac installer so that the gyp generation won't
> fail on Macs.
> Review URL: http://codereview.chromium.org/165109
>
> git-svn-id: 
> svn://svn.chromium.org/chrome/trunk/s...@227170039d316-1c4b-4281-b951-d872f2087c98
>
>
> But I still get the error. My "git status" is:
>
> m...@m0-desktop:~/chrome/src$ git status
>
> # On branch trunk# Untracked files:
> #   (use "git add ..." to include in what will be committed)
> #
> # chrome/test/data/layout_tests/LayoutTests/
> # valgrind-20090715/
> # valgrind.tmp/
> nothing added to commit but untracked files present (use "git add" to
> track)
>
>
> I really don't understand why it is happening, I diffed my hunspell.gyp wrt
> to the version online and they are identical.
>
> Any help is appreciated, I would like to work a bit this weekend but
> valgrind requires linux and I can't seem to gclient sync it :/
>
>
> Thanks!
>
> -- Mohamed Mansour
>
> >
>

--~--~-~--~~~---~--~~
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 failing while triggering gclient sync in linux with git

[Lei Zhang]

Working ok here with svn and the make build.

On Thu, Aug 6, 2009 at 8:58 PM, Mohamed Mansour wrote:
> Tonight I was trying to sync my project so I did "git pull" and it worked
> fine, then I did "gclient sync" as well as --force. But gyp is failing:
>
> m...@m0-desktop:~/chrome/src$ gclient sync
>  found .git directory; skipping src
>  running '/usr/bin/python src/tools/gyp/gyp_chromium' in
> '/home/m0/chrome'
> Updating projects from gyp files...
> Traceback (most recent call last):
>   File "src/tools/gyp/gyp_chromium", line 34, in 
>     sys.exit(gyp.main(args))
>   File "src/tools/gyp/pylib/gyp/__init__.py", line 262, in main
>     params)
>   File "src/tools/gyp/pylib/gyp/__init__.py", line 75, in Load
>     depth, generator_input_info)
>   File "src/tools/gyp/pylib/gyp/input.py", line 1644, in Load
>     LoadTargetBuildFile(build_file, data, aux_data, variables, includes,
> depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
>     includes, depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
>     includes, depth)
>   File "src/tools/gyp/pylib/gyp/input.py", line 224, in LoadTargetBuildFile
>     includes, True)
>   File "src/tools/gyp/pylib/gyp/input.py", line 129, in LoadOneBuildFile
>     build_file_data = eval(build_file_contents, {'__builtins__': None},
> None)
>   File "/home/m0/chrome/src/chrome/third_party/hunspell/hunspell.gyp", line
> 4
>
>     ^
> SyntaxError: invalid syntax
> failed to run command: /usr/bin/python src/tools/gyp/gyp_chromium
>
> I made sure I have no local changes (fresh out of git)
>
> m...@m0-desktop:~/chrome/src$ git log
> commit 0954eb9b2987d50c54cb9c62ba3dfdeec1f1b01b
> Author: gspen...@google.com
> 
> Date:   Fri Aug 7 03:38:01 2009 +
>     This adds a stub for the mac installer so that the gyp generation won't
> fail on Macs.
>     Review URL: http://codereview.chromium.org/165109
>
>     git-svn-id: svn://svn.chromium.org/chrome/trunk/s...@22717
> 0039d316-1c4b-4281-b951-d872f2087c98
>
> But I still get the error. My "git status" is:
>
> m...@m0-desktop:~/chrome/src$ git status
>
> # On branch trunk
> # Untracked files:
> #   (use "git add ..." to include in what will be committed)
> #
> # chrome/test/data/layout_tests/LayoutTests/
> # valgrind-20090715/
> # valgrind.tmp/
> nothing added to commit but untracked files present (use "git add" to track)
>
> I really don't understand why it is happening, I diffed my hunspell.gyp wrt
> to the version online and they are identical.
> Any help is appreciated, I would like to work a bit this weekend but
> valgrind requires linux and I can't seem to gclient sync it :/
>
> Thanks!
> -- Mohamed Mansour
>
> >
>

--~--~-~--~~~---~--~~
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 failing while triggering gclient sync in linux with git

[Mohamed Mansour]

Tonight I was trying to sync my project so I did "git pull" and it worked
fine, then I did "gclient sync" as well as --force. But gyp is failing:

m...@m0-desktop:~/chrome/src$ gclient sync found .git directory;
skipping src

 running '/usr/bin/python src/tools/gyp/gyp_chromium' in
'/home/m0/chrome'
Updating projects from gyp files...
Traceback (most recent call last):
  File "src/tools/gyp/gyp_chromium", line 34, in 
sys.exit(gyp.main(args))
  File "src/tools/gyp/pylib/gyp/__init__.py", line 262, in main
params)
  File "src/tools/gyp/pylib/gyp/__init__.py", line 75, in Load
depth, generator_input_info)
  File "src/tools/gyp/pylib/gyp/input.py", line 1644, in Load
LoadTargetBuildFile(build_file, data, aux_data, variables, includes,
depth)
  File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
includes, depth)
  File "src/tools/gyp/pylib/gyp/input.py", line 280, in LoadTargetBuildFile
includes, depth)
  File "src/tools/gyp/pylib/gyp/input.py", line 224, in LoadTargetBuildFile
includes, True)
  File "src/tools/gyp/pylib/gyp/input.py", line 129, in LoadOneBuildFile
build_file_data = eval(build_file_contents, {'__builtins__': None},
None)
  File "/home/m0/chrome/src/chrome/third_party/hunspell/hunspell.gyp", line
4

^
SyntaxError: invalid syntax
failed to run command: /usr/bin/python src/tools/gyp/gyp_chromium


I made sure I have no local changes (fresh out of git)

m...@m0-desktop:~/chrome/src$ git log
commit 0954eb9b2987d50c54cb9c62ba3dfdeec1f1b01b
Author: gspen...@google.com 
Date:   Fri Aug 7 03:38:01 2009 +

This adds a stub for the mac installer so that the gyp generation won't
fail on Macs.
Review URL: http://codereview.chromium.org/165109

git-svn-id:
svn://svn.chromium.org/chrome/trunk/s...@227170039d316-1c4b-4281-b951-d872f2087c98


But I still get the error. My "git status" is:

m...@m0-desktop:~/chrome/src$ git status

# On branch trunk# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
# chrome/test/data/layout_tests/LayoutTests/
# valgrind-20090715/
# valgrind.tmp/
nothing added to commit but untracked files present (use "git add" to track)


I really don't understand why it is happening, I diffed my hunspell.gyp wrt
to the version online and they are identical.

Any help is appreciated, I would like to work a bit this weekend but
valgrind requires linux and I can't seem to gclient sync it :/


Thanks!

-- Mohamed Mansour

--~--~-~--~~~---~--~~
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: [chromium-extensions] Re: Extension API Proposal: Performance Tracing

[Aaron Boodman]

[moving to chromium-dev, as it seems better for this discussion]

Kelly,

Sorry for not replying earlier. I'm a little bit underwater right now,
as we're trying to get everything with extensions tied up so we can
turn it on by default on dev.

I'd like to take a step back and ponder why even do this as an extension.

I assume your end goal must be to build this feature into Chrome's dev
tools, right? If so, I think it would be better to start out building
the code into Chrome, not on top of the extension system.

There is a significant cost to adding APIs to the extension system.
They must be general, relatively safe, and we must maintain them,
forever. In this case, I don't see a huge demand for these kind of
APIs. Even in Firefox, which has infinite flexibility, we only see a
few of these type of extensions.

In contrast, when something is part of Chrome directly, there is a lot
more power and flexibility available.

- a

On Wed, Aug 5, 2009 at 9:28 AM, Kelly Norton wrote:
> If you're interested in what the mechanics of this would look like, an
> initial patch for this is posted here: http://codereview.chromium.org/159882
>
> /kelly
> On Tue, Aug 4, 2009 at 2:39 PM, Kelly Norton  wrote:
>>
>> I've added a document to the chromium wiki that describes an extensions
>> API to support a performance tool, which is being called APU for now. For
>> those who haven't seen the tool, there is a very brief demo in this
>> video: http://www.youtube.com/watch?v=S5aJAaGZIvk#t=21m15s. The API is
>> essentially a firehose of timing data that can be enabled on a per-tab
>> basis. We're hoping this API is a good starting point for DevTools-related
>> APIs in that it has a narrowly focused initial use case and very little API
>> surface area. I'm interested in getting your feedback.
>> http://code.google.com/p/chromium/wiki/ExtensionsPerfTraceAPI
>> Thanks,
>> /kelly
>> --
>> If you received this communication by mistake, you are entitled to one
>> free ice cream cone on me. Simply print out this email including all
>> relevant SMTP headers and present them at my desk to claim your creamy
>> treat. We'll have a laugh at my emailing incompetence, and play a game of
>> ping pong. (offer may not be valid in all States).
>
>
>
> --
> If you received this communication by mistake, you are entitled to one free
> ice cream cone on me. Simply print out this email including all relevant
> SMTP headers and present them at my desk to claim your creamy treat. We'll
> have a laugh at my emailing incompetence, and play a game of ping pong.
> (offer may not be valid in all States).
>
> >
>

--~--~-~--~~~---~--~~
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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red

[Dan Kegel]

On Thu, Aug 6, 2009 at 4:48 PM, Peter Kasting wrote:
> I told Ben this morning that I'm taking ownership of the flakiness problem,
> and I meant it.  I will do my best to harass people.  Next on my list is
> going to every single subteam meeting and making noise at all of them.

Thank you for taking this on.

--~--~-~--~~~---~--~~
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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red

[Peter Kasting]

On Thu, Aug 6, 2009 at 4:45 PM, Dan Kegel  wrote:

> Closing the tree for several days would be a low price to
> pay for cleaning up the flaky tests and valgrind leaks...


I disagree, and I also think that closing the tree would not net you as many
people working on valgrind failures as you hope.  Most people would continue
working on their various different bugs, waiting for the tree to reopen.  I
know because we have had periods where the tree was closed for more than a
full day before and people's behavior was not really affected.

I told Ben this morning that I'm taking ownership of the flakiness problem,
and I meant it.  I will do my best to harass people.  Next on my list is
going to every single subteam meeting and making noise at all of them.

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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red

[Dan Kegel]

On Thu, Aug 6, 2009 at 4:38 PM, Peter Kasting wrote:
>> i.e. Next time we hold a valgrind fixit,
>> how about we just delete the non-upstream-bugs
>> suppressions files?
>
> I think this would be a mistake.
> There is a lot of accumulated "knowledge" in the valgrind suppresions file.
>  Doubtless some of it is obsolete (suppressions that no longer apply).
>  However, both erg and phajdan.jr have removed things like this (LayoutTest
> cruft for erg) recently, and that can be done in a
> change-one-variable-at-a-time controlled fashion.
> By contrast, dumping the whole file would have two effects:
> (1) If you're really serious about it, the tree will be closed for at least
> several days.  This is an extremely high cost.
> (2) You will be getting intermittent red far more frequently for weeks as
> the rarest of the suppressions in that file occasionally rear their head.

I forgot to mention: we would put the still-needed suppressions back
after the fixit.  There would be no ongoing flakiness as a result
of the temporary deletion of the suppressions.

Closing the tree for several days would be a low price to
pay for cleaning up the flaky tests and valgrind leaks...
- Dan

--~--~-~--~~~---~--~~
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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red

[Peter Kasting]

On Thu, Aug 6, 2009 at 4:09 PM, Dan Kegel  wrote:

> Despite having had several valgrind/purify fixit weeks,
> our bug tracker is still full of 'em.


Hence my email last night.

i.e. Next time we hold a valgrind fixit,
> how about we just delete the non-upstream-bugs
> suppressions files?


I think this would be a mistake.

There is a lot of accumulated "knowledge" in the valgrind suppresions file.
 Doubtless some of it is obsolete (suppressions that no longer apply).
 However, both erg and phajdan.jr have removed things like this (LayoutTest
cruft for erg) recently, and that can be done in a
change-one-variable-at-a-time controlled fashion.

By contrast, dumping the whole file would have two effects:
(1) If you're really serious about it, the tree will be closed for at least
several days.  This is an extremely high cost.
(2) You will be getting intermittent red far more frequently for weeks as
the rarest of the suppressions in that file occasionally rear their head.
 Flakiness is very bad.

Compare this to today, where the valgrind bots went red, I put hclam on it,
and he had a leak fix inside of an hour.  Non-flaky tests mean we can fix
new failures fast.

For better or worse, I believe we simply have to get people to clean things
up themselves.  Hence my directive last night for every Googler to put
something on his or her OKRs.  If we start fixing flaky LayoutTests, memory
bugs, etc., the hard-to-track-down valgrind suppressions will be removable
too.

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: PluginTest.Refresh is hanging purify every time

[Glen Murphy]

I believe Erik is also out for the next week.


On Thu, Aug 6, 2009 at 4:32 PM, Peter Kasting wrote:
> On Thu, Aug 6, 2009 at 4:23 PM, Dan Kegel  wrote:
>>
>> Hi Erik,
>> PluginTest.Refresh is hanging purify every time, ever since
>>
>> http://build.chromium.org/buildbot/waterfall/builders/Webkit%20(purify)/builds/9777
>> two days ago.
>>
>> Want me to file a bug / disable it?
>
> Per nsylvain, timsteele is disabling this for purify right now.
> 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: PluginTest.Refresh is hanging purify every time

[Peter Kasting]

On Thu, Aug 6, 2009 at 4:23 PM, Dan Kegel  wrote:

> Hi Erik,
> PluginTest.Refresh is hanging purify every time, ever since
>
> http://build.chromium.org/buildbot/waterfall/builders/Webkit%20(purify)/builds/9777
> two days ago.
>
> Want me to file a bug / disable it?


Per nsylvain, timsteele is disabling this for purify right now.

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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red

[Paweł Hajdan Jr .]

+1
Additional benefit would be the cleanup of the suppression files. I believe
some of them are fixed (I was able to successfuly remove at least two of
them).

On Thu, Aug 6, 2009 at 16:16, Elliot Glaysher (Chromium)
wrote:

>
> +1 to this idea. Close the tree, only fixes can get in.
>
> -- Elliot
>
> On Thu, Aug 6, 2009 at 4:09 PM, Dan Kegel wrote:
> >
> > Despite having had several valgrind/purify fixit weeks,
> > our bug tracker is still full of 'em.
> >
> > It might be a mistake to expect people to
> > get exicited about combing through a dusty
> > bug database.  How about we tap in to the
> > adrenalin rush of a red tree instead?
> >
> > i.e. Next time we hold a valgrind fixit,
> > how about we just delete the non-upstream-bugs
> > suppressions files?  The waterfall will turn
> > a lovely shade of red, and people will go into
> > action in their usual rapid way.
> >
> > (We'd still need to publicize it ahead of
> > time, and make sure people were set up
> > with valgrind properly, but that goes without saying.)
> > - Dan
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] PluginTest.Refresh is hanging purify every time

[Dan Kegel]

Hi Erik,
PluginTest.Refresh is hanging purify every time, ever since
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20(purify)/builds/9777
two days ago.

Want me to file a bug / disable 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: Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red

[Elliot Glaysher (Chromium)]

+1 to this idea. Close the tree, only fixes can get in.

-- Elliot

On Thu, Aug 6, 2009 at 4:09 PM, Dan Kegel wrote:
>
> Despite having had several valgrind/purify fixit weeks,
> our bug tracker is still full of 'em.
>
> It might be a mistake to expect people to
> get exicited about combing through a dusty
> bug database.  How about we tap in to the
> adrenalin rush of a red tree instead?
>
> i.e. Next time we hold a valgrind fixit,
> how about we just delete the non-upstream-bugs
> suppressions files?  The waterfall will turn
> a lovely shade of red, and people will go into
> action in their usual rapid way.
>
> (We'd still need to publicize it ahead of
> time, and make sure people were set up
> with valgrind properly, but that goes without saying.)
> - Dan
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Idea for next valgrind/purify fixit week: just delete the suppressions and watch the tree go red

[Dan Kegel]

Despite having had several valgrind/purify fixit weeks,
our bug tracker is still full of 'em.

It might be a mistake to expect people to
get exicited about combing through a dusty
bug database.  How about we tap in to the
adrenalin rush of a red tree instead?

i.e. Next time we hold a valgrind fixit,
how about we just delete the non-upstream-bugs
suppressions files?  The waterfall will turn
a lovely shade of red, and people will go into
action in their usual rapid way.

(We'd still need to publicize it ahead of
time, and make sure people were set up
with valgrind properly, but that goes without saying.)
- Dan

--~--~-~--~~~---~--~~
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: crashing on startup

[Gobbledegook]

Thanks! Had the same problem and was directed to this solution.
Resolved!

Windows users need to delete the extensions folder located here:

http://dev.chromium.org/user-experience/user-data-directory



On Aug 6, 7:43 pm, Evan Martin  wrote:
> A few people have found their trunk builds crashing on startup.
> This comes from a bug in theme loading and can bite you if you
> installed some of the in-development themes.
> The fix is to rm -rf your "Extensions" directory out of your profile 
> directory.
> The next release will have the bug fixed, and at that point these
> themes will no longer cause crashes.
--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Gobbledegook]

*linux

On Aug 6, 10:27 pm, Gobbledegook  wrote:
> haha yes. plain old windows user. i had an inkling it referred to a
> linum remove command but I thought it could be a shortcut overloader
> as well (end of target field thing).
>
> Anyway, I successfully found the folder, deleted it, installed Dev
> version, and now everything works!
>
> Thank you!!
>
> RESOLVED!!
>
> On Aug 6, 10:16 pm, Evan Stade  wrote:
>
>
>
> > oh sorry. Not using linux. "rm -rf" means to delete. So go find your
> > profile directory and delete the Extensions/ folder in there.
>
> > -- Evan Stade
>
> > On Thu, Aug 6, 2009 at 2:15 PM, Evan Stade wrote:
> > > Open your favorite terminal program and type
>
> > >  rm -rf ~/.config/google-chrome/Default/Extensions/
>
> > > at the prompt
>
> > > -- Evan Stade
>
> > > On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegook wrote:
>
> > >> Thanks for the replies guys.
>
> > >> What exactly does this mean:
>
> > >> The fix is to rm -rf your "Extensions" directory out of your profile
> > >> directory.
>
> > >> ???
>
> > >> On Aug 6, 10:06 pm, Dan Kegel  wrote:
> > >>> Evan wrote about this earlier:
> > >>> "A few people have found their trunk builds crashing on startup.
> > >>> This comes from a bug in theme loading and can bite you if you
> > >>> installed some of the in-development themes.
> > >>> The fix is to rm -rf your "Extensions" directory out of your profile 
> > >>> directory.
> > >>> The next release will have the bug fixed, and at that point these
> > >>> themes will no longer cause crashes."
>
> > >>> Does that help?
>
> > >>> On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook 
> > >>> wrote:
>
> > >>> > Hi,
>
> > >>> > I've been unable to get into chrome dev (latest) ever since I
> > >>> > installed the Baseball theme. Everything worked fine till my computer
> > >>> > crashed (unrelated to chrome / a USB - windows sleep mode driver
> > >>> > incompatibility)
>
> > >>> > It just gives the Whoa! Google has crashed error.
>
> > >>> > I uninstalled and tried reinstalling but it still refuses to work. I
> > >>> > didn't want to lose my history so I didn't try doing a completely
> > >>> > clean reinstall. However, I'm now on the beta channel and it's working
> > >>> > fine.
>
> > >>> > Toshiba A300D-15B dual core 2.1GHz AMD laptop
> > >>> > 4 GB RAM
> > >>> > Windows 7 RTM (build 7600) 64 bit
>
> > >>> > Steps to recreate scenario:
>
> > >>> > 1. Install Google Chrome Dev channel version.
> > >>> > 2. Open 5 tabs.
> > >>> > 3. Install the baseball theme and keep Chrome running.
> > >>> > 4. Put Windows into Sleep mode.
> > >>> > 5. Wake up windows.
> > >>> > 6. Do a hard restart (do not safely restart the computer but use the
> > >>> > power button if you're on a laptop or reset button if ure on a
> > >>> > desktop)
> > >>> > 7. Run Windows normally.
> > >>> > 8. Try to start Google Chrome.
>
> > >>> > It should crash.
--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Gobbledegook]

haha yes. plain old windows user. i had an inkling it referred to a
linum remove command but I thought it could be a shortcut overloader
as well (end of target field thing).

Anyway, I successfully found the folder, deleted it, installed Dev
version, and now everything works!

Thank you!!

RESOLVED!!

On Aug 6, 10:16 pm, Evan Stade  wrote:
> oh sorry. Not using linux. "rm -rf" means to delete. So go find your
> profile directory and delete the Extensions/ folder in there.
>
> -- Evan Stade
>
>
>
> On Thu, Aug 6, 2009 at 2:15 PM, Evan Stade wrote:
> > Open your favorite terminal program and type
>
> >  rm -rf ~/.config/google-chrome/Default/Extensions/
>
> > at the prompt
>
> > -- Evan Stade
>
> > On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegook wrote:
>
> >> Thanks for the replies guys.
>
> >> What exactly does this mean:
>
> >> The fix is to rm -rf your "Extensions" directory out of your profile
> >> directory.
>
> >> ???
>
> >> On Aug 6, 10:06 pm, Dan Kegel  wrote:
> >>> Evan wrote about this earlier:
> >>> "A few people have found their trunk builds crashing on startup.
> >>> This comes from a bug in theme loading and can bite you if you
> >>> installed some of the in-development themes.
> >>> The fix is to rm -rf your "Extensions" directory out of your profile 
> >>> directory.
> >>> The next release will have the bug fixed, and at that point these
> >>> themes will no longer cause crashes."
>
> >>> Does that help?
>
> >>> On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook wrote:
>
> >>> > Hi,
>
> >>> > I've been unable to get into chrome dev (latest) ever since I
> >>> > installed the Baseball theme. Everything worked fine till my computer
> >>> > crashed (unrelated to chrome / a USB - windows sleep mode driver
> >>> > incompatibility)
>
> >>> > It just gives the Whoa! Google has crashed error.
>
> >>> > I uninstalled and tried reinstalling but it still refuses to work. I
> >>> > didn't want to lose my history so I didn't try doing a completely
> >>> > clean reinstall. However, I'm now on the beta channel and it's working
> >>> > fine.
>
> >>> > Toshiba A300D-15B dual core 2.1GHz AMD laptop
> >>> > 4 GB RAM
> >>> > Windows 7 RTM (build 7600) 64 bit
>
> >>> > Steps to recreate scenario:
>
> >>> > 1. Install Google Chrome Dev channel version.
> >>> > 2. Open 5 tabs.
> >>> > 3. Install the baseball theme and keep Chrome running.
> >>> > 4. Put Windows into Sleep mode.
> >>> > 5. Wake up windows.
> >>> > 6. Do a hard restart (do not safely restart the computer but use the
> >>> > power button if you're on a laptop or reset button if ure on a
> >>> > desktop)
> >>> > 7. Run Windows normally.
> >>> > 8. Try to start Google Chrome.
>
> >>> > It should crash.
--~--~-~--~~~---~--~~
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: Git usage in chromium

[Evan Martin]

On Thu, Aug 6, 2009 at 2:06 PM, Marc-Antoine Ruel wrote:
>> Say DEPS says web...@revision A, and you have webkit at revision A~10.
>> gclient sync should probably fast-forward your checkout.
>>
>> Say DEPS says web...@revision A, and then you've checked out trunk and
>> have local changes.  gclient sync should probably... do nothing?
>>
>> But then how do we tell "DEPS checked them out at A~10 before, so we
>> should fast forward to A" from "they checked out A~10 because that was
>> trunk at the time, so we should fast forward to trunk"?
>
> I assume s/trunk/HEAD/g

Yeah, the SVN HEAD, not the git one.  Confusing.  :(

> But I still don't understand your sentence. Doesn't `git svn rebase
> --revision A` work for that or I misunderstood? I presume it will back
> merge if needed?

I didn't think rebase takes a --revision argument...

My examples were bad.  Let me try again.

Suppose current DEPS says WebKit at revision A.
I am tweaking WebKit stuff so I started at the newest version I can
find, version B.
I have made a local commit on top of that, call it C.
Now I do a gclient sync, and my DEPS updates to request some other
WebKit version D.
In the meantime, the newest WebKit available is now version E.

(Note that D can be earlier or later than B.)

In this circumstance I think I should remain on commit C.  But if C=B,
then maybe I should end up at E?  Or if you think rebasing is correct,
should I rebase C onto E or C onto D?  And what if I have local
uncommitted changes -- then rebasing isn't possible?

Finally, what if D is an *earlier* commit than A (we rolled back DEPS
for some reason), do I rebase my work in C backwards?  Etc. etc.

And say A=B=C (that is, I'm not working on WebKit at all), I think you
probably want to end up on D.  But detecting that A=C means you need
the DEPS file from *before* you synced (to get A).



What I had done before was add a tag to each git repo called "gclient"
that always pointed at the version requested by gclient, and then left
it up to you whether you wanted to check that out or not.  And then
you can compare your current commit to the gclient tag and warn
appropriately.  But I think git is confusing enough for most people so
someone (I think it was Tony?) pointed out I can keep it even simpler
and say "figure it out yourself".

--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Aaron Boodman]

You can find the location of your profile directory on this page:

http://dev.chromium.org/user-experience/user-data-directory

- a

On Thu, Aug 6, 2009 at 2:16 PM, Evan Stade wrote:
>
> oh sorry. Not using linux. "rm -rf" means to delete. So go find your
> profile directory and delete the Extensions/ folder in there.
>
> -- Evan Stade
>
>
>
> On Thu, Aug 6, 2009 at 2:15 PM, Evan Stade wrote:
>> Open your favorite terminal program and type
>>
>>  rm -rf ~/.config/google-chrome/Default/Extensions/
>>
>> at the prompt
>>
>> -- Evan Stade
>>
>>
>>
>> On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegook wrote:
>>>
>>> Thanks for the replies guys.
>>>
>>> What exactly does this mean:
>>>
>>> The fix is to rm -rf your "Extensions" directory out of your profile
>>> directory.
>>>
>>> ???
>>>
>>> On Aug 6, 10:06 pm, Dan Kegel  wrote:
 Evan wrote about this earlier:
 "A few people have found their trunk builds crashing on startup.
 This comes from a bug in theme loading and can bite you if you
 installed some of the in-development themes.
 The fix is to rm -rf your "Extensions" directory out of your profile 
 directory.
 The next release will have the bug fixed, and at that point these
 themes will no longer cause crashes."

 Does that help?



 On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook wrote:

 > Hi,

 > I've been unable to get into chrome dev (latest) ever since I
 > installed the Baseball theme. Everything worked fine till my computer
 > crashed (unrelated to chrome / a USB - windows sleep mode driver
 > incompatibility)

 > It just gives the Whoa! Google has crashed error.

 > I uninstalled and tried reinstalling but it still refuses to work. I
 > didn't want to lose my history so I didn't try doing a completely
 > clean reinstall. However, I'm now on the beta channel and it's working
 > fine.

 > Toshiba A300D-15B dual core 2.1GHz AMD laptop
 > 4 GB RAM
 > Windows 7 RTM (build 7600) 64 bit

 > Steps to recreate scenario:

 > 1. Install Google Chrome Dev channel version.
 > 2. Open 5 tabs.
 > 3. Install the baseball theme and keep Chrome running.
 > 4. Put Windows into Sleep mode.
 > 5. Wake up windows.
 > 6. Do a hard restart (do not safely restart the computer but use the
 > power button if you're on a laptop or reset button if ure on a
 > desktop)
 > 7. Run Windows normally.
 > 8. Try to start Google Chrome.

 > It should crash.
>>> >>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Robert Shield]

On Thu, Aug 6, 2009 at 5:15 PM, Evan Stade  wrote:

>
> Open your favorite terminal program and type
>
>  rm -rf ~/.config/google-chrome/Default/Extensions/
>
> at the prompt
>

Or, if you're using Windows, delete the contents of this folder:

C:\Users\\AppData\Local\Google\Chrome\User
Data\Default\Extensions



>
> -- Evan Stade
>
>
>
> On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegook wrote:
> >
> > Thanks for the replies guys.
> >
> > What exactly does this mean:
> >
> > The fix is to rm -rf your "Extensions" directory out of your profile
> > directory.
> >
> > ???
> >
> > On Aug 6, 10:06 pm, Dan Kegel  wrote:
> >> Evan wrote about this earlier:
> >> "A few people have found their trunk builds crashing on startup.
> >> This comes from a bug in theme loading and can bite you if you
> >> installed some of the in-development themes.
> >> The fix is to rm -rf your "Extensions" directory out of your profile
> directory.
> >> The next release will have the bug fixed, and at that point these
> >> themes will no longer cause crashes."
> >>
> >> Does that help?
> >>
> >>
> >>
> >> On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook
> wrote:
> >>
> >> > Hi,
> >>
> >> > I've been unable to get into chrome dev (latest) ever since I
> >> > installed the Baseball theme. Everything worked fine till my computer
> >> > crashed (unrelated to chrome / a USB - windows sleep mode driver
> >> > incompatibility)
> >>
> >> > It just gives the Whoa! Google has crashed error.
> >>
> >> > I uninstalled and tried reinstalling but it still refuses to work. I
> >> > didn't want to lose my history so I didn't try doing a completely
> >> > clean reinstall. However, I'm now on the beta channel and it's working
> >> > fine.
> >>
> >> > Toshiba A300D-15B dual core 2.1GHz AMD laptop
> >> > 4 GB RAM
> >> > Windows 7 RTM (build 7600) 64 bit
> >>
> >> > Steps to recreate scenario:
> >>
> >> > 1. Install Google Chrome Dev channel version.
> >> > 2. Open 5 tabs.
> >> > 3. Install the baseball theme and keep Chrome running.
> >> > 4. Put Windows into Sleep mode.
> >> > 5. Wake up windows.
> >> > 6. Do a hard restart (do not safely restart the computer but use the
> >> > power button if you're on a laptop or reset button if ure on a
> >> > desktop)
> >> > 7. Run Windows normally.
> >> > 8. Try to start Google Chrome.
> >>
> >> > It should crash.
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Evan Stade]

oh sorry. Not using linux. "rm -rf" means to delete. So go find your
profile directory and delete the Extensions/ folder in there.

-- Evan Stade



On Thu, Aug 6, 2009 at 2:15 PM, Evan Stade wrote:
> Open your favorite terminal program and type
>
>  rm -rf ~/.config/google-chrome/Default/Extensions/
>
> at the prompt
>
> -- Evan Stade
>
>
>
> On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegook wrote:
>>
>> Thanks for the replies guys.
>>
>> What exactly does this mean:
>>
>> The fix is to rm -rf your "Extensions" directory out of your profile
>> directory.
>>
>> ???
>>
>> On Aug 6, 10:06 pm, Dan Kegel  wrote:
>>> Evan wrote about this earlier:
>>> "A few people have found their trunk builds crashing on startup.
>>> This comes from a bug in theme loading and can bite you if you
>>> installed some of the in-development themes.
>>> The fix is to rm -rf your "Extensions" directory out of your profile 
>>> directory.
>>> The next release will have the bug fixed, and at that point these
>>> themes will no longer cause crashes."
>>>
>>> Does that help?
>>>
>>>
>>>
>>> On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook wrote:
>>>
>>> > Hi,
>>>
>>> > I've been unable to get into chrome dev (latest) ever since I
>>> > installed the Baseball theme. Everything worked fine till my computer
>>> > crashed (unrelated to chrome / a USB - windows sleep mode driver
>>> > incompatibility)
>>>
>>> > It just gives the Whoa! Google has crashed error.
>>>
>>> > I uninstalled and tried reinstalling but it still refuses to work. I
>>> > didn't want to lose my history so I didn't try doing a completely
>>> > clean reinstall. However, I'm now on the beta channel and it's working
>>> > fine.
>>>
>>> > Toshiba A300D-15B dual core 2.1GHz AMD laptop
>>> > 4 GB RAM
>>> > Windows 7 RTM (build 7600) 64 bit
>>>
>>> > Steps to recreate scenario:
>>>
>>> > 1. Install Google Chrome Dev channel version.
>>> > 2. Open 5 tabs.
>>> > 3. Install the baseball theme and keep Chrome running.
>>> > 4. Put Windows into Sleep mode.
>>> > 5. Wake up windows.
>>> > 6. Do a hard restart (do not safely restart the computer but use the
>>> > power button if you're on a laptop or reset button if ure on a
>>> > desktop)
>>> > 7. Run Windows normally.
>>> > 8. Try to start Google Chrome.
>>>
>>> > It should crash.
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Bapabooiee]

Just read the entire thread. It looks like this thread has gotten a
little more... "mucky" than it ever needed to be. What is going on
here?

On Aug 6, 11:16 am, yoav zilberberg  wrote:
> I apologize, i had no idea all of you are chrome devs, and i shall indeed
> happily remove myself
> thanx for answering, and best of luck you all.

>From what I've seen, the Chromium developers seem very reasonable, and
quite knowledgeable. I don't see any reason for the tension we've seen
here; and certainly don't see a reason why you should remove yourself
from the Chromium community.

It's a shame you feel that way, Yoav =\

--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Evan Stade]

Open your favorite terminal program and type

  rm -rf ~/.config/google-chrome/Default/Extensions/

at the prompt

-- Evan Stade



On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegook wrote:
>
> Thanks for the replies guys.
>
> What exactly does this mean:
>
> The fix is to rm -rf your "Extensions" directory out of your profile
> directory.
>
> ???
>
> On Aug 6, 10:06 pm, Dan Kegel  wrote:
>> Evan wrote about this earlier:
>> "A few people have found their trunk builds crashing on startup.
>> This comes from a bug in theme loading and can bite you if you
>> installed some of the in-development themes.
>> The fix is to rm -rf your "Extensions" directory out of your profile 
>> directory.
>> The next release will have the bug fixed, and at that point these
>> themes will no longer cause crashes."
>>
>> Does that help?
>>
>>
>>
>> On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook wrote:
>>
>> > Hi,
>>
>> > I've been unable to get into chrome dev (latest) ever since I
>> > installed the Baseball theme. Everything worked fine till my computer
>> > crashed (unrelated to chrome / a USB - windows sleep mode driver
>> > incompatibility)
>>
>> > It just gives the Whoa! Google has crashed error.
>>
>> > I uninstalled and tried reinstalling but it still refuses to work. I
>> > didn't want to lose my history so I didn't try doing a completely
>> > clean reinstall. However, I'm now on the beta channel and it's working
>> > fine.
>>
>> > Toshiba A300D-15B dual core 2.1GHz AMD laptop
>> > 4 GB RAM
>> > Windows 7 RTM (build 7600) 64 bit
>>
>> > Steps to recreate scenario:
>>
>> > 1. Install Google Chrome Dev channel version.
>> > 2. Open 5 tabs.
>> > 3. Install the baseball theme and keep Chrome running.
>> > 4. Put Windows into Sleep mode.
>> > 5. Wake up windows.
>> > 6. Do a hard restart (do not safely restart the computer but use the
>> > power button if you're on a laptop or reset button if ure on a
>> > desktop)
>> > 7. Run Windows normally.
>> > 8. Try to start Google Chrome.
>>
>> > It should crash.
> >
>

--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Gobbledegook]

Thanks for the replies guys.

What exactly does this mean:

The fix is to rm -rf your "Extensions" directory out of your profile
directory.

???

On Aug 6, 10:06 pm, Dan Kegel  wrote:
> Evan wrote about this earlier:
> "A few people have found their trunk builds crashing on startup.
> This comes from a bug in theme loading and can bite you if you
> installed some of the in-development themes.
> The fix is to rm -rf your "Extensions" directory out of your profile 
> directory.
> The next release will have the bug fixed, and at that point these
> themes will no longer cause crashes."
>
> Does that help?
>
>
>
> On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook wrote:
>
> > Hi,
>
> > I've been unable to get into chrome dev (latest) ever since I
> > installed the Baseball theme. Everything worked fine till my computer
> > crashed (unrelated to chrome / a USB - windows sleep mode driver
> > incompatibility)
>
> > It just gives the Whoa! Google has crashed error.
>
> > I uninstalled and tried reinstalling but it still refuses to work. I
> > didn't want to lose my history so I didn't try doing a completely
> > clean reinstall. However, I'm now on the beta channel and it's working
> > fine.
>
> > Toshiba A300D-15B dual core 2.1GHz AMD laptop
> > 4 GB RAM
> > Windows 7 RTM (build 7600) 64 bit
>
> > Steps to recreate scenario:
>
> > 1. Install Google Chrome Dev channel version.
> > 2. Open 5 tabs.
> > 3. Install the baseball theme and keep Chrome running.
> > 4. Put Windows into Sleep mode.
> > 5. Wake up windows.
> > 6. Do a hard restart (do not safely restart the computer but use the
> > power button if you're on a laptop or reset button if ure on a
> > desktop)
> > 7. Run Windows normally.
> > 8. Try to start Google Chrome.
>
> > It should crash.
--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Jeremy Orlow]

Does
http://groups.google.com/group/chromium-dev/browse_thread/thread/df20c1f0e4576131
 help?
If not, please go to new.crbug.com

On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook  wrote:

>
> Hi,
>
> I've been unable to get into chrome dev (latest) ever since I
> installed the Baseball theme. Everything worked fine till my computer
> crashed (unrelated to chrome / a USB - windows sleep mode driver
> incompatibility)
>
> It just gives the Whoa! Google has crashed error.
>
> I uninstalled and tried reinstalling but it still refuses to work. I
> didn't want to lose my history so I didn't try doing a completely
> clean reinstall. However, I'm now on the beta channel and it's working
> fine.
>
> Toshiba A300D-15B dual core 2.1GHz AMD laptop
> 4 GB RAM
> Windows 7 RTM (build 7600) 64 bit
>
> Steps to recreate scenario:
>
> 1. Install Google Chrome Dev channel version.
> 2. Open 5 tabs.
> 3. Install the baseball theme and keep Chrome running.
> 4. Put Windows into Sleep mode.
> 5. Wake up windows.
> 6. Do a hard restart (do not safely restart the computer but use the
> power button if you're on a laptop or reset button if ure on a
> desktop)
> 7. Run Windows normally.
> 8. Try to start Google Chrome.
>
> It should crash.
>
> >
>

--~--~-~--~~~---~--~~
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: Dev Chrome crashes on subsequent starts after installing a theme

[Dan Kegel]

Evan wrote about this earlier:
"A few people have found their trunk builds crashing on startup.
This comes from a bug in theme loading and can bite you if you
installed some of the in-development themes.
The fix is to rm -rf your "Extensions" directory out of your profile directory.
The next release will have the bug fixed, and at that point these
themes will no longer cause crashes."

Does that help?

On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegook wrote:
>
> Hi,
>
> I've been unable to get into chrome dev (latest) ever since I
> installed the Baseball theme. Everything worked fine till my computer
> crashed (unrelated to chrome / a USB - windows sleep mode driver
> incompatibility)
>
> It just gives the Whoa! Google has crashed error.
>
> I uninstalled and tried reinstalling but it still refuses to work. I
> didn't want to lose my history so I didn't try doing a completely
> clean reinstall. However, I'm now on the beta channel and it's working
> fine.
>
> Toshiba A300D-15B dual core 2.1GHz AMD laptop
> 4 GB RAM
> Windows 7 RTM (build 7600) 64 bit
>
> Steps to recreate scenario:
>
> 1. Install Google Chrome Dev channel version.
> 2. Open 5 tabs.
> 3. Install the baseball theme and keep Chrome running.
> 4. Put Windows into Sleep mode.
> 5. Wake up windows.
> 6. Do a hard restart (do not safely restart the computer but use the
> power button if you're on a laptop or reset button if ure on a
> desktop)
> 7. Run Windows normally.
> 8. Try to start Google Chrome.
>
> It should crash.
>
> >
>

--~--~-~--~~~---~--~~
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: Git usage in chromium

[Marc-Antoine Ruel]

On Thu, Aug 6, 2009 at 1:36 PM, Evan Martin wrote:
>
> On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafai wrote:
>>> After following the instructions in that document trunk/src is git and
>>> everything else (pulled in via DEPS, including webkit and also ICU,
>>> skia, etc.) is via svn.
>>
>> I've been wondering about this. What would it take to modify our git
>> checkout process to pull third_party/WebKit via git as well? Would it mostly
>> work to just exclude third_party/WebKit via DEPS, create it via a git
>> checkout and then write a script that wraps gclient sync to also git
>> pull/rebase third_party/WebKit? Is there a better way?
>
> I had an old version of gclient that did this.  The problem you run
> into is that there are more possible tree states of git than in svn so
> it's hard to map across.
>
> Say DEPS says web...@revision A, and you have webkit at revision A~10.
> gclient sync should probably fast-forward your checkout.
>
> Say DEPS says web...@revision A, and then you've checked out trunk and
> have local changes.  gclient sync should probably... do nothing?
>
> But then how do we tell "DEPS checked them out at A~10 before, so we
> should fast forward to A" from "they checked out A~10 because that was
> trunk at the time, so we should fast forward to trunk"?

I assume s/trunk/HEAD/g

But I still don't understand your sentence. Doesn't `git svn rebase
--revision A` work for that or I misunderstood? I presume it will back
merge if needed?

There's also conflict management but that's another story. :)

M-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: Running UI test in parallel (experimental)

[Nicolas Sylvain]

On Thu, Aug 6, 2009 at 1:06 PM, John Abd-El-Malek  wrote:

> This is very cool, but I ran into a few problems when I tried to run it:
> a:\chrome2\src\chrome>tools\test\smoketests.py --tests=ui
>
> >> You must have your local path of trunk/src/tools/python added to your
> PYTHONPATH.<<
>
> Traceback (most recent call last):
>   File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 32, in
> 
> import google.httpd_utils
> ImportError: No module named google.httpd_utils
>

You get this error when you use a python that is different from the one in
src\third_party\python_24\python.exe


>
>
> hmmm, never needed PYTHONPATH set before.  Can't this script set it itself?
>  Setting it manually will fail when I move depot locations etc..  But
> anyways, I set it and then
>
> a:\chrome2\src\chrome>set PYTHONPATH=a:\chrome\src\tools\python
>
> a:\chrome2\src\chrome>tools\test\smoketests.py --tests=ui
> Traceback (most recent call last):
>   File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 274, in
> 
> result = main(options, args)
>   File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 155, in main
> sys.path.insert(0, _BuildbotScriptPath('slave'))
>   File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 84, in
> _BuildbotScriptPath
> 'scripts', sub_dir)
>   File "a:\chrome\src\tools\python\google\path_utils.py", line 72, in
> FindUpward
> parent = FindUpwardParent(start_dir, *desired_list)
>   File "a:\chrome\src\tools\python\google\path_utils.py", line 55, in
> FindUpwardParent
> (desired_path, start_dir))
> google.path_utils.PathNotFound: Unable to find tools\buildbot\scripts\slave
> above A:\chrome2\src\chrome\tools\test
>
>
>
> tools\buildbot isn't in the public tree I think, since I don't find it
> here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/.  So
> external contributors can't use this?  Also, why should this script depend
> on the buildbot scripts?  I don't have them so I can't try this out.
>
http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/

Not sure why it needs it though.

>
> Can't we just have a minimal python script that runs ui_tests in parallel?
>

Nicolas

>
> On Wed, Jul 29, 2009 at 3:28 PM, Huan Ren  wrote:
>
>>
>> I just checked in a change to run ui_tests in parallel based on
>> sharding mechanism provided by GTest. Each ui_tests instance has its
>> own user data dir, and the number of ui_tests instances is
>> NUMBER_OF_PROCESSORS. I have updated
>> src/chrome/tools/test/smoketests.py so you can run it through command
>> line:
>>
>> python.exe smoketests.py --tests=ui [--verbose]
>>
>> Running ui_tests.exe directly is still the old behavior of
>> sequentially running. On my 4 core machine, the running time has been
>> reduced by half, from 832 secs to 443 secs. But I need to make sure
>> all tests can run reliably in this parallel fashion. So if you try it
>> out, I will be interested to know how fast the performance is improved
>> and what additional tests are failing.
>>
>> Huan
>>
>> P.S. this change is for Windows platform as I think Linux/Mac is
>> already using GTest sharding.
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Flakiness. Please help.

[Jeremy Orlow]

On Thu, Aug 6, 2009 at 2:02 PM, Nicolas Sylvain wrote:

>
>
> On Thu, Aug 6, 2009 at 1:05 PM, Scott Violet  wrote:
>
>>
>> Not sure, perhaps Huan could answer that. That said, --enable-dcheck
>> certainly works on the Chromium release builds from the buildbot:
>> http://build.chromium.org/buildbot/continuous/LATEST/ .
>
>
> Yes, --enable-dcheck is supposed to be disabled in Google Chrome build.
>

Disabled or optimized out (so all that code isn't in the resulting binary).
 Hopefully the latter.


>
> Nicolas
>
>
>>
>>
>>  -Scott
>>
>> On Thu, Aug 6, 2009 at 12:59 PM, Antony Sargent
>> wrote:
>> > To clarify, doesn't --enable-dcheck only work on chromium release builds
>> you
>> > built yourself and not official builds of Google Chrome?
>> >
>> > On Thu, Aug 6, 2009 at 10:15 AM, Scott Violet  wrote:
>> >>
>> >> One easy suggestion in helping catch bugs is to run Chrome with
>> >> --enable-dcheck . This'll prompt if you hit a DCHECK in release builds
>> >> and hopefully help isolate crashes before the fact.
>> >>
>> >>  -Scott
>> >>
>> >> On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting
>> wrote:
>> >> > THIS MAIL APPLIES TO YOU
>> >> > Flakiness is growing.  Smash it before it gets bigger, and keep it
>> >> > smashed.
>> >> > ***
>> >> > The MOST IMPORTANT section in this gigantic mail:
>> >> > PLEASE spend some of every workday (or each week at least, if you
>> can't
>> >> > spare time each day) looking at test failures, flakiness,
>> >> > valgrind/purify/coverity bugs, crashes, and/or memory bugs.  Make it
>> a
>> >> > goal
>> >> > to get an average of one line in the test-expectations file removed
>> each
>> >> > day.  If you're a Googler, put it on your OKRs (now, not sometime
>> >> > tomorrow).
>> >> > * DON'T wait for someone to assign bugs to you or ask for your help
>> >> > * DON'T wait for a team fixit week (those haven't worked)
>> >> > * DON'T wait for someone else to solve the problems
>> >> > * DON'T wait until after your current project is finished
>> >> > * DON'T wait until you have worked on WebKit
>> >> > HELP, even if it's just a little, even if it's not your core
>> competence.
>> >> >  We
>> >> > currently have hundreds upon hundreds of failing or flaky tests.  We
>> can
>> >> > dramatically reduce this quickly but ONLY IF YOU HELP.  This is an
>> >> > investment not only in the quality of Chrome but in the team's
>> ability
>> >> > to
>> >> > move fast, so help here doesn't just improve the quality of Chrome,
>> but
>> >> > also
>> >> > the derivative of the quality :)
>> >> > (If you do not know how to do anything above and need handholding,
>> >> > e-mail me
>> >> > and I will help you.  It's OK to be ignorant.)
>> >> > ***
>> >> > Next, how you should help keep the tree green at all times:
>> >> > * If you ever look at the buildbot and see red, and there's no
>> >> > explanation
>> >> > in the build status, ask what's going on on #chromium.  Ping the
>> >> > sheriffs
>> >> > specifically (they're listed in the upper-right corner).  If you do
>> not
>> >> > get
>> >> > an answer about ownership within a few minutes, close the tree (if
>> you
>> >> > have
>> >> > the rights to) or ask someone to close it.  THE TREE SHOULD NOT BE
>> OPEN
>> >> > WITH
>> >> > RED THAT NO ONE OWNS.  Help the sheriffs out with this -- they can't
>> >> > watch
>> >> > every second.  Closed trees suck; unowned bustage sucks more.  Be
>> >> > hard-nosed.
>> >> > * Yes, even purify, valgrind, and reliability bot redness.  If you
>> can't
>> >> > figure out what to do with these, try pinging erikkay for purify
>> issues
>> >> > and
>> >> > huanr for reliability issues.  (Not sure who a good general valgrind
>> >> > contact
>> >> > is.)
>> >> > * If you ever look at the buildbot and see orange ("unexpected
>> pass"),
>> >> > especially in the WebKit LayoutTest bots, ping the WebKit sheriff
>> (the
>> >> > calendar is linked from the top
>> >> > of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I
>> don't
>> >> > know
>> >> > whether it's world-readable).  If he wasn't aware of it, agree
>> between
>> >> > you
>> >> > on who will deal with it.  Orange alone is not reason to close the
>> tree,
>> >> > but
>> >> > it should NOT be ignored.
>> >> > * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE.  If
>> >> > they're
>> >> > really fixed by someone's commit, that should be easy to determine.
>> >> >  Otherwise, they're flaky, and we NEED to mark them as such, not just
>> >> > leave
>> >> > them.
>> >> > ***
>> >> > Finally, how to help if the LayoutTest bots are red or orange:
>> >> > (1) Try and determine if the test(s) are consistently passing/failing
>> >> > unexpectedly, or if they're flaky.  Make sure you look at all the
>> >> > different
>> >> > bots to see which OSes are affected.
>> >> > (2) Update src/webkit/tools/layout_tests/test-expectations.txt.  Look
>> >> > for
>> >> > the test(s) in question.  Often, flaky tests will already be in there
>> as
>> >> > failing or flaky for one O

[chromium-dev] Dev Chrome crashes on subsequent starts after installing a theme

[Gobbledegook]

Hi,

I've been unable to get into chrome dev (latest) ever since I
installed the Baseball theme. Everything worked fine till my computer
crashed (unrelated to chrome / a USB - windows sleep mode driver
incompatibility)

It just gives the Whoa! Google has crashed error.

I uninstalled and tried reinstalling but it still refuses to work. I
didn't want to lose my history so I didn't try doing a completely
clean reinstall. However, I'm now on the beta channel and it's working
fine.

Toshiba A300D-15B dual core 2.1GHz AMD laptop
4 GB RAM
Windows 7 RTM (build 7600) 64 bit

Steps to recreate scenario:

1. Install Google Chrome Dev channel version.
2. Open 5 tabs.
3. Install the baseball theme and keep Chrome running.
4. Put Windows into Sleep mode.
5. Wake up windows.
6. Do a hard restart (do not safely restart the computer but use the
power button if you're on a laptop or reset button if ure on a
desktop)
7. Run Windows normally.
8. Try to start Google Chrome.

It should crash.

--~--~-~--~~~---~--~~
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: Flakiness. Please help.

[Nicolas Sylvain]

On Thu, Aug 6, 2009 at 1:05 PM, Scott Violet  wrote:

>
> Not sure, perhaps Huan could answer that. That said, --enable-dcheck
> certainly works on the Chromium release builds from the buildbot:
> http://build.chromium.org/buildbot/continuous/LATEST/ .


Yes, --enable-dcheck is supposed to be disabled in Google Chrome build.

Nicolas


>
>
>  -Scott
>
> On Thu, Aug 6, 2009 at 12:59 PM, Antony Sargent
> wrote:
> > To clarify, doesn't --enable-dcheck only work on chromium release builds
> you
> > built yourself and not official builds of Google Chrome?
> >
> > On Thu, Aug 6, 2009 at 10:15 AM, Scott Violet  wrote:
> >>
> >> One easy suggestion in helping catch bugs is to run Chrome with
> >> --enable-dcheck . This'll prompt if you hit a DCHECK in release builds
> >> and hopefully help isolate crashes before the fact.
> >>
> >>  -Scott
> >>
> >> On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting
> wrote:
> >> > THIS MAIL APPLIES TO YOU
> >> > Flakiness is growing.  Smash it before it gets bigger, and keep it
> >> > smashed.
> >> > ***
> >> > The MOST IMPORTANT section in this gigantic mail:
> >> > PLEASE spend some of every workday (or each week at least, if you
> can't
> >> > spare time each day) looking at test failures, flakiness,
> >> > valgrind/purify/coverity bugs, crashes, and/or memory bugs.  Make it a
> >> > goal
> >> > to get an average of one line in the test-expectations file removed
> each
> >> > day.  If you're a Googler, put it on your OKRs (now, not sometime
> >> > tomorrow).
> >> > * DON'T wait for someone to assign bugs to you or ask for your help
> >> > * DON'T wait for a team fixit week (those haven't worked)
> >> > * DON'T wait for someone else to solve the problems
> >> > * DON'T wait until after your current project is finished
> >> > * DON'T wait until you have worked on WebKit
> >> > HELP, even if it's just a little, even if it's not your core
> competence.
> >> >  We
> >> > currently have hundreds upon hundreds of failing or flaky tests.  We
> can
> >> > dramatically reduce this quickly but ONLY IF YOU HELP.  This is an
> >> > investment not only in the quality of Chrome but in the team's ability
> >> > to
> >> > move fast, so help here doesn't just improve the quality of Chrome,
> but
> >> > also
> >> > the derivative of the quality :)
> >> > (If you do not know how to do anything above and need handholding,
> >> > e-mail me
> >> > and I will help you.  It's OK to be ignorant.)
> >> > ***
> >> > Next, how you should help keep the tree green at all times:
> >> > * If you ever look at the buildbot and see red, and there's no
> >> > explanation
> >> > in the build status, ask what's going on on #chromium.  Ping the
> >> > sheriffs
> >> > specifically (they're listed in the upper-right corner).  If you do
> not
> >> > get
> >> > an answer about ownership within a few minutes, close the tree (if you
> >> > have
> >> > the rights to) or ask someone to close it.  THE TREE SHOULD NOT BE
> OPEN
> >> > WITH
> >> > RED THAT NO ONE OWNS.  Help the sheriffs out with this -- they can't
> >> > watch
> >> > every second.  Closed trees suck; unowned bustage sucks more.  Be
> >> > hard-nosed.
> >> > * Yes, even purify, valgrind, and reliability bot redness.  If you
> can't
> >> > figure out what to do with these, try pinging erikkay for purify
> issues
> >> > and
> >> > huanr for reliability issues.  (Not sure who a good general valgrind
> >> > contact
> >> > is.)
> >> > * If you ever look at the buildbot and see orange ("unexpected pass"),
> >> > especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the
> >> > calendar is linked from the top
> >> > of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I
> don't
> >> > know
> >> > whether it's world-readable).  If he wasn't aware of it, agree between
> >> > you
> >> > on who will deal with it.  Orange alone is not reason to close the
> tree,
> >> > but
> >> > it should NOT be ignored.
> >> > * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE.  If
> >> > they're
> >> > really fixed by someone's commit, that should be easy to determine.
> >> >  Otherwise, they're flaky, and we NEED to mark them as such, not just
> >> > leave
> >> > them.
> >> > ***
> >> > Finally, how to help if the LayoutTest bots are red or orange:
> >> > (1) Try and determine if the test(s) are consistently passing/failing
> >> > unexpectedly, or if they're flaky.  Make sure you look at all the
> >> > different
> >> > bots to see which OSes are affected.
> >> > (2) Update src/webkit/tools/layout_tests/test-expectations.txt.  Look
> >> > for
> >> > the test(s) in question.  Often, flaky tests will already be in there
> as
> >> > failing or flaky for one OS, and need to have more added; or they will
> >> > be
> >> > marked flaky ("FAIL PASS") and need "CRASH" added.  If they're not
> >> > there,
> >> > add a line.
> >> > (3) Ensure the test(s) have a bug on file.  Note the bug on the
> >> > expectation.
> >> > (4) If any tests are crashing (flaky or not), t

[chromium-dev] Re: Running UI test in parallel (experimental)

[John Abd-El-Malek]

This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrome>tools\test\smoketests.py --tests=ui

>> You must have your local path of trunk/src/tools/python added to your
PYTHONPATH.<<

Traceback (most recent call last):
  File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 32, in

import google.httpd_utils
ImportError: No module named google.httpd_utils


hmmm, never needed PYTHONPATH set before.  Can't this script set it itself?
 Setting it manually will fail when I move depot locations etc..  But
anyways, I set it and then

a:\chrome2\src\chrome>set PYTHONPATH=a:\chrome\src\tools\python

a:\chrome2\src\chrome>tools\test\smoketests.py --tests=ui
Traceback (most recent call last):
  File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 274, in

result = main(options, args)
  File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 155, in main
sys.path.insert(0, _BuildbotScriptPath('slave'))
  File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 84, in
_BuildbotScriptPath
'scripts', sub_dir)
  File "a:\chrome\src\tools\python\google\path_utils.py", line 72, in
FindUpward
parent = FindUpwardParent(start_dir, *desired_list)
  File "a:\chrome\src\tools\python\google\path_utils.py", line 55, in
FindUpwardParent
(desired_path, start_dir))
google.path_utils.PathNotFound: Unable to find tools\buildbot\scripts\slave
above A:\chrome2\src\chrome\tools\test



tools\buildbot isn't in the public tree I think, since I don't find it
here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/.  So
external contributors can't use this?  Also, why should this script depend
on the buildbot scripts?  I don't have them so I can't try this out.

Can't we just have a minimal python script that runs ui_tests in parallel?

On Wed, Jul 29, 2009 at 3:28 PM, Huan Ren  wrote:

>
> I just checked in a change to run ui_tests in parallel based on
> sharding mechanism provided by GTest. Each ui_tests instance has its
> own user data dir, and the number of ui_tests instances is
> NUMBER_OF_PROCESSORS. I have updated
> src/chrome/tools/test/smoketests.py so you can run it through command
> line:
>
> python.exe smoketests.py --tests=ui [--verbose]
>
> Running ui_tests.exe directly is still the old behavior of
> sequentially running. On my 4 core machine, the running time has been
> reduced by half, from 832 secs to 443 secs. But I need to make sure
> all tests can run reliably in this parallel fashion. So if you try it
> out, I will be interested to know how fast the performance is improved
> and what additional tests are failing.
>
> Huan
>
> P.S. this change is for Windows platform as I think Linux/Mac is
> already using GTest sharding.
>
> >
>

--~--~-~--~~~---~--~~
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: Flakiness. Please help.

[Scott Violet]

Not sure, perhaps Huan could answer that. That said, --enable-dcheck
certainly works on the Chromium release builds from the buildbot:
http://build.chromium.org/buildbot/continuous/LATEST/ .

  -Scott

On Thu, Aug 6, 2009 at 12:59 PM, Antony Sargent wrote:
> To clarify, doesn't --enable-dcheck only work on chromium release builds you
> built yourself and not official builds of Google Chrome?
>
> On Thu, Aug 6, 2009 at 10:15 AM, Scott Violet  wrote:
>>
>> One easy suggestion in helping catch bugs is to run Chrome with
>> --enable-dcheck . This'll prompt if you hit a DCHECK in release builds
>> and hopefully help isolate crashes before the fact.
>>
>>  -Scott
>>
>> On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting wrote:
>> > THIS MAIL APPLIES TO YOU
>> > Flakiness is growing.  Smash it before it gets bigger, and keep it
>> > smashed.
>> > ***
>> > The MOST IMPORTANT section in this gigantic mail:
>> > PLEASE spend some of every workday (or each week at least, if you can't
>> > spare time each day) looking at test failures, flakiness,
>> > valgrind/purify/coverity bugs, crashes, and/or memory bugs.  Make it a
>> > goal
>> > to get an average of one line in the test-expectations file removed each
>> > day.  If you're a Googler, put it on your OKRs (now, not sometime
>> > tomorrow).
>> > * DON'T wait for someone to assign bugs to you or ask for your help
>> > * DON'T wait for a team fixit week (those haven't worked)
>> > * DON'T wait for someone else to solve the problems
>> > * DON'T wait until after your current project is finished
>> > * DON'T wait until you have worked on WebKit
>> > HELP, even if it's just a little, even if it's not your core competence.
>> >  We
>> > currently have hundreds upon hundreds of failing or flaky tests.  We can
>> > dramatically reduce this quickly but ONLY IF YOU HELP.  This is an
>> > investment not only in the quality of Chrome but in the team's ability
>> > to
>> > move fast, so help here doesn't just improve the quality of Chrome, but
>> > also
>> > the derivative of the quality :)
>> > (If you do not know how to do anything above and need handholding,
>> > e-mail me
>> > and I will help you.  It's OK to be ignorant.)
>> > ***
>> > Next, how you should help keep the tree green at all times:
>> > * If you ever look at the buildbot and see red, and there's no
>> > explanation
>> > in the build status, ask what's going on on #chromium.  Ping the
>> > sheriffs
>> > specifically (they're listed in the upper-right corner).  If you do not
>> > get
>> > an answer about ownership within a few minutes, close the tree (if you
>> > have
>> > the rights to) or ask someone to close it.  THE TREE SHOULD NOT BE OPEN
>> > WITH
>> > RED THAT NO ONE OWNS.  Help the sheriffs out with this -- they can't
>> > watch
>> > every second.  Closed trees suck; unowned bustage sucks more.  Be
>> > hard-nosed.
>> > * Yes, even purify, valgrind, and reliability bot redness.  If you can't
>> > figure out what to do with these, try pinging erikkay for purify issues
>> > and
>> > huanr for reliability issues.  (Not sure who a good general valgrind
>> > contact
>> > is.)
>> > * If you ever look at the buildbot and see orange ("unexpected pass"),
>> > especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the
>> > calendar is linked from the top
>> > of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't
>> > know
>> > whether it's world-readable).  If he wasn't aware of it, agree between
>> > you
>> > on who will deal with it.  Orange alone is not reason to close the tree,
>> > but
>> > it should NOT be ignored.
>> > * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE.  If
>> > they're
>> > really fixed by someone's commit, that should be easy to determine.
>> >  Otherwise, they're flaky, and we NEED to mark them as such, not just
>> > leave
>> > them.
>> > ***
>> > Finally, how to help if the LayoutTest bots are red or orange:
>> > (1) Try and determine if the test(s) are consistently passing/failing
>> > unexpectedly, or if they're flaky.  Make sure you look at all the
>> > different
>> > bots to see which OSes are affected.
>> > (2) Update src/webkit/tools/layout_tests/test-expectations.txt.  Look
>> > for
>> > the test(s) in question.  Often, flaky tests will already be in there as
>> > failing or flaky for one OS, and need to have more added; or they will
>> > be
>> > marked flaky ("FAIL PASS") and need "CRASH" added.  If they're not
>> > there,
>> > add a line.
>> > (3) Ensure the test(s) have a bug on file.  Note the bug on the
>> > expectation.
>> > (4) If any tests are crashing (flaky or not), they're high-priority and
>> > someone needs to triage them.  Today, dglazkov was WebKit sheriff and
>> > was
>> > having me mark these bugs as P1, Mstone-3, owner:dglazkov.  I'm not sure
>> > whether the Right Thing is to assign them to the WebKit sheriff or still
>> > to
>> > him (feel free to comment, dglazkov!).  Why are these P1?  Because until
>> > we
>> > prove they 

[chromium-dev] Re: Flakiness. Please help.

[Antony Sargent]

To clarify, doesn't --enable-dcheck only work on chromium release builds you
built yourself and not official builds of Google Chrome?

On Thu, Aug 6, 2009 at 10:15 AM, Scott Violet  wrote:

>
> One easy suggestion in helping catch bugs is to run Chrome with
> --enable-dcheck . This'll prompt if you hit a DCHECK in release builds
> and hopefully help isolate crashes before the fact.
>
>  -Scott
>
> On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting wrote:
> > THIS MAIL APPLIES TO YOU
> > Flakiness is growing.  Smash it before it gets bigger, and keep it
> smashed.
> > ***
> > The MOST IMPORTANT section in this gigantic mail:
> > PLEASE spend some of every workday (or each week at least, if you can't
> > spare time each day) looking at test failures, flakiness,
> > valgrind/purify/coverity bugs, crashes, and/or memory bugs.  Make it a
> goal
> > to get an average of one line in the test-expectations file removed each
> > day.  If you're a Googler, put it on your OKRs (now, not sometime
> tomorrow).
> > * DON'T wait for someone to assign bugs to you or ask for your help
> > * DON'T wait for a team fixit week (those haven't worked)
> > * DON'T wait for someone else to solve the problems
> > * DON'T wait until after your current project is finished
> > * DON'T wait until you have worked on WebKit
> > HELP, even if it's just a little, even if it's not your core competence.
>  We
> > currently have hundreds upon hundreds of failing or flaky tests.  We can
> > dramatically reduce this quickly but ONLY IF YOU HELP.  This is an
> > investment not only in the quality of Chrome but in the team's ability to
> > move fast, so help here doesn't just improve the quality of Chrome, but
> also
> > the derivative of the quality :)
> > (If you do not know how to do anything above and need handholding, e-mail
> me
> > and I will help you.  It's OK to be ignorant.)
> > ***
> > Next, how you should help keep the tree green at all times:
> > * If you ever look at the buildbot and see red, and there's no
> explanation
> > in the build status, ask what's going on on #chromium.  Ping the sheriffs
> > specifically (they're listed in the upper-right corner).  If you do not
> get
> > an answer about ownership within a few minutes, close the tree (if you
> have
> > the rights to) or ask someone to close it.  THE TREE SHOULD NOT BE OPEN
> WITH
> > RED THAT NO ONE OWNS.  Help the sheriffs out with this -- they can't
> watch
> > every second.  Closed trees suck; unowned bustage sucks more.  Be
> > hard-nosed.
> > * Yes, even purify, valgrind, and reliability bot redness.  If you can't
> > figure out what to do with these, try pinging erikkay for purify issues
> and
> > huanr for reliability issues.  (Not sure who a good general valgrind
> contact
> > is.)
> > * If you ever look at the buildbot and see orange ("unexpected pass"),
> > especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the
> > calendar is linked from the top
> > of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't
> know
> > whether it's world-readable).  If he wasn't aware of it, agree between
> you
> > on who will deal with it.  Orange alone is not reason to close the tree,
> but
> > it should NOT be ignored.
> > * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE.  If
> they're
> > really fixed by someone's commit, that should be easy to determine.
> >  Otherwise, they're flaky, and we NEED to mark them as such, not just
> leave
> > them.
> > ***
> > Finally, how to help if the LayoutTest bots are red or orange:
> > (1) Try and determine if the test(s) are consistently passing/failing
> > unexpectedly, or if they're flaky.  Make sure you look at all the
> different
> > bots to see which OSes are affected.
> > (2) Update src/webkit/tools/layout_tests/test-expectations.txt.  Look for
> > the test(s) in question.  Often, flaky tests will already be in there as
> > failing or flaky for one OS, and need to have more added; or they will be
> > marked flaky ("FAIL PASS") and need "CRASH" added.  If they're not there,
> > add a line.
> > (3) Ensure the test(s) have a bug on file.  Note the bug on the
> expectation.
> > (4) If any tests are crashing (flaky or not), they're high-priority and
> > someone needs to triage them.  Today, dglazkov was WebKit sheriff and was
> > having me mark these bugs as P1, Mstone-3, owner:dglazkov.  I'm not sure
> > whether the Right Thing is to assign them to the WebKit sheriff or still
> to
> > him (feel free to comment, dglazkov!).  Why are these P1?  Because until
> we
> > prove they can't affect Chrome itself, they potentially can, and Chrome
> > crashes are always P1.  They affect stability and security both.
> > (5) If you have commit rights, go ahead and TBR test-expectations changes
> > you're confident of.  I even suggest using --force if the tree is closed.
> >  Updating expectations is like fixing bustage, it helps the tree go green
> > faster and thus is almost always desirable.  If you don't have c

[chromium-dev] crashing on startup

[Evan Martin]

A few people have found their trunk builds crashing on startup.
This comes from a bug in theme loading and can bite you if you
installed some of the in-development themes.
The fix is to rm -rf your "Extensions" directory out of your profile directory.
The next release will have the bug fixed, and at that point these
themes will no longer cause crashes.

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[Peter Kasting]

On Thu, Aug 6, 2009 at 8:59 AM, Pam Greene  wrote:

> I've been using a local copy with this change (add all files to a new
> change, but not to an existing one) forever, but last I checked around, some
> people prefer the "always copy-paste" model. I'd be glad to check in my
> change if the consensus agrees.


Yes, please do this.  laforge's behavior is awesome as long as the "bug" of
subsequent modifications doesn't affect it.

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: Git usage in chromium

[Peter Kasting]

On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafai  wrote:

> I've been wondering about this. What would it take to modify our git
> checkout process to pull third_party/WebKit via git as well? Would it mostly
> work to just exclude third_party/WebKit via DEPS, create it via a git
> checkout and then write a script that wraps gclient sync to also git
> pull/rebase third_party/WebKit? Is there a better way?
>
> I'd like to have a git checkout of tip of tree trunk/src and tip of tree
> WebKit so I can have one tree for developing both Chrome and WebKit.
>

You can do this via svn; abarth started a thread about it several weeks ago
with a link to an instructions wiki page, and I have been fixing bugs on the
WebKit side to make it viable for development.

Dunno how to do it with git though, sorry.

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: The program 'chrome' received an X Window System error

[Evan Martin]

On Wed, Aug 5, 2009 at 5:51 PM, Albert Bachand wrote:
> Thanks, that was useful. The IPC messages right before the crash are:
>
> ipc 1855.ba2d400.22596386 3  ViewHostMsg_PaintRect (171016409, (0, 0, 1, 1),
> (1, 1), , 1)
> ipc 1855.ba2d400.22596386 3  ViewHostMsg_RenderViewReady
> ipc 1855.ba2d400.22596386 3  ViewHostMsg_DidStartLoading
> ipc 1855.ba2d400.22596386 3  ViewHostMsg_DidStartProvisionalLoadForFrame
> true, chrome://about/linux-splash
>
> Digging through the code it looks like the problem has to do with drawing
> the TabContentsViewGtk widgets. As far as I can tell, those widgets are not
> children of the GtkWindow widget which I'm drawing on the remote X screen.
> And since TabContentsViewGtk creates a custom widget (GtkFloatingContainer)
> that doesn't define a set_screen() function, I can't move that widget to the
> remote X screen.
>
> There's a few widgets that support being moved to a remote X screen
> (GtkWindow, GtkMenu, GtkInvisible, etc.) maybe the solution is to make
> GtkFloatingContainer support that as well. I'll keep digging...

Only top-level widgets should need a set_screen function, as otherwise
(as I understand it) the screen is inherited from the parent widget.
That's why for example GtkMenu has it (menus are top-level windows,
not children of the thing that popped it up).

As we discussed earlier, if I had to guess I'd say it's related to the
way we handle backing stores.  Generally we don't do any tricks with X
so it all should Just Work but the way renderers paint is very
complicated.

You could try stubbing out some of the functions in backing_store_x.cc
to see if you can make it neither crash nor draw anything, then go
from there.  I see a call to a function "x11_util::GetXDisplay()" that
seems like a good one to set a breakpoint on so you can trace it
backwards up to its caller, as that kind of call is surely the source
of these sorts of errors.

--~--~-~--~~~---~--~~
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: Git usage in chromium

[王重傑]

On Thu, Aug 6, 2009 at 10:36 AM, Evan Martin  wrote:

>
> On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafai wrote:
> >> After following the instructions in that document trunk/src is git and
> >> everything else (pulled in via DEPS, including webkit and also ICU,
> >> skia, etc.) is via svn.
> >
> > I've been wondering about this. What would it take to modify our git
> > checkout process to pull third_party/WebKit via git as well? Would it
> mostly
> > work to just exclude third_party/WebKit via DEPS, create it via a git
> > checkout and then write a script that wraps gclient sync to also git
> > pull/rebase third_party/WebKit? Is there a better way?
>
> I had an old version of gclient that did this.  The problem you run
> into is that there are more possible tree states of git than in svn so
> it's hard to map across.
>
> Say DEPS says web...@revision A, and you have webkit at revision A~10.
> gclient sync should probably fast-forward your checkout.
>
> Say DEPS says web...@revision A, and then you've checked out trunk and
> have local changes.  gclient sync should probably... do nothing?
>
> But then how do we tell "DEPS checked them out at A~10 before, so we
> should fast forward to A" from "they checked out A~10 because that was
> trunk at the time, so we should fast forward to trunk"?
>
> Etc.  It's basically some UI questions that I haven't had the time to
> worry about yet.


Currently, I just manage the webkit changes by hand rather than letting
gclient do it.

I have a git checkout of webkit symlinked (mounted in XP since symlinks
don't work right until vista) on top of third_party/WebKit.  You'll need to
add the following into the custom_deps of your .gclient:

  "src/third_party/WebKit/JavaScriptCore": None,
  "src/third_party/WebKit/WebCore": None,
  "src/third_party/WebKit/WebKitLibraries": None,
  "src/third_party/WebKit/LayoutTests": None,


Then after a gclient sync, to get a branch of webkit at the right revision +
all the build files regenerated, I do some variant of

ajwong$ i=`head ~/src/git-chrome/src/DEPS | grep webkit_revision | cut
-d '"' -f4`; git checkout -b $i `git svn find-rev r$i`
ajwong$ i gclient runhooks --force


Any of the merges/cherry-pick of current work off the webkit tree, I do by
hand.  It's been working pretty well for me.

-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: gcl change that you should be aware of

[Darin Fisher]

On Thu, Aug 6, 2009 at 6:12 AM, Thomas Van Lenten wrote:

>
>
> On Thu, Aug 6, 2009 at 3:51 AM, Adam Barth  wrote:
>
>>
>> Perhaps a better default is to use this behavior when first creating a
>> changelist and to use the old behavior when modifying a changelist.
>
>
> +1
>
> TVL
>


I agree.  This sounds like a nice compromise.
-Darin



>
>
>>
>>
>> Adam
>>
>>
>> On Thu, Aug 6, 2009 at 12:37 AM, Dirk Pranke wrote:
>> >
>> > I also fear that I may have unwanted files sneaking in. This was less
>> > of an issue with Perforce since you have to manually 'p4 edit' files
>> > first anyway.
>> >
>> > I'll be curious to see if there's a consensus preference one way or
>> > another. Maybe we can make this a gclient config setting or something?
>> >
>> > -- Dirk
>> >
>> > On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisher
>> wrote:
>> >> This seemed really great at first, but after some use, I find it a bit
>> >> frustrating since each time I run "gcl change", I now have to be
>> mindful
>> >> that gcl may add unwanted files to the CL.  The only way I've found to
>> avoid
>> >> this is to make sure that unwanted files are part of a dummy CL :-(
>> >> -Darin
>> >>
>> >>
>> >>
>> >> On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge 
>> wrote:
>> >>>
>> >>> Howdy,
>> >>> Quick little change to gcl that everyone should be aware of.  When you
>> >>> execute the script it will now automatically pull all physically
>> modified
>> >>> files into the "Paths in this changelist" section, which means no more
>> >>> copying and pasting the files you changed into your CL.  The behavior
>> is
>> >>> closer to that of P4 (where we delete files as opposed to adding
>> them).  All
>> >>> the unchanged files are still below.
>> >>> Kind Regards,
>> >>>
>> >>> Anthony Laforge
>> >>> Technical Program Manager
>> >>> Mountain View, CA
>> >>>
>> >>>
>> >>
>> >>
>> >> >
>> >>
>> >
>> > >
>> >
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: new Linux custom frame

[Evan Martin]

Yes, it's too bad that our dev channel release got bad padding on the
buttons.  I've seen a few comments online to the effect of "this is so
ugly how can I turn it off".  I fear people will turn it off then and
not discover it has improved since.

I think we're gonna tweak them one more time before we stop touching
them, though.

On Thu, Aug 6, 2009 at 10:29 AM, Paweł Hajdan
Jr. wrote:
> I just saw the new Linux custom frame buttons when compiled today from
> trunk. With the new increased padding it looks really well. I like 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: Git usage in chromium

[Evan Martin]

On Thu, Aug 6, 2009 at 10:15 AM, Ojan Vafai wrote:
>> After following the instructions in that document trunk/src is git and
>> everything else (pulled in via DEPS, including webkit and also ICU,
>> skia, etc.) is via svn.
>
> I've been wondering about this. What would it take to modify our git
> checkout process to pull third_party/WebKit via git as well? Would it mostly
> work to just exclude third_party/WebKit via DEPS, create it via a git
> checkout and then write a script that wraps gclient sync to also git
> pull/rebase third_party/WebKit? Is there a better way?

I had an old version of gclient that did this.  The problem you run
into is that there are more possible tree states of git than in svn so
it's hard to map across.

Say DEPS says web...@revision A, and you have webkit at revision A~10.
gclient sync should probably fast-forward your checkout.

Say DEPS says web...@revision A, and then you've checked out trunk and
have local changes.  gclient sync should probably... do nothing?

But then how do we tell "DEPS checked them out at A~10 before, so we
should fast forward to A" from "they checked out A~10 because that was
trunk at the time, so we should fast forward to trunk"?

Etc.  It's basically some UI questions that I haven't had the time to
worry about yet.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] new Linux custom frame

[Paweł Hajdan Jr .]

I just saw the new Linux custom frame buttons when compiled today from
trunk. With the new increased padding it looks really well. I like 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: Urgent, a very evil site i think which does evil things (no joke)

[Thomas Van Lenten]

On Thu, Aug 6, 2009 at 1:16 PM, Miguel F Mascarenhas Sousa Filipe <
miguel.fil...@gmail.com> wrote:

> Hi,
>
> On Thu, Aug 6, 2009 at 6:08 PM, Jeremy Orlow  wrote:
>
>> Yoav everyone on this thread is a Chromium developer and almost everyone
>> posting in this thread (not me) are some of the top developers working on
>> Chrome and many of them have spent a good deal of time working on sandbox
>> related issues.
>> All of us have a healthy disrespect for the "impossible" and would
>> definitely like to see plugin's sandboxed by default, but it's a very
>> difficult problem.  We're working hard on many fronts like making more stuff
>> possible without plugins (HTML 5), new technologies (NaCl), etc to change
>> the status quo.
>>
>
> Sorry to intrude, but can you explain what NaCl are you talking ?
> Is it this one: http://nacl.cr.yp.to/
> And what kind of work/use is being thought for NaCl + chromium.
> I'm asking this because I've looked at NaCl recently and seems very
> interesting..
>

Nope, this one: http://code.google.com/p/nativeclient/

TVL


>
> kind regards,
>
>
>
>
>>
>> I know it doesn't mean much to you, but I've met and/or worked with many
>> of the developers that reached the conclusion that sandboxing plugins isn't
>> practical (at least by default) and I can say that they're not only some of
>> the smartest developers I've ever met, but that the decision was also
>> painful to them.
>>
>> If you wanted to help, patches would be great.  But I think it'd also be
>> helpful if you turned it on and filed bugs when you hit compat issues.
>>
>> I'm not sure there's much else to say on the topic...
>>
>> J
>>
>>
>> On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth  wrote:
>>
>>>
>>> I don't really understand why you find Alex's message so frustrating.
>>> We'd love to make --safe-plugins the default.  One road to getting
>>> there is having more people use the option and find the
>>> incompatibilities.  We'd certainly welcome patches that improve it's
>>> compatibility.  If we can make it work well enough, then we can turn
>>> it on by default and everyone wins.
>>>
>>> Adam
>>>
>>>
>>> On Thu, Aug 6, 2009 at 9:46 AM, yoav
>>> zilberberg wrote:
>>> > Alex, let me get it, are you part of the chrome team ? i don't recall
>>> > accusing anyone from chrome
>>> > but i do recall not liking your reply, so just let me know if you are
>>> part
>>> > of the devs of chrome please
>>> > i will be honest, if you are, then i think it is time for me to move to
>>> a
>>> > different browser, if you are not
>>> > then don't decide if i accuse the chrome team or not, let them tell me,
>>> and
>>> > like i said
>>> > i would remove myself in a second and with no hard feelings
>>> >
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Miguel Sousa Filipe
>
>
> >
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Jeremy Orlow]

On Thu, Aug 6, 2009 at 10:16 AM, Miguel F Mascarenhas Sousa Filipe <
miguel.fil...@gmail.com> wrote:

> Hi,
>
> On Thu, Aug 6, 2009 at 6:08 PM, Jeremy Orlow  wrote:
>
>> Yoav everyone on this thread is a Chromium developer and almost everyone
>> posting in this thread (not me) are some of the top developers working on
>> Chrome and many of them have spent a good deal of time working on sandbox
>> related issues.
>> All of us have a healthy disrespect for the "impossible" and would
>> definitely like to see plugin's sandboxed by default, but it's a very
>> difficult problem.  We're working hard on many fronts like making more stuff
>> possible without plugins (HTML 5), new technologies (NaCl), etc to change
>> the status quo.
>>
>
> Sorry to intrude, but can you explain what NaCl are you talking ?
> Is it this one: http://nacl.cr.yp.to/
>

I was talking about this one: http://code.google.com/p/nativeclient/


> 
> And what kind of work/use is being thought for NaCl + chromium.
> I'm asking this because I've looked at NaCl recently and seems very
> interesting..
>
> kind regards,
>
>
>
>
>>
>> I know it doesn't mean much to you, but I've met and/or worked with many
>> of the developers that reached the conclusion that sandboxing plugins isn't
>> practical (at least by default) and I can say that they're not only some of
>> the smartest developers I've ever met, but that the decision was also
>> painful to them.
>>
>> If you wanted to help, patches would be great.  But I think it'd also be
>> helpful if you turned it on and filed bugs when you hit compat issues.
>>
>> I'm not sure there's much else to say on the topic...
>>
>> J
>>
>>
>> On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth  wrote:
>>
>>>
>>> I don't really understand why you find Alex's message so frustrating.
>>> We'd love to make --safe-plugins the default.  One road to getting
>>> there is having more people use the option and find the
>>> incompatibilities.  We'd certainly welcome patches that improve it's
>>> compatibility.  If we can make it work well enough, then we can turn
>>> it on by default and everyone wins.
>>>
>>> Adam
>>>
>>>
>>> On Thu, Aug 6, 2009 at 9:46 AM, yoav
>>> zilberberg wrote:
>>> > Alex, let me get it, are you part of the chrome team ? i don't recall
>>> > accusing anyone from chrome
>>> > but i do recall not liking your reply, so just let me know if you are
>>> part
>>> > of the devs of chrome please
>>> > i will be honest, if you are, then i think it is time for me to move to
>>> a
>>> > different browser, if you are not
>>> > then don't decide if i accuse the chrome team or not, let them tell me,
>>> and
>>> > like i said
>>> > i would remove myself in a second and with no hard feelings
>>> >
>>>
>>>
>>>
>>
>> >>
>>
>
>
> --
> Miguel Sousa Filipe
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Miguel F Mascarenhas Sousa Filipe]

Hi,

On Thu, Aug 6, 2009 at 6:08 PM, Jeremy Orlow  wrote:

> Yoav everyone on this thread is a Chromium developer and almost everyone
> posting in this thread (not me) are some of the top developers working on
> Chrome and many of them have spent a good deal of time working on sandbox
> related issues.
> All of us have a healthy disrespect for the "impossible" and would
> definitely like to see plugin's sandboxed by default, but it's a very
> difficult problem.  We're working hard on many fronts like making more stuff
> possible without plugins (HTML 5), new technologies (NaCl), etc to change
> the status quo.
>

Sorry to intrude, but can you explain what NaCl are you talking ?
Is it this one: http://nacl.cr.yp.to/
And what kind of work/use is being thought for NaCl + chromium.
I'm asking this because I've looked at NaCl recently and seems very
interesting..

kind regards,




>
> I know it doesn't mean much to you, but I've met and/or worked with many of
> the developers that reached the conclusion that sandboxing plugins isn't
> practical (at least by default) and I can say that they're not only some of
> the smartest developers I've ever met, but that the decision was also
> painful to them.
>
> If you wanted to help, patches would be great.  But I think it'd also be
> helpful if you turned it on and filed bugs when you hit compat issues.
>
> I'm not sure there's much else to say on the topic...
>
> J
>
>
> On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth  wrote:
>
>>
>> I don't really understand why you find Alex's message so frustrating.
>> We'd love to make --safe-plugins the default.  One road to getting
>> there is having more people use the option and find the
>> incompatibilities.  We'd certainly welcome patches that improve it's
>> compatibility.  If we can make it work well enough, then we can turn
>> it on by default and everyone wins.
>>
>> Adam
>>
>>
>> On Thu, Aug 6, 2009 at 9:46 AM, yoav
>> zilberberg wrote:
>> > Alex, let me get it, are you part of the chrome team ? i don't recall
>> > accusing anyone from chrome
>> > but i do recall not liking your reply, so just let me know if you are
>> part
>> > of the devs of chrome please
>> > i will be honest, if you are, then i think it is time for me to move to
>> a
>> > different browser, if you are not
>> > then don't decide if i accuse the chrome team or not, let them tell me,
>> and
>> > like i said
>> > i would remove myself in a second and with no hard feelings
>> >
>>
>>
>>
>
> >
>


-- 
Miguel Sousa Filipe

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[yoav zilberberg]

I apologize, i had no idea all of you are chrome devs, and i shall indeed
happily remove myself
thanx for answering, and best of luck you all.

--~--~-~--~~~---~--~~
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: Flakiness. Please help.

[Scott Violet]

One easy suggestion in helping catch bugs is to run Chrome with
--enable-dcheck . This'll prompt if you hit a DCHECK in release builds
and hopefully help isolate crashes before the fact.

  -Scott

On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting wrote:
> THIS MAIL APPLIES TO YOU
> Flakiness is growing.  Smash it before it gets bigger, and keep it smashed.
> ***
> The MOST IMPORTANT section in this gigantic mail:
> PLEASE spend some of every workday (or each week at least, if you can't
> spare time each day) looking at test failures, flakiness,
> valgrind/purify/coverity bugs, crashes, and/or memory bugs.  Make it a goal
> to get an average of one line in the test-expectations file removed each
> day.  If you're a Googler, put it on your OKRs (now, not sometime tomorrow).
> * DON'T wait for someone to assign bugs to you or ask for your help
> * DON'T wait for a team fixit week (those haven't worked)
> * DON'T wait for someone else to solve the problems
> * DON'T wait until after your current project is finished
> * DON'T wait until you have worked on WebKit
> HELP, even if it's just a little, even if it's not your core competence.  We
> currently have hundreds upon hundreds of failing or flaky tests.  We can
> dramatically reduce this quickly but ONLY IF YOU HELP.  This is an
> investment not only in the quality of Chrome but in the team's ability to
> move fast, so help here doesn't just improve the quality of Chrome, but also
> the derivative of the quality :)
> (If you do not know how to do anything above and need handholding, e-mail me
> and I will help you.  It's OK to be ignorant.)
> ***
> Next, how you should help keep the tree green at all times:
> * If you ever look at the buildbot and see red, and there's no explanation
> in the build status, ask what's going on on #chromium.  Ping the sheriffs
> specifically (they're listed in the upper-right corner).  If you do not get
> an answer about ownership within a few minutes, close the tree (if you have
> the rights to) or ask someone to close it.  THE TREE SHOULD NOT BE OPEN WITH
> RED THAT NO ONE OWNS.  Help the sheriffs out with this -- they can't watch
> every second.  Closed trees suck; unowned bustage sucks more.  Be
> hard-nosed.
> * Yes, even purify, valgrind, and reliability bot redness.  If you can't
> figure out what to do with these, try pinging erikkay for purify issues and
> huanr for reliability issues.  (Not sure who a good general valgrind contact
> is.)
> * If you ever look at the buildbot and see orange ("unexpected pass"),
> especially in the WebKit LayoutTest bots, ping the WebKit sheriff (the
> calendar is linked from the top
> of http://dev.chromium.org/developers/how-tos/webkit-merge-1 ; I don't know
> whether it's world-readable).  If he wasn't aware of it, agree between you
> on who will deal with it.  Orange alone is not reason to close the tree, but
> it should NOT be ignored.
> * DON'T IGNORE TESTS BECAUSE THEY WENT GREEN ON THE NEXT CYCLE.  If they're
> really fixed by someone's commit, that should be easy to determine.
>  Otherwise, they're flaky, and we NEED to mark them as such, not just leave
> them.
> ***
> Finally, how to help if the LayoutTest bots are red or orange:
> (1) Try and determine if the test(s) are consistently passing/failing
> unexpectedly, or if they're flaky.  Make sure you look at all the different
> bots to see which OSes are affected.
> (2) Update src/webkit/tools/layout_tests/test-expectations.txt.  Look for
> the test(s) in question.  Often, flaky tests will already be in there as
> failing or flaky for one OS, and need to have more added; or they will be
> marked flaky ("FAIL PASS") and need "CRASH" added.  If they're not there,
> add a line.
> (3) Ensure the test(s) have a bug on file.  Note the bug on the expectation.
> (4) If any tests are crashing (flaky or not), they're high-priority and
> someone needs to triage them.  Today, dglazkov was WebKit sheriff and was
> having me mark these bugs as P1, Mstone-3, owner:dglazkov.  I'm not sure
> whether the Right Thing is to assign them to the WebKit sheriff or still to
> him (feel free to comment, dglazkov!).  Why are these P1?  Because until we
> prove they can't affect Chrome itself, they potentially can, and Chrome
> crashes are always P1.  They affect stability and security both.
> (5) If you have commit rights, go ahead and TBR test-expectations changes
> you're confident of.  I even suggest using --force if the tree is closed.
>  Updating expectations is like fixing bustage, it helps the tree go green
> faster and thus is almost always desirable.  If you don't have commit
> rights, send your review to the WebKit sheriff.
> ***
> Your reward for reading this far:
> * At the end of the quarter, I will nominate for a peer bonus every Googler
> who puts something meaningful about flakiness/test failures/the other stuff
> above on their OKRs, accomplishes it, and sends me a note pointing that out.
> * At the end of the quarter, I will nominate for 

[chromium-dev] Re: Git usage in chromium

[Ojan Vafai]

On Thu, Aug 6, 2009 at 12:59 PM, Evan Martin  wrote:

> On Thu, Aug 6, 2009 at 9:55 AM, n179911 wrote:
> > I read this about git usage in chromium:
> >
> > http://code.google.com/p/chromium/wiki/UsingGit
>
> After following the instructions in that document trunk/src is git and
> everything else (pulled in via DEPS, including webkit and also ICU,
> skia, etc.) is via svn.


I've been wondering about this. What would it take to modify our git
checkout process to pull third_party/WebKit via git as well? Would it mostly
work to just exclude third_party/WebKit via DEPS, create it via a git
checkout and then write a script that wraps gclient sync to also git
pull/rebase third_party/WebKit? Is there a better way?

I'd like to have a git checkout of tip of tree trunk/src and tip of tree
WebKit so I can have one tree for developing both Chrome and WebKit.

Ojan

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Jeremy Orlow]

Yoav everyone on this thread is a Chromium developer and almost everyone
posting in this thread (not me) are some of the top developers working on
Chrome and many of them have spent a good deal of time working on sandbox
related issues.
All of us have a healthy disrespect for the "impossible" and would
definitely like to see plugin's sandboxed by default, but it's a very
difficult problem.  We're working hard on many fronts like making more stuff
possible without plugins (HTML 5), new technologies (NaCl), etc to change
the status quo.

I know it doesn't mean much to you, but I've met and/or worked with many of
the developers that reached the conclusion that sandboxing plugins isn't
practical (at least by default) and I can say that they're not only some of
the smartest developers I've ever met, but that the decision was also
painful to them.

If you wanted to help, patches would be great.  But I think it'd also be
helpful if you turned it on and filed bugs when you hit compat issues.

I'm not sure there's much else to say on the topic...

J

On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth  wrote:

>
> I don't really understand why you find Alex's message so frustrating.
> We'd love to make --safe-plugins the default.  One road to getting
> there is having more people use the option and find the
> incompatibilities.  We'd certainly welcome patches that improve it's
> compatibility.  If we can make it work well enough, then we can turn
> it on by default and everyone wins.
>
> Adam
>
>
> On Thu, Aug 6, 2009 at 9:46 AM, yoav
> zilberberg wrote:
> > Alex, let me get it, are you part of the chrome team ? i don't recall
> > accusing anyone from chrome
> > but i do recall not liking your reply, so just let me know if you are
> part
> > of the devs of chrome please
> > i will be honest, if you are, then i think it is time for me to move to a
> > different browser, if you are not
> > then don't decide if i accuse the chrome team or not, let them tell me,
> and
> > like i said
> > i would remove myself in a second and with no hard feelings
> >
>
> >
>

--~--~-~--~~~---~--~~
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: PSA: irc awareness [Was: Trick question: Who is "responsible" for repairing a red tree?]

[Drew Wilson]

One caveat for Colloquy is that the default highlight for "someone sent you
a PM" is "bounce once" rather than "bounce lots of times", so it's really
easy to miss PMs if you don't change the default.
-atw

On Thu, Aug 6, 2009 at 8:57 AM, Pam Greene  wrote:

> For Colloquy, enter your nick in Preferences > Alerts > Highlight words.
> You can also enter other things you might be interested in, such as "red" or
> "sheriff" or "caja".
>
> - Pam
>
> On Wed, Aug 5, 2009 at 7:25 PM, Dirk Pranke  wrote:
>
>>
>> I would love to enable that feature ... anyone know how to do that for
>> Adium on the Mac (IRC support is new in the 1.4 beta)?
>> Failing that, Colloquy?
>>
>> -- Dirk
>>
>> On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruel
>> wrote:
>> > Most irc clients have an option to beep, flash or shutdown your computer
>> > when your nick is mentioned on a channel. It may not be enabled by
>> default
>> > so please enable this. Ask around if you can't find how to enable this.
>> > Thanks,
>> > M-A
>> >
>> > On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel  wrote:
>> >>
>> >> On Wed, Aug 5, 2009 at 2:45 PM, Tim Steele wrote:
>> >> > you have to keep asking, unless you're always on IRC and can cleverly
>> >> > search
>> >> > the window contents.  A constant place to go looking for this would
>> make
>> >> > it
>> >> > easier, at least in my opinion.  Like right now I don't know what's
>> up
>> >> > with
>> >> > Chromium Mac (valgrind)
>> >>
>> >> You need to be on IRC and scroll back:
>> >>
>> >> [13:55] mac valgrind unit -> rohitrao?
>> >> [13:57]  dkegel: very likely
>> >> [13:58] emailed rohit
>> >> [14:02]   dkegel, jar: looking
>> >> [14:30]   jar, dkegel: reverted 22517
>> >>
>> >> I doubt anything more durable than IRC is going to help...
>> >> IRC and the tree status are the place to go, I'm afraid.
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Git usage in chromium

[Evan Martin]

On Thu, Aug 6, 2009 at 9:55 AM, n179911 wrote:
> I read this about git usage in chromium:
>
> http://code.google.com/p/chromium/wiki/UsingGit
>
> It looks like it is using a combination of git and svn for version control.
>
> Can you please tell me what are using git and what are using svn?
> My guess is third-party/webkit will be using svn and everything else is git?
> Is that correct?

After following the instructions in that document trunk/src is git and
everything else (pulled in via DEPS, including webkit and also ICU,
skia, etc.) is via svn.

You are of course welcome to check out yourself (via git-svn) in any
combination you see fit, but it can be fiddly to get right.

--~--~-~--~~~---~--~~
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: Git usage in chromium

[Pam Greene]

On Thu, Aug 6, 2009 at 9:55 AM, n179911  wrote:

>
> Hi,
>
> I read this about git usage in chromium:
>
> http://code.google.com/p/chromium/wiki/UsingGit
>
> It looks like it is using a combination of git and svn for version control.
>
> Can you please tell me what are using git and what are using svn?
> My guess is third-party/webkit will be using svn and everything else is
> git?
> Is that correct?


Both Chromium and WebKit use svn, but you can wrap git on top of that if you
want by following those instructions.

- Pam


>
>
> 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] Git usage in chromium

[n179911]

Hi,

I read this about git usage in chromium:

http://code.google.com/p/chromium/wiki/UsingGit

It looks like it is using a combination of git and svn for version control.

Can you please tell me what are using git and what are using svn?
My guess is third-party/webkit will be using svn and everything else is git?
Is that correct?

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: Urgent, a very evil site i think which does evil things (no joke)

[Adam Barth]

I don't really understand why you find Alex's message so frustrating.
We'd love to make --safe-plugins the default.  One road to getting
there is having more people use the option and find the
incompatibilities.  We'd certainly welcome patches that improve it's
compatibility.  If we can make it work well enough, then we can turn
it on by default and everyone wins.

Adam


On Thu, Aug 6, 2009 at 9:46 AM, yoav
zilberberg wrote:
> Alex, let me get it, are you part of the chrome team ? i don't recall
> accusing anyone from chrome
> but i do recall not liking your reply, so just let me know if you are part
> of the devs of chrome please
> i will be honest, if you are, then i think it is time for me to move to a
> different browser, if you are not
> then don't decide if i accuse the chrome team or not, let them tell me, and
> like i said
> i would remove myself in a second and with no hard feelings
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Evan Martin]

I am not quite sure what just happened there.

On Thu, Aug 6, 2009 at 9:46 AM, yoav
zilberberg wrote:
> Alex, let me get it, are you part of the chrome team ? i don't recall
> accusing anyone from chrome
> but i do recall not liking your reply, so just let me know if you are part
> of the devs of chrome please
> i will be honest, if you are, then i think it is time for me to move to a
> different browser, if you are not
> then don't decide if i accuse the chrome team or not, let them tell me, and
> like i said
> i would remove myself in a second and with no hard feelings
>
> >
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[yoav zilberberg]

Alex, let me get it, are you part of the chrome team ? i don't recall
accusing anyone from chromebut i do recall not liking your reply, so just
let me know if you are part of the devs of chrome please

i will be honest, if you are, then i think it is time for me to move to a
different browser, if you are not
then don't decide if i accuse the chrome team or not, let them tell me, and
like i said
i would remove myself in a second and with no hard feelings

--~--~-~--~~~---~--~~
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: Strange periodic popup window on 3.0.196.0 on Linux?

[Evan Martin]

I haven't.  What sort of window?  (Does it have a title bar?
Toolbar?)  Can you get a screenshot?

On Thu, Aug 6, 2009 at 8:37 AM, Dan Kegel wrote:
>
> Ever since updating to 3.0.196.0, I've seen a
> blank window pop up and go away periodically
> (once an hour or so?).  Anyone else seen that?
>
> >
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Alex Russell]

On Aug 6, 2009, at 1:43 AM, yoav zilberberg wrote:

> No adam, i did not sumbit patches to the sandbox :) i just used its  
> API's to forward calls from kernel32.dll to my own DLL's so i could  
> inject code to VC.exe and force it to run in the idle priority  
> class
>
> but i still don't get it
> if Flash expects to be able to SendMessage, then you cannot sandbox  
> it anyways as there is no limit to what can be done
> and of course, i also look forward to HTML5
>
> All i am saying is that one of the biggest selling points of chrome  
> is that it is secure (no drive by malware anymore)

--disable-plugins or --safe-plugins will get you there. Just don't  
expect full web compatibility. What you're expressing is the very real  
tension between what users currently expect and the security  
implications of how those expectations are realized today. Browser  
vendors are caught in the middle -- this is by way of explanation, not  
excuse. I think everyone working on Chrome wishes Flash were sandbox- 
able and are frustrated with the current situation. If you've got  
ideas for how to make --safe-plugins work better with real-world  
Flash, I suspect those ideas would be well received. Accusing the team  
of gross negligence probably won't help you get patches landed any  
faster, though.

> and i was hoping from such a good produce as chrome to protect me
>
> there is simple statistics to be had here
> do most flash apps expect to the able to SendMessage ? if so, i  
> admit, this is a hopeless case
> but if not, then you should have added an option in chrome to say
> 'sandbox flash by default' and then you could whitelist some sites  
> you trust

I think to Adam's point, we'd like a relatively complete sandbox  
(i.e., one that run in a pre-defined policy and in which one failure  
won't lead to many other kinds of breaks). Take the example of 3D  
hardware access: drivers run in the kernel. Any problem there will  
invalidate whatever work is done at, say, the filesystem level. It's  
likely true that most of the world's Flash doesn't need to do insecure  
things. Figuring out a sane way to either tell Flash "no" in a way  
that doesn't out-and-out crash movies or in some other way give users  
control seems an area that could use more exploration if you've got  
the time.

Regards

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[Pam Greene]

I've been using a local copy with this change (add all files to a new
change, but not to an existing one) forever, but last I checked around, some
people prefer the "always copy-paste" model. I'd be glad to check in my
change if the consensus agrees.

- Pam

On Thu, Aug 6, 2009 at 12:51 AM, Adam Barth  wrote:

>
> Perhaps a better default is to use this behavior when first creating a
> changelist and to use the old behavior when modifying a changelist.
>
> Adam
>
>
> On Thu, Aug 6, 2009 at 12:37 AM, Dirk Pranke wrote:
> >
> > I also fear that I may have unwanted files sneaking in. This was less
> > of an issue with Perforce since you have to manually 'p4 edit' files
> > first anyway.
> >
> > I'll be curious to see if there's a consensus preference one way or
> > another. Maybe we can make this a gclient config setting or something?
> >
> > -- Dirk
> >
> > On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisher wrote:
> >> This seemed really great at first, but after some use, I find it a bit
> >> frustrating since each time I run "gcl change", I now have to be mindful
> >> that gcl may add unwanted files to the CL.  The only way I've found to
> avoid
> >> this is to make sure that unwanted files are part of a dummy CL :-(
> >> -Darin
> >>
> >>
> >>
> >> On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge 
> wrote:
> >>>
> >>> Howdy,
> >>> Quick little change to gcl that everyone should be aware of.  When you
> >>> execute the script it will now automatically pull all physically
> modified
> >>> files into the "Paths in this changelist" section, which means no more
> >>> copying and pasting the files you changed into your CL.  The behavior
> is
> >>> closer to that of P4 (where we delete files as opposed to adding them).
>  All
> >>> the unchanged files are still below.
> >>> Kind Regards,
> >>>
> >>> Anthony Laforge
> >>> Technical Program Manager
> >>> Mountain View, CA
> >>>
> >>>
> >>
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: PSA: irc awareness [Was: Trick question: Who is "responsible" for repairing a red tree?]

[Pam Greene]

For Colloquy, enter your nick in Preferences > Alerts > Highlight words. You
can also enter other things you might be interested in, such as "red" or
"sheriff" or "caja".

- Pam

On Wed, Aug 5, 2009 at 7:25 PM, Dirk Pranke  wrote:

>
> I would love to enable that feature ... anyone know how to do that for
> Adium on the Mac (IRC support is new in the 1.4 beta)?
> Failing that, Colloquy?
>
> -- Dirk
>
> On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruel
> wrote:
> > Most irc clients have an option to beep, flash or shutdown your computer
> > when your nick is mentioned on a channel. It may not be enabled by
> default
> > so please enable this. Ask around if you can't find how to enable this.
> > Thanks,
> > M-A
> >
> > On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel  wrote:
> >>
> >> On Wed, Aug 5, 2009 at 2:45 PM, Tim Steele wrote:
> >> > you have to keep asking, unless you're always on IRC and can cleverly
> >> > search
> >> > the window contents.  A constant place to go looking for this would
> make
> >> > it
> >> > easier, at least in my opinion.  Like right now I don't know what's up
> >> > with
> >> > Chromium Mac (valgrind)
> >>
> >> You need to be on IRC and scroll back:
> >>
> >> [13:55] mac valgrind unit -> rohitrao?
> >> [13:57]  dkegel: very likely
> >> [13:58] emailed rohit
> >> [14:02]   dkegel, jar: looking
> >> [14:30]   jar, dkegel: reverted 22517
> >>
> >> I doubt anything more durable than IRC is going to help...
> >> IRC and the tree status are the place to go, I'm afraid.
> >>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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-team] Beware of any issues linking to trucountme.com

[progame]

the new spam is by a user called lewiskevin64
http://code.google.com/u/lewiskevin64/updates

spamming the url "giga-tube.net"  which i am guessing is also devious

On Aug 6, 7:40 am, Mohamed Mansour  wrote:
> I was going to delete them when I saw them, but committers have no access to
> delete posts :)  If only the issue tracker was open source, we could have
> helped them implement it !
> -- Mohamed Mansour
>
>
>
> On Thu, Aug 6, 2009 at 12:19 AM, Ian Fette  wrote:
> > Sadly there's about 60 of these, still cleaning them up. AFAIK there's no
> > way for me to ban the user :(
> > (Also, queuing up 60 tabs reminds me that I would really love a tab
> > overflow solution :)
>
> > 2009/8/5 Anthony LaForge 
>
> > A friendly person appears to be spamming our issue tracker w/ a virus link.
> >> Kind Regards,
>
> >> Anthony Laforge
> >> Technical Program Manager
> >> Mountain View, CA
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Strange periodic popup window on 3.0.196.0 on Linux?

[Dan Kegel]

Ever since updating to 3.0.196.0, I've seen a
blank window pop up and go away periodically
(once an hour or so?).  Anyone else seen that?

--~--~-~--~~~---~--~~
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: PSA: irc awareness [Was: Trick question: Who is "responsible" for repairing a red tree?]

[Robert Sesek]

Dirk,

Adium should automatically do it for your full IRC nick. You can also
go into Adium --> Preferences --> Advanced --> Mention to have it
watch for other things. Also, you can go into the Events preference
and change the "You are mentioned (Group Chat)" notification options.

- Robert

On Aug 5, 10:25 pm, Dirk Pranke  wrote:
> I would love to enable that feature ... anyone know how to do that for
> Adium on the Mac (IRC support is new in the 1.4 beta)?
> Failing that, Colloquy?
>
> -- Dirk
>
>
>
> On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruel wrote:
> > Most irc clients have an option to beep, flash or shutdown your computer
> > when your nick is mentioned on a channel. It may not be enabled by default
> > so please enable this. Ask around if you can't find how to enable this.
> > Thanks,
> > M-A
>
> > On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel  wrote:
>
> >> On Wed, Aug 5, 2009 at 2:45 PM, Tim Steele wrote:
> >> > you have to keep asking, unless you're always on IRC and can cleverly
> >> > search
> >> > the window contents.  A constant place to go looking for this would make
> >> > it
> >> > easier, at least in my opinion.  Like right now I don't know what's up
> >> > with
> >> > Chromium Mac (valgrind)
>
> >> You need to be on IRC and scroll back:
>
> >> [13:55]         mac valgrind unit -> rohitrao?
> >> [13:57]      dkegel: very likely
> >> [13:58]         emailed rohit
> >> [14:02]       dkegel, jar: looking
> >> [14:30]       jar, dkegel: reverted 22517
>
> >> I doubt anything more durable than IRC is going to help...
> >> IRC and the tree status are the place to go, I'm afraid.
--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[Anthony LaForge]

I've reverted the change, gcl will go back to normal in about 5-10 minutes.

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA


On Thu, Aug 6, 2009 at 8:13 AM, John Abd-El-Malek  wrote:

> whoa, please revert this change.  if I have a big changelist, now every
> time I run gcl I have to expend effort to make sure no new files crept in.
>  this will lead to more build failures as people check in other files
> accidently.
>
> On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge wrote:
>
>>  Howdy,
>> Quick little change to gcl that everyone should be aware of.  When you
>> execute the script it will now automatically pull all physically modified
>> files into the "Paths in this changelist" section, which means no more
>> copying and pasting the files you changed into your CL.  The behavior is
>> closer to that of P4 (where we delete files as opposed to adding them).  All
>> the unchanged files are still below.
>>
>> Kind Regards,
>>
>> Anthony Laforge
>> Technical Program Manager
>> Mountain View, CA
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[John Abd-El-Malek]

whoa, please revert this change.  if I have a big changelist, now every time
I run gcl I have to expend effort to make sure no new files crept in.  this
will lead to more build failures as people check in other files accidently.

On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge  wrote:

> Howdy,
> Quick little change to gcl that everyone should be aware of.  When you
> execute the script it will now automatically pull all physically modified
> files into the "Paths in this changelist" section, which means no more
> copying and pasting the files you changed into your CL.  The behavior is
> closer to that of P4 (where we delete files as opposed to adding them).  All
> the unchanged files are still below.
>
> Kind Regards,
>
> Anthony Laforge
> Technical Program Manager
> Mountain View, CA
>
> >
>

--~--~-~--~~~---~--~~
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: Flakiness. Please help.

[Dan Kegel]

On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting wrote:
> * Yes, even purify, valgrind, and reliability bot redness.  If you can't
> figure out what to do with these, try pinging erikkay for purify issues and
> huanr for reliability issues.  (Not sure who a good general valgrind contact
> is.)

I'm willing to be a valgrind contact.
- Dan

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[Thomas Van Lenten]

On Thu, Aug 6, 2009 at 3:51 AM, Adam Barth  wrote:

>
> Perhaps a better default is to use this behavior when first creating a
> changelist and to use the old behavior when modifying a changelist.


+1

TVL


>
>
> Adam
>
>
> On Thu, Aug 6, 2009 at 12:37 AM, Dirk Pranke wrote:
> >
> > I also fear that I may have unwanted files sneaking in. This was less
> > of an issue with Perforce since you have to manually 'p4 edit' files
> > first anyway.
> >
> > I'll be curious to see if there's a consensus preference one way or
> > another. Maybe we can make this a gclient config setting or something?
> >
> > -- Dirk
> >
> > On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisher wrote:
> >> This seemed really great at first, but after some use, I find it a bit
> >> frustrating since each time I run "gcl change", I now have to be mindful
> >> that gcl may add unwanted files to the CL.  The only way I've found to
> avoid
> >> this is to make sure that unwanted files are part of a dummy CL :-(
> >> -Darin
> >>
> >>
> >>
> >> On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge 
> wrote:
> >>>
> >>> Howdy,
> >>> Quick little change to gcl that everyone should be aware of.  When you
> >>> execute the script it will now automatically pull all physically
> modified
> >>> files into the "Paths in this changelist" section, which means no more
> >>> copying and pasting the files you changed into your CL.  The behavior
> is
> >>> closer to that of P4 (where we delete files as opposed to adding them).
>  All
> >>> the unchanged files are still below.
> >>> Kind Regards,
> >>>
> >>> Anthony Laforge
> >>> Technical Program Manager
> >>> Mountain View, CA
> >>>
> >>>
> >>
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Need some help with Grit

[Wa]

Well the grd file hasn't been changed, I'm using the 196 one (tried
197 as well).
I figured that might be intended, but using reshacker I can see that
IDR_FRAME is 10583 (by identifying the image I mean).
This is also the case in the .rc file made manually for Chromium Theme
Creator by U_I. (Which I'm trying to automate).

Thanks for the info though. I'll see what I can sort out.

On Aug 6, 1:42 am, Jói  wrote:
> Hi Wa,
>
> GRIT generates ID numbers for all constants regardless of 
> elements or not, but skips output to the RC file for items that are in
>  elements that evaluate to false.  This is done so that two
> different builds with different preprocessor defines (that cause
> different  sections to be included or not) get the same IDs for
> the same resources.
>
> > This doesn't seem to be the same as when you guys build the .rc file
> > though, as the correct ID for IDR_FRAME is 10583.
>
> Why do you think this is the correct ID for IDR_FRAME?  GRIT generates
> IDs every time it is run, and they are internally consistent but may
> change between invocations if the .grd file has been changed.
>
> Cheers,
> Jói
>
> On Aug 6, 2:34 am, Wa  wrote:
>
>
>
> > I'm trying to use Grit to compile the theme resource headers for
> > reference. But when I do so, it seems to be counting the s
> > under  though it's not exporting them to the
> > header. For example from compile app_resources.grd:
> > #define IDR_MINIMIZE_H 10581
> > #define IDR_MINIMIZE_P 10582
> > #define IDR_FRAME 10595
> > #define IDR_FRAME_INACTIVE 10596
>
> > That's the output, which as you can see, the increment breaks between
> > IDR_MINIMIZE_P and IDR_FRAME. Checking the -x verbose output, it is in
> > fact enumerating the inputs under the linux check there, incrementing
> > the ID value.
> > This doesn't seem to be the same as when you guys build the .rc file
> > though, as the correct ID for IDR_FRAME is 10583.
> > Is there a command line argument to Grit to step over ifs that
> > evaluate false that I'm missing here? I looked over the source for
> > Grit and your build files as best I could without knowing Python and
> > having never used VC++, but can't find anything related.
>
> > If nothing else I guess I can just parse them out entirely in my
> > bat..though I really would rather not.
--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[yoav zilberberg]

No adam, i did not sumbit patches to the sandbox :) i just used its API's to
forward calls from kernel32.dll to my own DLL's so i could inject code to
VC.exe and force it to run in the idle priority class
but i still don't get it
if Flash expects to be able to SendMessage, then you cannot sandbox it
anyways as there is no limit to what can be done
and of course, i also look forward to HTML5

All i am saying is that one of the biggest selling points of chrome is that
it is secure (no drive by malware anymore)
and i was hoping from such a good produce as chrome to protect me

there is simple statistics to be had here
do most flash apps expect to the able to SendMessage ? if so, i admit, this
is a hopeless case
but if not, then you should have added an option in chrome to say
'sandbox flash by default' and then you could whitelist some sites you trust

--~--~-~--~~~---~--~~
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: Need some help with Grit

[Jói]

Hi Wa,

GRIT generates ID numbers for all constants regardless of 
elements or not, but skips output to the RC file for items that are in
 elements that evaluate to false.  This is done so that two
different builds with different preprocessor defines (that cause
different  sections to be included or not) get the same IDs for
the same resources.

> This doesn't seem to be the same as when you guys build the .rc file
> though, as the correct ID for IDR_FRAME is 10583.

Why do you think this is the correct ID for IDR_FRAME?  GRIT generates
IDs every time it is run, and they are internally consistent but may
change between invocations if the .grd file has been changed.

Cheers,
Jói


On Aug 6, 2:34 am, Wa  wrote:
> I'm trying to use Grit to compile the theme resource headers for
> reference. But when I do so, it seems to be counting the s
> under  though it's not exporting them to the
> header. For example from compile app_resources.grd:
> #define IDR_MINIMIZE_H 10581
> #define IDR_MINIMIZE_P 10582
> #define IDR_FRAME 10595
> #define IDR_FRAME_INACTIVE 10596
>
> That's the output, which as you can see, the increment breaks between
> IDR_MINIMIZE_P and IDR_FRAME. Checking the -x verbose output, it is in
> fact enumerating the inputs under the linux check there, incrementing
> the ID value.
> This doesn't seem to be the same as when you guys build the .rc file
> though, as the correct ID for IDR_FRAME is 10583.
> Is there a command line argument to Grit to step over ifs that
> evaluate false that I'm missing here? I looked over the source for
> Grit and your build files as best I could without knowing Python and
> having never used VC++, but can't find anything related.
>
> If nothing else I guess I can just parse them out entirely in my
> bat..though I really would rather not.
--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Adam Barth]

I'm glad to hear you've been submitting patches to the sandbox.  The
tricky part about sandboxing code is you have to think of all the
malicious things the code could do to get out of the sandbox.  Even if
we could reliably stop Flash from forking WinMail.exe, what's to stop
Flash from sending the proper sequence of Win32 messages to open a
command prompt and type WinMail.exe into the console?

I think what Carlos is saying is that if you open up enough holes in
the sandbox to have Flash function properly, then you've made it easy
for an attacker to escape.

As for watching YouTube securely, I have high hopes that HTML5's
 tag will help you.  :)

Adam


On Thu, Aug 6, 2009 at 1:25 AM, yoav
zilberberg wrote:
> Ian, well, i like your reply, so just tell me please for my own knowledge
> one thing
> is there ever a reason to allow flash (we are talking only flash here) to
> fork WinMail.exe for example ?
> i am a very light weight surfer, and i mostly read tech stuff, so my
> experience with flash is mostly youtube
> is this really something which any flash application does ?
> does flash really expect to have access to 'program files' ?
> if flash is expected to have access to it all, then you wouldn't have tried
> to sandbox it in the first place, right ?
> and btw, i read really a lot of the source code of chrome, and i still do, i
> even used your sandbox API
> to various tricks, and i even submitted patches and expect to do more in the
> future
> >
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[yoav zilberberg]

Ian, well, i like your reply, so just tell me please for my own knowledge
one thing
is there ever a reason to allow flash (we are talking only flash here) to
fork WinMail.exe for example ?

i am a very light weight surfer, and i mostly read tech stuff, so my
experience with flash is mostly youtube

is this really something which any flash application does ?

does flash really expect to have access to 'program files' ?

if flash is expected to have access to it all, then you wouldn't have tried
to sandbox it in the first place, right ?
and btw, i read really a lot of the source code of chrome, and i still do, i
even used your sandbox API
to various tricks, and i even submitted patches and expect to do more in the
future

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Ian Fette]

Actually, I thought the answer was quite reasoned. I probably would have
just said "read the archive, or any of the blog posts we've done on
sandboxing, or the papers written on the subject."
It's not "trust the force," it's "we tried this already and had a ton of
problems, here's a sampling, and if you really care you can look around for
more information, but in short there's little we can do without support from
the plugin vendors." Carlos is the expert on the sandbox, and has tried to
sandbox flash in the past (and believe me, he would really love to be able
to do so).

Intercepting filesystem access could have stopped this attack, but it also
could break flash. Plugins (take Air, for example, which provides filesystem
access)
have expectations, including filesystem access, and when you break those
expectations things go south rapidly. If plugins weren't supposed to have
any filesystem access, or any access beyond what a renderer has, then sure
we could sandbox them and things would be dandy. But it just doesn't work
that way, and so we are trying to do what we can, including working with the
plugin vendors, to make this happen -- it's just not as simple as you seem
to portray it as.

2009/8/6 yoav zilberberg 

> Alex, your reply irritates me so much that i am willing to take my chancesand
> if anyone (from @chromium) finds my answer insulting e-mail me and i will
> remove myself
> forever from your lists, promise!
>
> what kind of an answer is that ?
> do you know how this attack was carried ?
> did you even read this thread before suggesting your comments ?
>
> even the start of your thread "trust the force" is so arrogant, and while i
> don't know who carlos is
> i would think that even carlos would know that if you intercepted file
> access you would have
> easily stopped this attack.
>
> jeremy was at least constructive, in suggesting i would patch it myself,
> but like i said, i don't know NPAPI
> nor do i know flash for that matter
>
> but i do know windows, alex, and whatever flash does internally he cannot
> access the disk directly, right ? (of course not)
> so just that simple test would have been enough
>
> and again, if anyone(!) from chrome(!) finds my response offensive, reply
> here and i promise never to post here again
> with zero hard feelings
>
> nakro
>
> >
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[yoav zilberberg]

Alex, your reply irritates me so much that i am willing to take my chancesand
if anyone (from @chromium) finds my answer insulting e-mail me and i will
remove myself
forever from your lists, promise!

what kind of an answer is that ?
do you know how this attack was carried ?
did you even read this thread before suggesting your comments ?

even the start of your thread "trust the force" is so arrogant, and while i
don't know who carlos is
i would think that even carlos would know that if you intercepted file
access you would have
easily stopped this attack.

jeremy was at least constructive, in suggesting i would patch it myself, but
like i said, i don't know NPAPI
nor do i know flash for that matter

but i do know windows, alex, and whatever flash does internally he cannot
access the disk directly, right ? (of course not)
so just that simple test would have been enough

and again, if anyone(!) from chrome(!) finds my response offensive, reply
here and i promise never to post here again
with zero hard feelings

nakro

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[Adam Barth]

Perhaps a better default is to use this behavior when first creating a
changelist and to use the old behavior when modifying a changelist.

Adam


On Thu, Aug 6, 2009 at 12:37 AM, Dirk Pranke wrote:
>
> I also fear that I may have unwanted files sneaking in. This was less
> of an issue with Perforce since you have to manually 'p4 edit' files
> first anyway.
>
> I'll be curious to see if there's a consensus preference one way or
> another. Maybe we can make this a gclient config setting or something?
>
> -- Dirk
>
> On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisher wrote:
>> This seemed really great at first, but after some use, I find it a bit
>> frustrating since each time I run "gcl change", I now have to be mindful
>> that gcl may add unwanted files to the CL.  The only way I've found to avoid
>> this is to make sure that unwanted files are part of a dummy CL :-(
>> -Darin
>>
>>
>>
>> On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge  wrote:
>>>
>>> Howdy,
>>> Quick little change to gcl that everyone should be aware of.  When you
>>> execute the script it will now automatically pull all physically modified
>>> files into the "Paths in this changelist" section, which means no more
>>> copying and pasting the files you changed into your CL.  The behavior is
>>> closer to that of P4 (where we delete files as opposed to adding them).  All
>>> the unchanged files are still below.
>>> Kind Regards,
>>>
>>> Anthony Laforge
>>> Technical Program Manager
>>> Mountain View, CA
>>>
>>>
>>
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[Jeremy Orlow]

Another vote against this change for similar reasons...

On Thu, Aug 6, 2009 at 12:37 AM, Dirk Pranke  wrote:

>
> I also fear that I may have unwanted files sneaking in. This was less
> of an issue with Perforce since you have to manually 'p4 edit' files
> first anyway.
>
> I'll be curious to see if there's a consensus preference one way or
> another. Maybe we can make this a gclient config setting or something?
>
> -- Dirk
>
> On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisher wrote:
> > This seemed really great at first, but after some use, I find it a bit
> > frustrating since each time I run "gcl change", I now have to be mindful
> > that gcl may add unwanted files to the CL.  The only way I've found to
> avoid
> > this is to make sure that unwanted files are part of a dummy CL :-(
> > -Darin
> >
> >
> >
> > On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge 
> wrote:
> >>
> >> Howdy,
> >> Quick little change to gcl that everyone should be aware of.  When you
> >> execute the script it will now automatically pull all physically
> modified
> >> files into the "Paths in this changelist" section, which means no more
> >> copying and pasting the files you changed into your CL.  The behavior is
> >> closer to that of P4 (where we delete files as opposed to adding them).
>  All
> >> the unchanged files are still below.
> >> Kind Regards,
> >>
> >> Anthony Laforge
> >> Technical Program Manager
> >> Mountain View, CA
> >>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[Dirk Pranke]

I also fear that I may have unwanted files sneaking in. This was less
of an issue with Perforce since you have to manually 'p4 edit' files
first anyway.

I'll be curious to see if there's a consensus preference one way or
another. Maybe we can make this a gclient config setting or something?

-- Dirk

On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisher wrote:
> This seemed really great at first, but after some use, I find it a bit
> frustrating since each time I run "gcl change", I now have to be mindful
> that gcl may add unwanted files to the CL.  The only way I've found to avoid
> this is to make sure that unwanted files are part of a dummy CL :-(
> -Darin
>
>
>
> On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge  wrote:
>>
>> Howdy,
>> Quick little change to gcl that everyone should be aware of.  When you
>> execute the script it will now automatically pull all physically modified
>> files into the "Paths in this changelist" section, which means no more
>> copying and pasting the files you changed into your CL.  The behavior is
>> closer to that of P4 (where we delete files as opposed to adding them).  All
>> the unchanged files are still below.
>> Kind Regards,
>>
>> Anthony Laforge
>> Technical Program Manager
>> Mountain View, CA
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[Darin Fisher]

This seemed really great at first, but after some use, I find it a bit
frustrating since each time I run "gcl change", I now have to be mindful
that gcl may add unwanted files to the CL.  The only way I've found to avoid
this is to make sure that unwanted files are part of a dummy CL :-(
-Darin



On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge  wrote:

> Howdy,
> Quick little change to gcl that everyone should be aware of.  When you
> execute the script it will now automatically pull all physically modified
> files into the "Paths in this changelist" section, which means no more
> copying and pasting the files you changed into your CL.  The behavior is
> closer to that of P4 (where we delete files as opposed to adding them).  All
> the unchanged files are still below.
>
> Kind Regards,
>
> Anthony Laforge
> Technical Program Manager
> Mountain View, CA
>
> >
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Alex Russell]

On Aug 5, 2009, at 11:52 PM, yoav zilberberg wrote:

> Jeremy, i can't see how it will make things any worse to punch these  
> holes
>
> you still fork flash in its own process like you do now
> only you sandbox it how is it any worse ?

Please trust authoritative folks like Carlos when they tell you that  
if sandboxing Flash were something that could be done reliably, even  
with high effort, it would have been done by the Chrome team already.  
Features of Flash like direct network access through their own stack,  
direct access to GPU resources, access to the file system, and audio/ 
video input are incredibly hard to sort out from "regular" Flash  
usage. At a minimum, they'll require code changes to Flash to help  
browsers mediate the access to those resources in a sandboxed  
environment. The current NPAPI interface doesn't have those contracts  
in place, and so the assumptions have been fixed and code written  
right up to the limit of those assumptions. To see how it works for  
yourself, try the --safe-plugins flag and then see how well the Flash- 
using web at large works (and if/how things break).

It's all tractable in time, and you're right that it's absolutely  
desirable to sandbox Flash, but doing it today will undoubtedly lead  
to a poor user experience.

If you'd like this situation to improve, might I suggest you help out  
by striking up a conversation with Adobe on the topic? In my personal  
interactions with their folks, they've been cordial and reasonable,  
and I'm sure they'd like to hear from a customer who's interested in  
seeing a safer Flash.

Regards

> this is just an observation that if i would write malware (which of  
> course, i would never)
> i would just use flash plugins exploits to be cross browser compatible
> and this renders the sandbox nearly useless for future attacks
>
> what "decent" malware writer would bother with webkit explits ? none!
>
> besides, if you look at the help forum of chrome, you will see some  
> people are starting to catch malware like this
> which is btw, how i got this evil site's URL i would never click  
> on my own such a foul looking site
>
> as for the auto updating issue, i suggested a solution in one of my  
> prev posts
> and i am sure you can have a word with adobe for this
>
> in a sense chrome makes it easier to infect itself(!) as you run  
> plugins in the medium integrity level (Vista and above)
> and you normally install chrome in the local user account, so no UAC  
> prompt will help the user
> if some delicate file or DLL is written to chrome folder, and then  
> it will do something never intended
>
> also, one more note, flash is special enough that if you would "hard  
> code" the solution to it, you would anyays
> solve most infections problems in the world, and maybe even  
> cancer... who knows ?
>
> and regarding what CPU said (and ignoring the auto-update) it seems  
> that flash does work flawlessly
> using your '--safe-plugins' switch, and doing this on that site does  
> stop the attack
> (tbh, maybe the attack was stopped because the sun's java died in  
> the sandbox, but Ian said it was a flash based
> attack)
>
> >


--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Jeremy Orlow]

On Wed, Aug 5, 2009 at 11:52 PM, yoav zilberberg
wrote:

> Jeremy, i can't see how it will make things any worse to punch these holes
>

I never said it's worse...just that you couldn't make it airtight.

Patches welcome.  :-)


> you still fork flash in its own process like you do now
> only you sandbox it how is it any worse ?
>
> this is just an observation that if i would write malware (which of course,
> i would never)
> i would just use flash plugins exploits to be cross browser compatible
> and this renders the sandbox nearly useless for future attacks
>
> what "decent" malware writer would bother with webkit explits ? none!
>
> besides, if you look at the help forum of chrome, you will see some people
> are starting to catch malware like this
> which is btw, how i got this evil site's URL i would never click on my
> own such a foul looking site
>
> as for the auto updating issue, i suggested a solution in one of my prev
> posts
> and i am sure you can have a word with adobe for this
>
> in a sense chrome makes it easier to infect itself(!) as you run plugins in
> the medium integrity level (Vista and above)
> and you normally install chrome in the local user account, so no UAC prompt
> will help the user
> if some delicate file or DLL is written to chrome folder, and then it will
> do something never intended
>
> also, one more note, flash is special enough that if you would "hard code"
> the solution to it, you would anyays
> solve most infections problems in the world, and maybe even cancer... who
> knows ?
>
> and regarding what CPU said (and ignoring the auto-update) it seems that
> flash does work flawlessly
> using your '--safe-plugins' switch, and doing this on that site does stop
> the attack
> (tbh, maybe the attack was stopped because the sun's java died in the
> sandbox, but Ian said it was a flash based
> attack)
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---