[chromium-dev] Re: Linux status

[Erik Kay]

One other thought for those of you looking for areas to contribute on
the Linux side of things is to start working on the chrome unit_tests
project.  There are a number of tests in this project that don't
depend explicitly on WebKit.  I'd guess that a bunch of chrome/common,
browser/history, browser/safe_browsing, browser/net, etc. are all
doable.  You'll need to do some hacking to the SConscript file to make
sure it doesn't try to use anything from WebKit or other projects that
haven't been ported, but that should be straightforward.

As with all of these things, be sure to file bugs about the areas that
you're working on so that it's easier for people to avoid conflicts.

Erik

On Thu, Sep 11, 2008 at 3:15 PM, Evan Martin <[EMAIL PROTECTED]> wrote:
>
> [Back before we were public I used to send out semiregular status
> reports, but Darin pointed out I can now send them here.]
>
> http://code.google.com/p/chromium/issues/list?q=os:linux is hopefully
> up to date with what everyone's working on.  Please feel free to bring
> other Linux-specific bugs to my attention.
> We've had a bunch of contributions from people outside Google, which
> is pretty rad.
>
> I believe we [people working on Linux] are currently kind of
> bottlenecked on the WebKit merge: there's little point in making our
> local copy of WebKit code portable when those changes have been made
> upstream already.  The merge is especially gnarly this time because
> we've been tracking the stable Safari 3.1 branch of WebKit the past
> few months and now we're trying to switch to trunk, and simultaneously
> we've been trying to push upstream as much of our forked code as
> reasonable.
>
> To that end, Tony has been helping with the merge; last I heard
> they've finally got all the compiler warnings fixed and are just down
> to 4,200 linker errors.  ;)  If you want to help out with that, try
> asking on the (temporary) channel #chromium-merge on freenode.
>
> Unfortunately, testing changes done for the merge currently requires
> Windows, so maybe it'll be hard to help if all you have is Linux.  On
> the other hand, hopefully this will be done soon, and once the port is
> a bit more flushed out future merges can be done on your platform of
> choice.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Memory leaks in disk_cache (or tests)

[Erik Kay]

Was this leak ever confirmed?  If it's real (and cross-platform), then
Purify failed to catch it and I'd like to report it upstream (I've
seen plenty of false positives, but no false negatives).

Erik


On Thu, Sep 18, 2008 at 6:11 AM, deanm <[EMAIL PROTECTED]> wrote:
>
> Valgrind never lies
>
> ==13767== 32,768 bytes in 2 blocks are definitely lost in loss record
> 5 of 6
> ==13767==at 0x4C9900F: operator new[](unsigned)
> (vg_replace_malloc.c:268)
> ==13767==by 0x81031D9: disk_cache::EntryImpl::PrepareTarget(int,
> int, int, b
> ool) (entry_impl.cc:607)
> ==13767==by 0x8103876: disk_cache::EntryImpl::WriteData(int, int,
> char const
> *, int, CallbackRunner >*, bool) (entry_impl.cc:302)
> ==13767==by 0x80B497B: DiskCacheEntryTest::GrowData()
> (entry_unittest.cc:431
> )
> ==13767==by 0x80B6EF1:
> DiskCacheEntryTest_GrowData_Test::TestBody() (entry_u
> nittest.cc:475)
> ==13767==by 0x8197403: testing::Test::Run() (gtest.cc:1834)
> ==13767==by 0x819AF12: testing::internal::TestInfoImpl::Run()
> (gtest.cc:1999
> )
> ==13767==by 0x819F5B6:
> testing::internal::TestInfoImpl::RunTest(testing::Tes
> tInfo*) (gtest-internal-inl.h:574)
> ==13767==by 0x819B716: void
> testing::internal::List::ForEach (testing::TestInfo*)>(void (*)(testing::TestInfo*)) const (gtest-
> internal-inl.h:335)
> ==13767==by 0x819AE0C: testing::TestCase::Run() (gtest.cc:2094)
> ==13767==by 0x819F59A:
> testing::TestCase::RunTestCase(testing::TestCase*) (gtest-internal-
> inl.h:687)
> ==13767==by 0x819B582: void
> testing::internal::List::ForEach (testing::TestCase*)>(void (*)(testing::TestCase*)) const (gtest-
> internal-inl.h:335)
> ==13767==
> ==13767==
>
>
>
> ==13767== 278,528 bytes in 17 blocks are definitely lost in loss
> record 6 of 6
> ==13767==at 0x4C9900F: operator new[](unsigned)
> (vg_replace_malloc.c:268)
> ==13767==by 0x8101B84:
> disk_cache::EntryImpl::MoveToLocalBuffer(int) (entry_impl.cc:671)
> ==13767==by 0x8102DFB: disk_cache::EntryImpl::GrowUserBuffer(int,
> int, int, bool) (entry_impl.cc:630)
> ==13767==by 0x8103191: disk_cache::EntryImpl::PrepareTarget(int,
> int, int, bool) (entry_impl.cc:602)
> ==13767==by 0x8103876: disk_cache::EntryImpl::WriteData(int, int,
> char const*, int, CallbackRunner >*, bool) (entry_impl.cc:
> 302)
> ==13767==by 0x80B68EE: DiskCacheEntryTest::GrowData()
> (entry_unittest.cc:465)
> ==13767==by 0x80B6EF1:
> DiskCacheEntryTest_GrowData_Test::TestBody() (entry_unittest.cc:475)
> ==13767==by 0x8197403: testing::Test::Run() (gtest.cc:1834)
> ==13767==by 0x819AF12: testing::internal::TestInfoImpl::Run()
> (gtest.cc:1999)
> ==13767==by 0x819F5B6:
> testing::internal::TestInfoImpl::RunTest(testing::TestInfo*) (gtest-
> internal-inl.h:574)
> ==13767==by 0x819B716: void
> testing::internal::List::ForEach (testing::TestInfo*)>(void (*)(testing::TestInfo*)) const (gtest-
> internal-inl.h:335)
> ==13767==by 0x819AE0C: testing::TestCase::Run() (gtest.cc:2094)
> ==13767==
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: File Association - I want to fix it

[Erik Kay]

Thanks for the report.  Could you please file this in the issue tracker?

Erik


On Thu, Sep 25, 2008 at 12:12 PM, HLS <[EMAIL PROTECTED]> wrote:
>
> Folks,
>
> Chrome does not properly launch registered extensions on the PC.
>
> It wouldn;'t be an issue if the "Always Open Files of this type" would
> work, but it seems this option is useless. Maybe its not implemented.
>
> If someone would so kind to assist and point me in the right direction
> for the source code that handle this, I would like to take a stab in
> correcting it and I promise I won't bother you with this.
>
> Background:
>
> We have a popular 12 year old GUI frontend that many of our customer
> use.   It can run on its own, but it has a feature where it will use
> the browser to launch its GUI clients.  For example, the user can go
> to a web site and see a login optons:
>
>   Login and use HTML clients
>   Login and use GUI frrontend clients.
>
> If the 2nd option is used, then our "clients" which have WCN url
> extension are special triggers to start GUI clients on the user's PC.
>
> This File Extension Association recording works fine with all browsers
> - except Chrome.
>
> I need to get that fixed.
>
> --
> HLS
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: [V8-dev] Re: purify builders won't link

[Erik Kay]

It looks like a clobber build of unit tests didn't fix the problem.
I'm trying a clobber build of test_shell right now.

Erik


On Wed, Nov 26, 2008 at 12:36 AM, Darin Fisher <[EMAIL PROTECTED]> wrote:
> Yeah, the error is very similar to the one in that bug.  Here's the error
> that we are seeing on the bots:
> 124>javascriptcore_pcre.lib(pcre_xclass.obj) : error LNK2005: "bool __cdecl
> kjs_pcre_xclass(int,unsigned char const *)" (?kjs_pcre_xclass@@[EMAIL 
> PROTECTED])
> already defined in v8_snapshot.lib(pcre_xclass.obj)
> -Darin
>
> 2008/11/26 Søren Gjesse <[EMAIL PROTECTED]>
>>
>> Could this be something like http://b/issue?id=1320493?
>> I ran into this exact issue a couple of weeks back. When I did a rebuild
>> test_shell (or Chrome) it linked fine, and it also linked after the first
>> changes and rebuilds, but after a few rebuilds the error in bug report
>> started re-appearing. Deleting src/chrome/Debug did not fix it. The only fix
>> I could find was to change the dependency of test_shell (and chrome_dll) on
>> v8_snapshot to v8.
>> I have since created a new workspace and have never seen the problem in
>> that workspace. I still have the broken workspace on my disk.
>> /Søren
>>
>> On Wed, Nov 26, 2008 at 4:09 AM, Erik Kay <[EMAIL PROTECTED]> wrote:
>>>
>>> I can help you take a look at this tomorrow morning.  Can you point me
>>> at the patch to use?
>>>
>>> Erik
>>>
>>>
>>> On Tue, Nov 25, 2008 at 6:34 PM, Ojan Vafai <[EMAIL PROTECTED]> wrote:
>>> > Purify builders are having link errors as of the most recent webkit
>>> > merge.
>>> > Something about javascriptcore_pcre. I'm not sure if it's the merge or
>>> > if
>>> > it's just that the merge cause more projects to need recompiling. Seems
>>> > totally unrelated to any code touched by the merge.
>>> > In either case, Darin and I agreed that it's better to not roll back
>>> > the
>>> > merge.
>>> > I can look into this tomorrow morning. If any other kind soul feels
>>> > moved,
>>> > they are more than welcome to. I wasn't able to reproduce the link
>>> > error
>>> > using incredibuild. Will try with VS build tomorrow.
>>> > Ojan
>>> >
>>> >
>>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: [V8-dev] Re: [chromium-dev] Re: [V8-dev] Re: purify builders won't link

[Erik Kay]

I filed http://code.google.com/p/chromium/issues/detail?id=4828 to
track this issue.

A temporary workaround is that if you build with IncrediBuild, it
seems to not hit the error.

Erik


On Wed, Nov 26, 2008 at 1:08 PM, David Levin <[EMAIL PROTECTED]> wrote:
> I'm hitting this error right now in a normal vs build for chrome.sln on my
> machine.
>
> I did a gclient sync (this morning).
> Then a clean build.
> Then the full build.
>
> Both test_shell and test_shell_test fail to build due to it.
> I thought it was something wrong with my machine until I saw this.
> Dave
>
> On Wed, Nov 26, 2008 at 9:06 AM, Ojan Vafai <[EMAIL PROTECTED]> wrote:
>>
>> Resending from the right address...
>> Started failing with this
>> CL http://build.chromium.org/buildbot/waterfall/changes/2762, which updated
>> deps to bring in the new merge.
>> I was able to build a local purify build last night using incredibuild.
>> Maybe something is wrong with the builder? Could it be a dependency issue
>> that just affects VS purify build?
>> Ojan
>> On Wed, Nov 26, 2008 at 8:52 AM, Ojan Vafai <[EMAIL PROTECTED]> wrote:
>>>
>>> Started failing with this
>>> CL http://build.chromium.org/buildbot/waterfall/changes/2762, which updated
>>> deps to bring in the new merge.
>>> I was able to build a local purify build last night using incredibuild.
>>> Maybe something is wrong with the builder? Could it be a dependency issue
>>> that just affects VS purify build?
>>> Ojan
>>>
>>> On Wed, Nov 26, 2008 at 8:24 AM, Erik Kay <[EMAIL PROTECTED]> wrote:
>>>>
>>>> It looks like a clobber build of unit tests didn't fix the problem.
>>>> I'm trying a clobber build of test_shell right now.
>>>>
>>>> Erik
>>>>
>>>>
>>>> On Wed, Nov 26, 2008 at 12:36 AM, Darin Fisher <[EMAIL PROTECTED]>
>>>> wrote:
>>>> > Yeah, the error is very similar to the one in that bug.  Here's the
>>>> > error
>>>> > that we are seeing on the bots:
>>>> > 124>javascriptcore_pcre.lib(pcre_xclass.obj) : error LNK2005: "bool
>>>> > __cdecl
>>>> > kjs_pcre_xclass(int,unsigned char const *)"
>>>> > (?kjs_pcre_xclass@@[EMAIL PROTECTED])
>>>> > already defined in v8_snapshot.lib(pcre_xclass.obj)
>>>> > -Darin
>>>> >
>>>> > 2008/11/26 Søren Gjesse <[EMAIL PROTECTED]>
>>>> >>
>>>> >> Could this be something like http://b/issue?id=1320493?
>>>> >> I ran into this exact issue a couple of weeks back. When I did a
>>>> >> rebuild
>>>> >> test_shell (or Chrome) it linked fine, and it also linked after the
>>>> >> first
>>>> >> changes and rebuilds, but after a few rebuilds the error in bug
>>>> >> report
>>>> >> started re-appearing. Deleting src/chrome/Debug did not fix it. The
>>>> >> only fix
>>>> >> I could find was to change the dependency of test_shell (and
>>>> >> chrome_dll) on
>>>> >> v8_snapshot to v8.
>>>> >> I have since created a new workspace and have never seen the problem
>>>> >> in
>>>> >> that workspace. I still have the broken workspace on my disk.
>>>> >> /Søren
>>>> >>
>>>> >> On Wed, Nov 26, 2008 at 4:09 AM, Erik Kay <[EMAIL PROTECTED]> wrote:
>>>> >>>
>>>> >>> I can help you take a look at this tomorrow morning.  Can you point
>>>> >>> me
>>>> >>> at the patch to use?
>>>> >>>
>>>> >>> Erik
>>>> >>>
>>>> >>>
>>>> >>> On Tue, Nov 25, 2008 at 6:34 PM, Ojan Vafai <[EMAIL PROTECTED]> wrote:
>>>> >>> > Purify builders are having link errors as of the most recent
>>>> >>> > webkit
>>>> >>> > merge.
>>>> >>> > Something about javascriptcore_pcre. I'm not sure if it's the
>>>> >>> > merge or
>>>> >>> > if
>>>> >>> > it's just that the merge cause more projects to need recompiling.
>>>> >>> > Seems
>>>> >>> > totally unrelated to any code touched by the merge.
>>>> >>> > In either case, Darin and I agreed that it's better to not roll
>>>> >>> > back
>>>> >>> > the
>>>> >>> > merge.
>>>> >>> > I can look into this tomorrow morning. If any other kind soul
>>>> >>> > feels
>>>> >>> > moved,
>>>> >>> > they are more than welcome to. I wasn't able to reproduce the link
>>>> >>> > error
>>>> >>> > using incredibuild. Will try with VS build tomorrow.
>>>> >>> > Ojan
>>>> >>> >
>>>> >>> >
>>>> >>
>>>> >
>>>> >
>>>> > >
>>>> >
>>>>
>>>>
>>>
>>
>>
>>
>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] removing ATL dependencies from Chromium

[Erik Kay]

It would be nice to remove ATL/WTL dependencies from Chromium so that
people can build it with Visual C++ Express.

While rewriting our UI code is unlikely to happen overnight, I was
thinking that it should be possible to at least build test_shell
without ATL.  Unfortunately, we have a handful of dependencies in base
and in our webkit port.  Some of these are trivial to fix, others not
so much.  I filed a handful of bugs against the ones that I found, so
if you've got some downtime or are looking for a small focused bit of
work to bite off, take a look at one of these:

base/wmi_util.cc - bug 5021 - lots of COM
webkit/tools/test_shell - bug 5022 - a few small issues
webkit/default_plugin - bug 5023 - UI for handling plugin installation
webkit/activex_shim - bug 5025 - more COM
tools/grit - string table .res files generated with ATL dependencies


Erik

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: removing ATL dependencies from Chromium

[Erik Kay]

On Tue, Dec 2, 2008 at 6:09 PM, Marc-Antoine Ruel <[EMAIL PROTECTED]> wrote:
> But don't work on 5025, I think it's wasted time. It's a non-essential plugin.

oops.  I had a typo.  That was actually 5024.  My original thought was
to remove it as well, but I was surprised that there were a bunch of
callouts to the code, testing for mime types, etc.  Perhaps the right
fix for that one is to make it a compile-time option.

Erik

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] using Hammer to generate smaller dlls and unit tests

[Erik Kay]

Now that we've got Hammer building the Windows version, and we've got
a dependency DAG being enforced by checkdeps, is there anything
holding us back from splitting up chrome.dll for Debug builds (or
maybe some other build target initially)?  It seems like the link time
wins would be large, as would the instrumentation cycle for Purify.

The same goes for unit_tests, which has gotten larger than chrome.dll.
 (I know people feel we have too many separate unit tests already, but
this should really be handled with smoketests.py anyway)

Erik

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: UI proposal: Open link in new foreground tab

[Erik Kay]

On Wed, Dec 10, 2008 at 6:40 AM, Mike Pinkerton <[EMAIL PROTECTED]> wrote:
> Note this is one of the prefs that even Camino has, where we are
> fairly rigorous about what prefs we allow. Some users prefer their
> default to open in the fg, others prefer them to open in the
> background. I think this is one of those cases where there is no
> "right" answer and the "preference" should be determined by the user.

Does Camino collect any usage stats?  If so, it would be interesting
to see how many people use this preference.

Erik

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: User scripts design doc

[Erik Kay]

On Wed, Dec 10, 2008 at 1:34 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 10, 2008 at 12:09 PM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>>
>> Ojan brought this up before, but I think it's a good idea, so I'll
>> evangelize it some more.  Instead of requiring the extension developer
>> to come up with an extension ID (com.google.myextension), use
>> templating to automatically substitute a guaranteed unique ID where
>> needed.  The template substitution would be done in the browser
>> process before we handed the script off to a renderer. Examples:
>> -  img.src = "${EXTENSION_URL}/foo.gif";
>> -  var extension = new chromium.Extension("${EXTENSION_ID}");
>
> It is a good idea. Part of the reason I brought back the short ID was
> we found two places it was useful (here, and as a name for
> directories) and I was worried we were going to keep coming up with
> examples like that. Also, it seems like using a public key as an ID is
> overkill in case we ever have SSL-served extensions.
>
> On the other hand, there is a lot of charm to only having the public
> key as an identifier in the case of packaged extensions. And I'm not
> that concerned about the escaping issues.
>
> Let me think on it some more. Erikkay -- any thoughts on this?

In general, my preference would be to have a single id for the
extension.  Multiple id's seem to always end in pain and hurting.  We
already have one id that we know we have to have - the public key.
This is what we're going to use for autoupdate and blacklisting.
However, the public key is far too unwieldy for general use in
referring to the extension in code and on the filesystem.  Even with
templating, it would wind up expanding the underlying URL to something
that would likely break some assertions.  Given this, I think we need
a second id.  The reason we went with the com.example.myextension
style id is that it's more in keeping with the purpose of this id
which is to be the simple, user-friendly, human readable version.  Why
introduce yet another wacky unreadable guid-based id when we don't
have to? I don't think it's too much trouble to ask the developer to
come up with an id that's unique in this scheme.

Unfortunately, I also think we couldn't do templating even if we
wanted to.  What if you want to have multiple extensions that
cooperate with each other?  They need a way to refer to each other.

Erik

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: User scripts design doc

[Erik Kay]

On Wed, Dec 10, 2008 at 2:24 PM, Peter Kasting <[EMAIL PROTECTED]> wrote:
> For file:// support, why not allow "file" as a supported scheme, but not
> include it in the "*" list?  Authors who wish to support it can explicitly
> add a match for it.

Yes, I thought this was in the original design.  We should also
explicitly support chrome:// URLs (and again, not have it match with
*).  Users should be able to use these scripts to hack on the new tab
page, etc.

Erik

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Rietveld improvements for large changelists

[Erik Kay]

Awesome John.  Thanks!


On Wed, Dec 10, 2008 at 4:00 PM, John Abd-El-Malek <[EMAIL PROTECTED]> wrote:
>
> (It's been suggested that I send this out to a large audience, so here you go)
>
> Most of the Rietveld problems that I see in the logs or that people
> complain about has been with regards to either very large changelists
> (i.e. > 100 files) or with many patchsets of large changelists (i.e.
> 10 patchsets of 20 files each).  I've recently been pushing fixes to
> alleviate these problems, so Rietveld should now be able to work with
> these kinds of changelists.  If you've been holding back using
> Rietveld for these reviews, or manually splitting them up into
> multiple changelists, this shouldn't be necessary anymore.
>
> Note that changelists with > 500 files still won't work.  Those are
> pretty rare and it would take major changes to how Rietveld works in
> order to make them work, so I don't think it's worth it at this point.
>
> As usual, let me know if you see any problems.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: layout test result scores don't match up?

[Erik Kay]

On Fri, Dec 12, 2008 at 9:10 AM, Mike Pinkerton  wrote:
> I noticed today that the numbers in score.txt don't match the same
> results dumped to stdout at the end of running the layout tests. eg:

How is score.txt generated?  I recently made a change to
run_webkit_tests.py that prints out an additional number in the
summary (the total number of tests in the system, prior to any
filtering or skipping).  It prints it out differently, but it's the
new first number that's printed out, so if the script that creates
score doesn't have a good pattern match, it would pick up the wrong
number.

Erik

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: code style verification/formatting tool

[Erik Kay]

jam++
Great stuff!  I like how this is integrated.  It feels very natural.

Erik


On Tue, Dec 16, 2008 at 8:16 PM, John Abd-El-Malek  wrote:

>
> Just a heads-up that I've integrated the script into our Rietveld
> instance.  If you use gcl, it will ping the server at a special url
> after a patchset upload so that it can lint the files in the
> background.  When you visit the issue page, you'll see  a "x errors"
> link under the Lint column which takes you to the lint output. If the
> file hasn't been linted yet, you'll see "? errors", in which case
> clicking the link will show the errors and save it for future
> refreshes of the issue page.
>
> On Fri, Dec 5, 2008 at 5:34 AM, Marc-Antoine Ruel 
> wrote:
> >
> > I did an internal search and the current state is:
> >
> > - "Folks have been looking at open sourcing cpplint"
> > - In its current incarnation, there is a lot of google-specific checks
> > that needs to be factored out simply because they don't apply to
> > external and open source projects.
> > - Nobody actually took over to do the work.
> >
> > So I wouldn't expect anything in the near term.
> >
> > M-A
> >
> > On Thu, Dec 4, 2008 at 10:24 PM, Marshall Greenblatt
> >  wrote:
> >> Ok, so, back to the original question.  When can those of us external to
> >> google expect a code style tool? :-)
> >>
> >> On Thu, Dec 4, 2008 at 1:57 PM, Dean McNamee 
> wrote:
> >>>
> >>> It doesn't need to be a parser, it's just a linter.  You don't really
> >>> need to understand anything about the program to give useful warnings
> >>> about style.  Our biggest style violation is probably trailing
> >>> whitespace, for example.
> >>>
> >>> On Thu, Dec 4, 2008 at 7:33 PM, Benjamin  wrote:
> >>> >
> >>> > You wrote a c++ parser in python? cl!  I can't wait to see the
> >>> > source.
> >>> >
> >>> > -Benjamin Meyer
> >>> >
> >>> > On Thu, Dec 4, 2008 at 12:22 PM, Pam Greene 
> wrote:
> >>> >>
> >>> >> On Wed, Dec 3, 2008 at 8:30 PM, Benjamin  wrote:
> >>> >>>
> >>> >>> On Wed, Dec 3, 2008 at 3:45 PM, Marshall Greenblatt
> >>> >>>  wrote:
> >>>  Sorry to be a pest, but has there been any progress on this?
> >>> 
> >>>  Thanks,
> >>>  Marshall
> >>> 
> >>>  On Thu, Sep 18, 2008 at 4:17 PM, Pam Greene 
> wrote:
> >>> >
> >>> > On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
> >>> >  wrote:
> >>> > > Hi Mark/Pam,
> >>> > >
> >>> > > On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai <
> m...@chromium.org>
> >>> > > wrote:
> >>> > >>
> >>> > >> Great question.  We've been talking about open-sourcing
> something
> >>> > >> for
> >>> > >> this, but so far, we don't have anything yet.  We do have
> >>> > >> something we
> >>> > >> use internally, but someone needs to go through it and clean
> up a
> >>> > >> few
> >>> > >> things before releasing it so that it runs well in the wild.
> >>> > >>  When it
> >>> > >> does materialize, it'll show up on the style guide project
> >>> > >> (http://google-styleguide.googlecode.com/).
> >>> > >
> >>> > > Do you guys have a timeline in mind of when such a tool might
> >>> > > become
> >>> > > available?  If there are potential code licensing/IP issues,
> >>> > > perhaps it
> >>> > > could be made available as a web-based service?  For instance,
> >>> > > something
> >>> > > like the w3c validator but returning the corrections in either
> >>> > > human-readable format or a format conducive to automation.
> >>> >
> >>> > Everybody's generally in support of open-sourcing the tool, and I
> >>> > don't anticipate any licensing conflicts; it's just a matter of
> >>> > finding the time to go through it.  For what it's worth, setting
> it
> >>> > up
> >>> > as a web-based service wouldn't be any faster.  More than days,
> less
> >>> > than months, would be my guess.
> >>> >
> >>> > - Pam
> >>> >>>
> >>> >>> A web tool would only delay releasing a real tool.  Just curious
> how
> >>> >>> is it written?  Using llvm, rpp, or another parser?
> >>> >>
> >>> >> It's in Python.
> >>> >>
> >>> >> - Pam
> >>> >>
> >>> >>>
> >>> >>> -Benjamin Meyer
> >>> >>>
> >>> >>> >
> >>> >>>
> >>> >>
> >>> >> >
> >>> >>
> >>> >
> >>> > >
> >>> >
> >>>
> >>>
> >>
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design for better supporting bookmarklets

[Erik Kay]

I didn't see any discussion in this for how we deal with the SSL lock icon
or the warning sign icon.  If we put these icons in the same location, and
allow them to be specified by the bookmarklet provider, then we have a
potential security issue.  It seems like the SSL lock icon needs to be in a
visually distinct place so that if someone else decides to put up an similar
looking icon, the likelihood of confusion is low.  While it's true that we
have other SSL indicators, this is still the one that users have been
trained to look for.
Erik


On Tue, Dec 16, 2008 at 5:33 PM, Nick Baum  wrote:

> Hi all,
>
> I've posted a document that describes how we could better support
> bookmarklets:
>
> http://sites.google.com/a/chromium.org/dev/user-experience/bookmarklets
>
> Let me know if you have any feedback!
> Cheers,
>
> -Nick
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Extensions and profiles

[Erik Kay]

On Wed, Dec 17, 2008 at 12:34 PM, Aaron Boodman  wrote:

>
> Thanks everyone for your feedback and examples.
>
> From this thread and talking to people in person, I came to the
> conclusions that:
>
> a) profile-level and machine-level extension installations are both
> important use cases
> b) there are relatively easy ways to work around the technical problem
> I was having implementing profile-level extension installations
>
> I have a implementation working and I'll be sending it out for comment
> soon.
>

Hmm.  This isn't the conclusion I came to.  First off, I think there was a
bit of confusion in terminology.  People were throwing around per-user vs.
per-machine, and that's not what Aaron was talking about here.  The main
issue right now is that Chrome still has a notion of multiple profiles.
 Even though most users don't use multiple user profile directories, many
use incognito, which is a separate user profile.  Since chrome is currently
installed per-user, this makes things a bit murky when you say
per-installation.  In reality, I think all we're currently talking about is
per-user vs. per-profile.  When we have machine-wide installs again, we can
talk about per-machine extensions.

The second thing I saw people blurring was installation vs. configuration.
 Just because you install the extension doesn't mean it has to be enabled
across all profiles or that it should have the same configuration data.  In
fact, I would argue that by default, they wouldn't be enabled across
profiles and wouldn't share configuration data.

Some of this discussion is also messed up because multiple profiles isn't
really a first class citizen in our UI, so it's unclear how much time we
should spend worrying about the use case.

Here's my take about how things should work
- installation of extensions should be per-user (with the possibility of
per-machine when we have it)
- configuration (including whether or not it's enabled) should be
per-profile
- incognito should be a special case - users can manually disable extensions
for incognito, but we also pass a special flag into extensions when running
in incognito mode so that if they do run, they can behave appropriately
 (ideally this is how we'd like to see plugins work as well)

Erik

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Is the zlib valgrind warning in GZipUnitTest.DecodeDeflate spurious?

[Erik Kay]

Yes, this is a known (benign) error.  See buganizer 1063732.  There
are a number of these in the purify filters that you guys should look at to
avoid duplicate effort.

Erik


On Fri, Dec 19, 2008 at 5:16 PM, Dan Kegel  wrote:
>
> I just ran into this today (using valgrind-3.4.0.SVN for its nifty
> track-origins option):
>
> $ valgrind --track-origins=yes Hammer/net_unittests
> --gtest_filter=GZipUnitTest.DecodeDeflate
>
> [ RUN  ] GZipUnitTest.DecodeDeflate
> Conditional jump or move depends on uninitialised value(s)
>   at longest_match (deflate.c:1121)
>   by deflate_slow (deflate.c:1595)
>   by MOZ_Z_deflate (deflate.c:790)
>   by (anonymous namespace)::GZipUnitTest::CompressAll((anonymous
> namespace)::EncodeMode, char const*, int, char*, int*)
> (gzip_filter_unittest.cc:142)
>   by (anonymous namespace)::GZipUnitTest::SetUp()
> (gzip_filter_unittest.cc:75)
>   by testing::Test::Run() (gtest.cc:1829)
>   by testing::internal::TestInfoImpl::Run() (gtest.cc:1999)
>   by testing::internal::TestInfoImpl::RunTest(testing::TestInfo*)
> (gtest-internal-inl.h:574)
>   by void testing::internal::List::ForEach (*)(testing::TestInfo*)>(void (*)(testing::TestInfo*)) const
> (gtest-internal-inl.h:335)
>   by testing::TestCase::Run() (gtest.cc:2094)
>   by testing::TestCase::RunTestCase(testing::TestCase*)
> (gtest-internal-inl.h:687)
>   by void testing::internal::List::ForEach (*)(testing::TestCase*)>(void (*)(testing::TestCase*)) const
> (gtest-internal-inl.h:335)
>  Uninitialised value was created by a heap allocation
>   at malloc (vg_replace_malloc.c:207)
>   by MOZ_Z_zcalloc (zutil.c:306)
>   by MOZ_Z_deflateInit2_ (deflate.c:287)
>   by MOZ_Z_deflateInit_ (deflate.c:210)
>   by (anonymous namespace)::GZipUnitTest::CompressAll((anonymous
> namespace)::EncodeMode, char const*, int, char*, int*)
> (gzip_filter_unittest.cc:120)
>   by (anonymous namespace)::GZipUnitTest::SetUp() (gzip_filter_unittest.cc:75)
>   by testing::Test::Run() (gtest.cc:1829)
>   by testing::internal::TestInfoImpl::Run() (gtest.cc:1999)
>   by testing::internal::TestInfoImpl::RunTest(testing::TestInfo*)
> (gtest-internal-inl.h:574)
>   by void testing::internal::List::ForEach (*)(testing::TestInfo*)>(void (*)(testing::TestInfo*)) const
> (gtest-internal-inl.h:335)
>   by testing::TestCase::Run() (gtest.cc:2094)
>   by testing::TestCase::RunTestCase(testing::TestCase*)
> (gtest-internal-inl.h:687)
>
> [   OK ] GZipUnitTest.DecodeDeflate
>
> (Strange that zcalloc calls malloc instead of calloc on 32 bit
> machines.  I wonder what the thinking there was?)
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: cpplint.py open sourced!

[Erik Kay]

Yay!  This will be a big help to external contributors.

It would be nice if a version of this could be adapted for WebKit
style as well.  ;-)

Erik


On Tue, Jan 13, 2009 at 2:25 PM, Elliot Glaysher (Chromium)
 wrote:
>
> Background: For the last couple of months, there have been requests
> from external contributors for a style linting tool. I've just finish
> cleaning Google's cpplint.py up for public release.
>
> cpplint.py takes file names as input and returns file/line number
> pairs with error messages about style violations. By default it
> outputs in a format friendly to emacs compile-mode, but can output
> Visual Studio compatible errors with the "--output=vs7" option. See
> cpplint.py --help for more details. cpplint.py is not perfect as it is
> based on regular expressions--thus it won't catch everything and will
> have the occasional false positive.
>
> John is planning on integrating this directly with gcl, but if you
> want to run it right now, the python script is available at:
>
>  http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
>
> For those who are interested, I've also released Google's indentation
> rules for emacs:
>
>  http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el
>
> -- Elliot
>
> >
>

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

[chromium-dev] minor changes to log files in unit tests

[Erik Kay]

If you never look at log output from unit tests, you can skip this message.

I landed a change today that makes sure that InitLogging is called
during startup of all of our unit tests that use test_suite (there are
a small number of tests that don't).  Prior to this, it would
initialize on first use.  This could lead to issues with threading
when two threads tried to use logging for the first time (this was
happening with base_unittests.exe).  The new behavior means that a
file handle will be opened immediately at launch where it wasn't
before (this affected at least one test that expected no file handles
to be opened when it ran).

As part of this change, I also changed the default filename of all of
the logs to be testname.log (e.g. base_unittests.log).  Perf unit
tests have two log files, testname.log and testname_perf.log (e.g.
perf_tests.log and perf_tests_perf.log).

All unit test initialization is now handled in one place
(base/test_suite.h) rather than scattered in each unit test.  If you
want to change what happens during test initialization, change it here
or in one of its subclasses.  There are no command-line flags that
affect the behavior of this general logging code.  Prior to this, some
tests had their own custom flags.  If you find yourself missing one of
these flags, add them back here so that all tests can benefit.

Erik

--~--~-~--~~~---~--~~
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: Making sense of startup

[Erik Kay]

On Thu, Jan 15, 2009 at 11:11 AM, Ben Goodger (Google)  
wrote:
> I'm not coming at this from an optimization perspective, I'm thinking
> more of making the startup flow understandable to mere mortals.

Amanda's suggestion would likely actually accomplish both, so I don't
think we should dismiss it if it happens to make startup faster as a
result as well. :-)

The gist would be to have some way for a given service to specify its
startup dependencies.  Once you do that, then you can essentially list
your startup services in pretty much any order since the dependencies
would get worked out correctly.  It would also allow us to catch
things like dependency cycles and to more clearly figure out how to
optimize startup time by perhaps figuring out how to remove
unnecessary dependencies.  Finally, it would allow easier unit testing
since you'd be able to safely grab a subset of the services you want
to test and to have a system that knows how to initialize properly
(addressing Scott's issue).

Of course, coming up with a nice way to express these dependencies
cleanly and actually figuring out what all of the dependencies are are
both easier said than done.

Erik

--~--~-~--~~~---~--~~
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: Making sense of startup

[Erik Kay]

On Thu, Jan 15, 2009 at 1:37 PM, Brett Wilson  wrote:
>
> On Thu, Jan 15, 2009 at 1:19 PM, Amanda Walker  wrote:
>>
>> That's true.  In the example I gave (Mac driver loading), each module
>> has a property list that lists its dependencies (and version
>> requirements, etc.).  That's not quite as simple to do inside a single
>> application, of course, but having code do the ordering still seems
>> like a win to me.
>>
>> Consider startup as a sequence of, say:
>>
>> Initializer foo("foo");
>> foo.DependsOn("bar");
>> foo.DependsOn("zot");
>>
>> Initializer alice("alice");
>> alice.DependsOn("bob");
>> alice.DependsOn("eve");
>> [...]
>> Initializer::LaunchAll();
>>
>> (or, more generally, "Initializer:::Launch("chromium");" where
>> "chromium" is a top level module, so that the general framework could
>> be used for things besides app launch)
>
> I have a hard time thinking about this with your abstract example. I
> also have a hard time believing we have so many interdependencies that
> it requires writing a makefile to start the program, and that such a
> syntax is easier to read than just listing out in comments why things
> are done in this order.

The issue is one of maintenance.  A lot happens at startup.  As people
make changes, it's not necessarily obvious where to insert your
initialization code.  Depending on your dependencies, your new service
may require a complex re-ordering of initialization.  If we actually
explicitly express dependencies and automatically manage them, then we
can be precise about it.

Maybe we'd have to see an example to know for sure, but it feels like
it would be easier to read startup dependencies if they were expressed
explicitly as opposed to comments which don't need to be complete and
can drift from reality.

Erik

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

[chromium-dev] watching the waterfall for purify errors

[Erik Kay]

This is a friendly reminder that when you check in, you're responsible
for looking at the output of the purify builders as well.  If you see
that they're red and you've checked in in the last few hours, look at
the builder's history to see if the first failure lines up with your
checkin.  In the last week or so, I've had to point out failures to
people pretty much every day.

Two caveats.  With each checkin, the layout tester is less of an
indicator that you've broken something recently since it runs a small
subset of the layout tests each time, it may cycle red then green and
red again, without any checkins.  Also, the purify bots are flakier
than we'd like, so they're red more than we'd like.  This means that
sometimes it will be red due to something you didn't do.  This doesn't
excuse you from checking to see if it's your error.

Erik

--~--~-~--~~~---~--~~
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: mismatched new/delete[] in webkit?

[Erik Kay]

(apologies for resend)

Yes.  This is the same issue.  This was also reported in:
  http://code.google.com/p/chromium/issues/detail?id=5464
where we decided to filter the errors in Purify because the code was
argued to be correct and an important optimization (and they didn't
want to change it).  Dean's making an attempt to get a real fix on the
WebKit side of things in the bug James linked to.

Erik


On Tue, Jan 27, 2009 at 8:52 AM, James Robinson  wrote:
> The last one looks similar
> to https://bugs.webkit.org/show_bug.cgi?id=23473 or 
> https://bugs.webkit.org/show_bug.cgi?id=22834,
> which Brett Wilson and Dean McNamee appear to be working on.
> - James
>
> On Tue, Jan 27, 2009 at 11:45 AM, Dan Kegel 
> wrote:
>>
>> Noticed in passing while looking for something else this morning
>> (though they may have been there a while).
>> These sound potentially nasty; is anybody looking at them already?
>>
>> $ valgrind --track-origins=yes Hammer/test_shell_tests
>> ...
>> [ RUN  ] WebFrameTest.GetContentAsPlainText
>> UNIMPLEMENTED:
>> (/home/dank/chromium/src/webkit/port/bindings/v8/ScriptController.cpp:143
>> updatePlatformScriptObjects)
>> Mismatched free() / delete / delete []
>>  at free (vg_replace_malloc.c:323)
>>  by WTF::fastFree(void*) (FastMalloc.cpp:216)
>>  by
>> WebCore::CSSSelectorList::adoptSelectorVector(WTF::Vector> 0u>&) (CSSSelectorList.cpp:57)
>>  by
>> WebCore::CSSStyleRule::adoptSelectorVector(WTF::Vector> 0u>&) (CSSStyleRule.h:53)
>>  by WebCore::CSSParser::createStyleRule(WTF::Vector> 0u>*) (CSSParser.cpp:4547)
>>  by cssyyparse(void*) (CSSGrammar.y:792)
>>  by WebCore::CSSParser::parseSheet(WebCore::CSSStyleSheet*,
>> WebCore::String const&) (CSSParser.cpp:224)
>>  by WebCore::CSSStyleSheet::parseString(WebCore::String const&,
>> bool) (CSSStyleSheet.cpp:164)
>>  by WebCore::parseUASheet(WebCore::String const&)
>> (CSSStyleSelector.cpp:486)
>>  by WebCore::parseUASheet(char const*, unsigned int)
>> (CSSStyleSelector.cpp:492)
>>  by WebCore::loadSimpleDefaultStyle() (CSSStyleSelector.cpp:531)
>>  by WebCore::CSSStyleSelector::CSSStyleSelector(WebCore::Document*,
>> WebCore::String const&, WebCore::StyleSheetList*,
>> WebCore::CSSStyleSheet*, bool, bool) (CSSStyleSelector.cpp:406)
>>  Address 0x127ac840 is 0 bytes inside a block of size 16 alloc'd
>>  at operator new(unsigned int) (vg_replace_malloc.c:224)
>>  by WebCore::CSSParser::createFloatingSelector() (CSSParser.cpp:4382)
>>  by cssyyparse(void*) (CSSGrammar.y:883)
>>  by WebCore::CSSParser::parseSheet(WebCore::CSSStyleSheet*,
>> WebCore::String const&) (CSSParser.cpp:224)
>>  by WebCore::CSSStyleSheet::parseString(WebCore::String const&,
>> bool) (CSSStyleSheet.cpp:164)
>>  by WebCore::parseUASheet(WebCore::String const&)
>> (CSSStyleSelector.cpp:486)
>>  by WebCore::parseUASheet(char const*, unsigned int)
>> (CSSStyleSelector.cpp:492)
>>  by WebCore::loadSimpleDefaultStyle() (CSSStyleSelector.cpp:531)
>>  by WebCore::CSSStyleSelector::CSSStyleSelector(WebCore::Document*,
>> WebCore::String const&, WebCore::StyleSheetList*,
>> WebCore::CSSStyleSheet*, bool, bool) (CSSStyleSelector.cpp:406)
>>  by WebCore::Document::attach() (Document.cpp:1383)
>>  by WebCore::Frame::setDocument(WTF::PassRefPtr)
>> (Frame.cpp:272)
>>  by WebCore::FrameLoader::begin(WebCore::KURL const&, bool,
>> WebCore::SecurityOrigin*) (FrameLoader.cpp:949)
>>
>> Mismatched free() / delete / delete []
>>  at operator delete(void*) (vg_replace_malloc.c:342)
>>  by WebCore::V8Proxy::InitContextIfNeeded() (v8_proxy.cpp:2318)
>>  by WebCore::V8Proxy::GetContext(WebCore::Frame*) (v8_proxy.cpp:2473)
>>  by WebCore::ScriptController::BindToWindowObject(WebCore::Frame*,
>> WebCore::String const&, NPObject*) (ScriptController.cpp:278)
>>  by WebFrameImpl::BindToWindowObject(std::basic_string> std::char_traits, std::allocator > const&,
>> NPObject*) (webframe_impl.cc:689)
>>  by CppBoundClass::BindToJavascript(WebFrame*,
>> std::basic_string,
>> std::allocator > const&) (cpp_bound_class.cc:255)
>>  by TestShell::BindJSObjectsToWindow(WebFrame*) (test_shell.cc:409)
>>  by TestWebViewDelegate::WindowObjectCleared(WebFrame*)
>> (test_webview_delegate.cc:122)
>>  by WebFrameLoaderClient::windowObjectCleared()
>> (webframeloaderclient_impl.cc:100)
>>  by WebCore::FrameLoader::dispatchWindowObjectAvailable()
>> (FrameLoader.cpp:5180)
>>  by WebCore::FrameLoader::receivedFirstData() (FrameLoader.cpp:878)
>>  by WebCore::FrameLoader::setEncoding(WebCore::String const&, bool)
>> (FrameLoader.cpp:1899)
>>  Address 0x11c66678 is 0 bytes inside a block of size 4 alloc'd
>>  at operator new[](unsigned int) (vg_replace_malloc.c:268)
>>  by WebCore::V8Proxy::InitContextIfNeeded() (v8_proxy.cpp:2309)
>>  by WebCore::V8Proxy::GetContext(WebCore::Frame*) (v8_proxy.cpp:2473)
>>  by WebCore::ScriptController::BindToWindowObject(WebCore::Frame*,
>> WebCore::String const&, NPObject*) (ScriptController.cpp:278)
>>  by WebFrameImpl::BindToWindowObject(std::basic_string> std::char_traits, s

[chromium-dev] Re: Responsibility reviewing patches with multiple reviewers

[Erik Kay]

This feels like a tools issue to me.  In Mondrian, the review has an
overall score on it (or at least it did the last time I used it).  If
a reviewer replied without a LGTM, then it subtracted 1.  A reply with
a LGTM added 1.  It didn't allow you to commit the change until you
had at least a +1, so with multiple reviewers asking for changes, it
was clear whether you had something still pending or not.  I'm not
convinced that this precise mechanism is what we'd want, but perhaps
something related would help.

Erik


On Tue, Jan 27, 2009 at 10:04 PM, Brett Wilson  wrote:
>
> There are a lot of patches lately with a lot of reviewers on them,
> especially related to porting since a lot of people might need to be
> in the loop for some changes.
>
> The problem is that there's no clear responsibility given in these
> reviews. If I'm the sole reviewer on a change, I know I have to do a
> good job. When there are three other people, I sometimes assume that
> somebody else must have looked carefully at some part of the review.
> I'm sure sometimes all the reviewers think this and the change isn't
> reviewed properly.
>
> In other cases, some reviewers say LGTM for a patch, while others are
> still expecting changes. The author can get confused as to the status
> of the review, and I also know some patches have been checked in
> lately where at least one reviewer expected further changes before
> checkin.
>
> At the same time, we want to encourage many people to participate in
> the review process and keep tabs on what's going on. I propose several
> changes to best practices:
>
> 1. When a patch author requests more than one reviewer, they should
> make clear in the review request email what they expect the
> responsibility of each reviewer to be. Example:
>  agl: bitmap changes
>  evanm: process hacks
>  everybody else: FYI
> In this case, I might be on the review list because I've asked to be
> in the loop for multiprocess changes, but I wouldn't be the primary
> reviewer and the author and other reviewers wouldn't be expecting me
> to review all the diffs in detail.
>
> 2. If you get a review that includes many other people, and the author
> didn't do (1), please ask them what part you're responsible for if you
> don't want to review the whole thing in detail.
>
> 3. The author should wait for approval from everybody on the reviewer
> list before checking in.
>
> 4. People who are on a review without clear review responsibility
> should be super responsive and not hold up the review. The patch
> author should feel free to ping them mercilessly if they are.
>
> 5. If you're on "FYI" person on a review and you didn't actually
> review in detail (or at all), but don't have a problem with the patch,
> note this. You could say something like "rubber stamp" or "ACK"
> instead of "LGTM." This way the real reviewers know not to trust that
> you did their work for them, but the author of the patch knows they
> don't have to wait for further feedback from you.
>
> Hopefully we can still keep everybody in the loop but have clear
> ownership and detailed reviews. It might even speed up some patches
> since I can quickly ACK patches I don't care about, and the patch
> author knows they don't have to wait for feedback from me. Or do you
> think this has too much overhead?
>
> Comments?
>
> Brett
>
> >
>

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

[chromium-dev] Re: Accessing DOM from extension process

[Erik Kay]

(apologies for repost)

On Tue, Jan 27, 2009 at 10:05 AM, Yury Semikhatsky  wrote:
> On Tue, Jan 27, 2009 at 8:08 PM, Aaron Boodman  wrote:
>>
>> It seemed complicated to allow other processes direct access to the
>> DOM, so we were not going to do that.
>
> But many extensions will need to access the DOM one way or another.
> Are you going to restrict this access or probably inject extensions
> code directly into the page(as it's described in early design document)?

I think the biggest difference between what the out of process
inspector needs and what the extension system needs is that we don't
need to keep a mirror of the DOM in the extension processes.  For
extensions that need to modify or inspect page content, the model will
be that they inject script into the page and then use higher level
message passing.

That said, if you guys really nail this remote DOM API and get it to
perform well, it could be interesting to extensions as well.  I'm a
little dubious since the performance needs are likely a bit different
when you're debugging a process.  In our case, we're really trying
hard to avoid noticeable slowdowns in interactive page performance.

Erik

--~--~-~--~~~---~--~~
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: Don't include render_messages.h in a header

[Erik Kay]

(arg.  reposting again)

One thing that scons is very good at is dependency analysis.  Is it
possible to get it to spit out a dependency report (which files depend
on each file in the project)?  I wonder if we might find that files
like npapi.h don't actually need to touch everything, etc.

Erik


On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
>
> I fear we have a have a couple long threads of headers that touch
> everything.  At one point we had something like: v8 bindings -> stats
> table -> process_util -> process, which meant if you touched any of
> our process-management code we'd rebuild all of WebKit's SVG bindings.
>  :~(
>
> For an especially painful build, try touching npapi.h.  Apparently
> most of our project depends on that file.
>
> On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek  wrote:
>>
>> I've gone through the code and removed all such occurrences. This
>> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
>> SSD). It also means that editing that file only rebuilds 36 files
>> instead of 200.
>>
>> There shouldn't be any reason to include that file from a header. The
>> reason this has happened is that people have ended up using structs
>> that define the parameters of an IPC message with many parameters as
>> member variables in classes. If this happens, then the struct should
>> just be moved to its own file outside of render_messages.h.
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Don't include render_messages.h in a header

[Erik Kay]

(sorry for repost, gmail sucks and I have a short memory)

On Thu, Feb 5, 2009 at 2:51 PM, Steven Knight  wrote:
> Hi Erik--
> It depends on what you really want.  SCons does have all of the
> dependencies, but it doesn't keep the #include tree.
> Tangible example:  if "foo.c" #includes "inc.h", and "inc.h" also #includes
> both "a.h" and "b.h", the resulting dependency list actually looks like:
> foo.o:   foo.c inc.h a.h b.h
>
> It's trivial to dump that sort of information from SCons' database (there's
> a "sconsign" script that will do it).
> It would not show you which files #included each other, which for this
> example would look something like:
> foo.o:   foo.c
> foo.c:   inc.h
> inc.h:   a.h b.h
> (SCons doesn't track those #include relationships are not actually
> dependencies.)

Right, I figured all of the info was there.  I guess the question was
whether it was easy to do something like this:

$ scons_deps a.h
foo.c

$ scons_deps -v a.h
foo.c:inc.h:a.h

$ scons_deps -v 
foo.c:inc.h:a.h
foo.c:inc.h:b.h
bar.c:bar.h
etc.

Does such a script (or something similar) exist?  From what you're
saying, I'm assuming it's easy to write.


> Now that I think about it, I'm not sure how you'd use either set of
> information to determine automatically that a dependency isn't needed.  The
> dependencies only exist because there's actually a #include line somewhere
> in the chain that will (or might) suck it into the compile.  Trying to
> figure out if a given #include is somehow unnecessary for a given .o file
> seems like a garbage-in-garbage-out problem; I don't see where you'd derive
> the distinction that indicates one #include is necessary but another isn't.
> But if someone does come up with a use for the dependency info (per the
> first example above), it's easy enough to get.

Right, I wasn't assuming you'd be able to figure out if a given
dependency was necessary in an automated way.  The point of this would
be to emit a report that then could be examined by a human.  We could
easily munge the data and answer questions like "which header is most
depended on in the source?", or "which header file adds the most bytes
to a build?" (size in bytes * number of files included)


Erik



> On Thu, Feb 5, 2009 at 11:26 AM, Erik Kay  wrote:
>>
>> (arg.  reposting again)
>>
>> One thing that scons is very good at is dependency analysis.  Is it
>> possible to get it to spit out a dependency report (which files depend
>> on each file in the project)?  I wonder if we might find that files
>> like npapi.h don't actually need to touch everything, etc.
>>
>> Erik
>>
>>
>> On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
>> >
>> > I fear we have a have a couple long threads of headers that touch
>> > everything.  At one point we had something like: v8 bindings -> stats
>> > table -> process_util -> process, which meant if you touched any of
>> > our process-management code we'd rebuild all of WebKit's SVG bindings.
>> >  :~(
>> >
>> > For an especially painful build, try touching npapi.h.  Apparently
>> > most of our project depends on that file.
>> >
>> > On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek 
>> > wrote:
>> >>
>> >> I've gone through the code and removed all such occurrences. This
>> >> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
>> >> SSD). It also means that editing that file only rebuilds 36 files
>> >> instead of 200.
>> >>
>> >> There shouldn't be any reason to include that file from a header. The
>> >> reason this has happened is that people have ended up using structs
>> >> that define the parameters of an IPC message with many parameters as
>> >> member variables in classes. If this happens, then the struct should
>> >> just be moved to its own file outside of render_messages.h.
>> >>
>> >> >
>> >>
>> >
>> > >
>> >
>>
>> >>
>
>

--~--~-~--~~~---~--~~
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: checkdeps failure when a unit test relies on v8.h

[Erik Kay]

v8 is already in the browser process.

Erik


On Sun, Feb 15, 2009 at 1:46 PM, Evan Martin  wrote:
>
> Does this mean we'll have v8 in the browser process?
>
> We had idly chatted about running a 64-bit browser process to fix the
> library hell on Linux.  It shouldn't block you either way -- I'm just
> curious.
>
> On Sun, Feb 15, 2009 at 1:42 AM, Aaron Boodman  wrote:
>>
>> I'm trying to commit a change
>> (http://codereview.chromium.org/19737/diff/1440/1448 ) which adds a
>> base class for unit tests that exercise JavaScript. It uses v8.h,
>> which is disallowed by DEPS. What is the right way to do this?
>>
>> - 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: checkdeps failure when a unit test relies on v8.h

[Erik Kay]

On Tue, Feb 17, 2009 at 8:06 AM, Marc-Antoine Ruel  wrote:
> I guess it's not doable ATM anyway but does the debugger really needs
> to run in the browser?

I think the debugger's dependency is already gone (or very close to
it).  It's still used in the telnet interface, but nobody's really
using that at the moment.  If it really causes a problem being there,
then I'd say to go ahead and remove it.   However, if it's not causing
problems, then I'd say that it should be left in.  We've got some long
standing ideas for how to use this to simplify browser automation,
specifically for testing, but perhaps for user scripting as well.
Nothing active is happening on this front though.

Erik

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

[chromium-dev] Using Purify - how to fix the buildbots

[Erik Kay]

I added a page to the wiki that talks about using Purify in the
Chromium project:
http://sites.google.com/a/chromium.org/dev/developers/how-tos/using-purify

For Googlers, this is an updated version of an old page you may have
seen before.  It has a few important changes however, so I encourage
you to read it.

Most importantly, the instructions for how to address the bot turning
red, and how to filter out errors temporarily have been updated and
clarified.

For contributors who don't have access to Purify, there's useful
information here about how to tackle errors from the buildbot even
without having Purify installed.

Erik

--~--~-~--~~~---~--~~
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: VS solution takes forever to load

[Erik Kay]

Wow.  That's really cool.  The slow solution load time has been really
pissing me off for a while now.  Emptying this directory fixed this
problem completely for me.  I recommend everyone do this.

The wacky bit about that directory is that (for me at least) it's a
bunch (31000+) of empty directories.  Just opening the directory up to
look at it took almost 10 minutes for me.  Someone on the net said it
took him two hours to delete the files.  I recommend that you do it
from the command-line.

I did some searching using my favorite search engine and found the
following tidbit:
===
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=347228
Our problem is that developers are accumulating massive numbers of
directories and files (24,000+ directories in one case) in the
%userroot%\Local Settings\ApplicationData\Microsoft\WebSiteCache
directory.Our solutions tend to have upward of 150-200 projects so
this is a real problem. We are also seeing the following unnecessary
lines (for windows apps!) in our .sln files that seem to be causing
the issue:
ProjectSection(WebsiteProperties) = preProject
Debug.AspNetCompiler.Debug = "True"
Release.AspNetCompiler.Debug = "False"
EndProjectSection
===

Apparently, the unnecessary insertion of these lines is a known bug in
VS2005 that's fixed in VS2008.  Maybe the new solution/project
generator will solve this for us by omitting these lines from the sln.

Erik


On Thu, Feb 19, 2009 at 2:41 PM, Eric Roman  wrote:
>
> So I recently had the problem where loading "chrome.sln: takes about
> 10 minutes (in other words, absurdly long).
>
> It seems this time the the problem was VS trying to load many hundreds
> of hundreds of files from "~/Local Settings/Application
> Data/Microsoft/WebsiteCache/*"
> Not sure why that happened, but deleting "WebsiteCache" did help dramatically.
>
> Since super slow load times is a regular problem for me, I am
> wandering what workarounds others have.
>
> One thing I find myself frequently doing is to delete the "chrome.ncb"
> and build output directories. This usually shaves off a couple minutes
> for me, and is marginally less disruptive to rebuild than be stuck
> waiting for the project to load.
>
> Thanks!
>
> >
>

--~--~-~--~~~---~--~~
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: Where is the data for reliablity and purify tests stored?

[Erik Kay]

John,

I just sent out email this past week to chromium-dev about an updated
wiki page with all of the Purify info you could want (search for
"Using Purify").  The page is here:

http://dev.chromium.org/developers/how-tos/using-purify

The short answer for these tests is that the data is in:
  src/chrome/test/data/purify

and the data that you need in order to add to these config files is here:
  http://build.chromium.org/buildbot/purify/unit/

Erik


On Sat, Feb 21, 2009 at 12:12 PM, John Abd-El-Malek  wrote:
> (CCing chrome-dev so that others who don't know can search for this later.
>  Using Erik's & Huan's chromium emails so reply get sent to the list).
>
> I submitted some refactoring and now I'm seeing the reliability and purify
> tests are red, which I think is a false alarm due to callstacks changing.
> For the reliability tests, this is the new regression.  I don't think my
> code could have affected this, so my hunch is that this callstack didn't
> match an existing list since RenderThread::OnMessageReceived is now
> ChildThread::OnMessageReceived.  But I can't find out where the existing
> crash callstacks are stored so I can verify this?
>
> http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Reliability/builds/1155/steps/reliability%20tests/logs/stdio
>
> REGRESSION: NEW crash stack traces found
> 
> chrome_23e!WebCore::FrameLoader::submitFormAgain+0x1e
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp
> @ 511]
> chrome_23e!WebCore::FrameLoader::executeScript+0x5d
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp
> @ 788]
> chrome_23e!WebCore::HTMLTokenizer::scriptExecution+0xc7
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> @ 608]
> chrome_23e!WebCore::HTMLTokenizer::notifyFinished+0x204
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> @ 1986]
> chrome_23e!WebCore::CachedScript::addClient+0x23
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedscript.cpp
> @ 57]
> chrome_23e!WebCore::HTMLTokenizer::scriptHandler+0x404
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> @ 494]
> chrome_23e!WebCore::HTMLTokenizer::parseSpecial+0x3fd
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> @ 347]
> chrome_23e!WebCore::HTMLTokenizer::parseTag+0x112c
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> @ 1495]
> chrome_23e!WebCore::HTMLTokenizer::write+0x410
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> @ 1726]
> chrome_23e!WebCore::HTMLTokenizer::notifyFinished+0x27c
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> @ 2014]
> chrome_23e!WebCore::CachedImage::checkNotify+0x3a
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedimage.cpp
> @ 320]
> chrome_23e!WebCore::CachedScript::data+0x99
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedscript.cpp
> @ 98]
> chrome_23e!WebCore::Loader::Host::didFinishLoading+0xab
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\loader.cpp
> @ 305]
> chrome_23e!WebCore::SubresourceLoader::didFinishLoading+0x2b
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\subresourceloader.cpp
> @ 183]
> chrome_23e!WebCore::ResourceLoader::didFinishLoading+0x7
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\resourceloader.cpp
> @ 417]
> chrome_23e!WebCore::ResourceHandleInternal::OnCompletedRequest+0xf7
> [c:\b\slave\chromium-rel-xp\build\src\webkit\glue\resource_handle_impl.cc @
> 636]
> chrome_23e!ResourceDispatcher::OnRequestComplete+0x86
> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc @
> 419]
> chrome_23e!IPC::MessageWithTuple
>>::Dispatch ResourceDispatcher::*)(int,URLRequestStatus const &)>+0x30
> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\ipc_message_utils.h @
> 1135]
> chrome_23e!ResourceDispatcher::DispatchMessageW+0x97
> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc @
> 464]
> chrome_23e!ResourceDispatcher::OnMessageReceived+0x174
> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc @
> 277]
> chrome_23e!RenderView::OnMessageReceived+0x81
> [c:\b\slave\chromium-rel-xp\build\src\chrome\renderer\render_view.cc @ 333]
> chrome_23e!MessageRouter::RouteMessage+0x34
> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\message_router.cc @ 39]
> chrome_23e!MessageRouter::OnMessageReceived+0x30
> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\message_router.cc @ 30]
> chrome_23e!ChildThread::OnMessageReceived+0x36
> [c:\b\slave\c

[chromium-dev] Re: [extensions] Thoughts on scaling

[Erik Kay]

In general, I'm all for this approach.  As you said, I think a large
number of trivial extensions are either purely action based, or can be
handled dynamically  declarative ways (for example, maybe a weather
extension could fetch the latest weather icon from a declared URL, RSS
feed).

On Mon, Feb 23, 2009 at 12:51 PM, Aaron Boodman  wrote:
> We'd still need the ability to spin up extension processes to render
> bigger UI, like when a dialog needs to be opened or a sidebar needs to
> be displayed.

Agree.  I think in general if we can be on-demand or lazy with process
creation, it'll be a big win.  Another example of this is an
extenion's config page.

Erik

--~--~-~--~~~---~--~~
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: Profile Corruption, cause?

[Erik Kay]

One thing that would help is if some of the users who are running into
this would be willing to share their whole profile with us.

While our best guess is that this is sqlite corruption, we don't know
for sure.  Even if it is sqlite corruption, having the specific db
might help us figure out how to more reliably detect it.

Erik


On Thu, Mar 5, 2009 at 10:39 PM, Finnur Thorarinsson
 wrote:
> I suspect this is like crashes due to memory corruption: It won't do much
> good to stare at the call stack at the time corruption was detected; we need
> to know the stack at the time corruption occurred (assuming this is Chrome
> that is corrupting the profile).
> For memory corruptions we have gflags; I wonder if there is something in
> SqlLite that can help us here?
>
> On Thu, Mar 5, 2009 at 22:20, Mark Larson (Google)  wrote:
>>
>> Mohamed,
>> I'm glad to see your interest in tackling this problem.
>> Unfortunately, that data is collected under an agreement between the user
>> and Google, so we cannot share the dumps. It's OK to share the stack traces,
>> which have no personally identifying information, but I'm not sure we can
>> even find a set of reports definitely correlated with profile corruption.
>> This makes me wonder if we should have an integrity check when we detect
>> that the browser crashed in the previous session. It might be useful to
>> offer to reset the user's profile or (ideally) drop the parts that are
>> corrupt. I'd personally rather drop my entire browsing history to keep my
>> saved passwords (and vice versa). The UI would have to be diplomatic.
>> Maybe some developers who have dealt with corruption issues in the past
>> can provide some advice on things we could do to address corruption.
>> Thanks,
>> Mark
>> On Thu, Mar 5, 2009 at 21:09, Mohamed Mansour 
>> wrote:
>>>
>>> Hello, on the Google Help Forums, 80-85% of the crashes reported there
>>> are due to profile corruptions. What they have to do is run chrome in a new
>>> user directory, chrome.exe --user-data-dir=c:\foo, or deleting the local
>>> state file.
>>> Anyone have any idea what may of caused this? Users who don't know the
>>> answer to this problem, usually give up using the browser. Chrome is a great
>>> browser, and its sad to see people not using it because of this. If anyone
>>> has any crash logs due to this (from user reporting), and since its internal
>>> to Google, can you share the stack trace? I would like to spend one weekend
>>> taking a look at it.
>>> Thanks!
>>>
>>
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Profile Corruption, cause?

[Erik Kay]

On Fri, Mar 6, 2009 at 9:33 AM, Brett Wilson  wrote:
> Getting the database has helped in a few cases where it turned out some
> assumptions were being violated, but if the sqlite data structures are
> corrupted, getting the DB has never been helpful to diagnose the root cause.
>
> It might help us make sqlite not crash for these types of corruption,
> though.
>
> I think we should install an exception handler on the DB threads, and if we
> get two crashes in a row from sqlite, recreate the DB.

Yep.  This would be nice.  If these crashes are really this frequent,
perhaps we should move the db out of the browser process. Or perhaps
we could simply have an out of process validator that we could run if
we got a single browser crash from sqlite.

Erik



> Brett
>
> On Mar 6, 2009 9:19 AM, "Erik Kay"  wrote:
>
>
> One thing that would help is if some of the users who are running into
> this would be willing to share their whole profile with us.
>
> While our best guess is that this is sqlite corruption, we don't know
> for sure.  Even if it is sqlite corruption, having the specific db
> might help us figure out how to more reliably detect it.
>
> Erik
>
> On Thu, Mar 5, 2009 at 10:39 PM, Finnur Thorarinsson 
> wrote: > I suspect this...

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

[chromium-dev] Re: Changes to the waterfall.

[Erik Kay]

(repost)

On Mon, Mar 9, 2009 at 9:45 AM, Nicolas Sylvain  wrote:
> I think purify ui tests is just waiting for a new version of purify maybe?
> After that it should be easy enough to turn it green.

Nope.  The purify UI tests are looking for some love and attention
(AFAIK, nobody's working on it right now).  While some of the hangs
are likely Purify bugs, without someone actually tracking them down,
no progress will be made.


> I could also move valgrind to the FYI waterfall if we don't plan to make
> progress and add it to the top bar anytime soon.

>From what I remember Dan Kegel owns this and was going to get on it a
few weeks ago.  Dan?


Erik

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

[chromium-dev] codinghorror on Chrome error messages

[Erik Kay]

I hadn't seen this sent around yet in case some of you missed this:
http://www.codinghorror.com/blog/archives/001238.html


Erik

--~--~-~--~~~---~--~~
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: [extensions] Extensions HOWTO doc

[Erik Kay]

On Tue, Mar 17, 2009 at 1:00 AM, Aaron Boodman  wrote:

>
> Extensions comrades,
>
> Here are my takeaways on what we can improve based on Glen's experience:
>
> * Make the id field optional for development mode
> * We should add a temporary alert box saying "success" after
> installation of a crx file, until we have a proper install UI
> * We should reuse the current process when a crx file is opened by a
> chrome instance (we talked about this today)
> * We should add some easy way to create a crx file using chrome.exe or
> a website or something


Agree with these points, but here's a slightly less annoying cheat for the
install UI:
- open up raf's extension ui page in a tab and highlight the newly installed
extension





>
>
> - a
>
> On Mon, Mar 16, 2009 at 11:54 PM, Aaron Boodman  wrote:
> > On Mon, Mar 16, 2009 at 10:52 PM, Glen Murphy  wrote:
> >> I created a content script this evening. If it helps you refine the
> >> doc, here are the things I ran into. I was using a nightly build
> >> (11818):
> >
> > Thanks a lot for the feedback!
> >
> >> - I didn't expect, and was thankful for the manifest validation error
> >> messages. I wonder where these should go.
> >
> > Whee. I love error messages and am glad you found them helpful. I also
> > don't know where they should go yet, but I don't want to remove them
> > until we have a better place because they are so useful.
> >
> >> - Sometimes the script seemed to fail to load - particularly after
> >> hitting reload.
> >
> > That is weird, I've never noticed that. The only thing that I can
> > imagine is that because the reload is asynchronous, you were beating
> > it, but that seems hard to believe. Did you notice that the second
> > time you refreshed you'd see your changes?
> >
> >> - Couldn't see JS errors for the extension in the inspector, but I
> >> think the inspector is pretty hosed regardless.
> >
> > What do you mean? JavaScript errors from content scripts? Or other
> > types of extension errors? You should definitely see errors, and I
> > know I've seen them before.
> >
> >> - Because of both of the above, I always just restarted Chrome
> >> whenever I made any changes, setting my homepage to my test page.
> >
> > That sucks, I really want a edit-reload development experience.
> >
> >> - I missed the bit about the ID being a 40-digit hex number and spent
> >> a long time trying all sorts of stuff with my name in it.
> >
> > Yeah, we should just remove the requirement for the ID altogether from
> > the development mode.
> >
> >> - I also missed the bit about Python 2.6 and spent a reasonable amount
> >> of time figuring out how to install the non-default dep (SimpleJSON)
> >> in my Python 2.5, as the ez_setup only pretended to work.
> >> - I put chromium_extension.py in the same dir as the files. It then
> >> included itself in the CRX.
> >
> > We want to add a feature to Chrome itself where you can just use it to
> > create the package.
> >
> >> - The doc isn't clear about what to do with the CRX. Dragging it onto
> >> Chrome downloads it, and setting Chrome as the default opener for the
> >> filetype results in an infinite tab-spawning download loop (opening it
> >> downloads it again, after which it autoopens : repeat). If it's not
> >> implemented, can we say so?
> >
> > Dragging it onto Chrome should download it, then install it, but there
> > is no UI letting you know that anything happened right now, and it
> > also doesn't work correctly when you're using a Chrome that isn't your
> > default installation.
> >
> > I will update the doc and try and fix these issues.
> >
> >> - Either way, you may find it here:
> >>  OR
> >>  (5KB) - it's a version of that
> >> content-clipping script we wrote a few years ago. alt+drag to create,
> >> double-click to spawn.
> >
> > Both files appear to be invalid??
> >
> >> - I was worried that all of the content-scripting I'd forgotten would
> >> come and bite me, but apart from brief confusion over scope
> >> ('document' working, but 'window' requiring 'contentWindow'), writing
> >> the code itself was easy as pie.
> >
> > 'window' shouldn't require contentWindow, unless you want to access
> > the content window's global scope, which doesn't seem necessary for
> > what you're trying to do (but I can't remember exactly what feature
> > you're talking about).
> >
> > - 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] sheriffs: please keep the purify bots green

[Erik Kay]

We had been doing a decent job of keeping the main purify bots green the
last couple of weeks, but over the weekend, it looks like a new regression
slipped into XP unit.  That further masked another new error that was
introduced yesterday.
I've asked this before, but please treat a purify bot turning red as if any
other bot turned red.  Close the tree.  Track down the change.  Roll it
back, etc.

There's detailed documentation on how to temporarily skip tests or add
errors to an ignore list:
http://dev.chromium.org/developers/how-tos/using-purify#TOC-When-the-bot-turns-red

As sheriffs, you're the ones who need to drive this.  Feel free to ping me
if you need help tracking down an issue.

Erik

--~--~-~--~~~---~--~~
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: sheriffs: please keep the purify bots green

[Erik Kay]

+yurys

Thanks for tracking this one down, Alpha.

Yury, I think the remaining error is yours (from
http://codereview.chromium.org/42233 at r11855).

Erik


On Wed, Mar 18, 2009 at 2:29 PM, Alpha (Hin-Chung) Lam  wrote:
>
> Found the root in 
> chrome/browser/renderer_host/resource_dispatcher_host_unittest.cc
> Review: http://codereview.chromium.org/42360
> Alpha
> 2009/3/18 Dean McNamee 
>>
>> It looks similar to:
>>
>> http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/builds/2466/steps/purify%20test:%20unit/logs/stdio
>>
>> Which is what caused hclam's patch to reverted previously.
>>
>> On Wed, Mar 18, 2009 at 7:55 PM, Adam Langley  wrote:
>> >
>> > On Wed, Mar 18, 2009 at 11:48 AM, Marc-Antoine Ruel  
>> > wrote:
>> >> It could be anywhere from 11801 to 11818. ben, jam, agl, dkegel, hclam,
>> >> levin, tc, pkasting checked in during that time frame. ager, sgk did
>> >> non-code changes so I don't think it's them.
>> >> We'll soon make the tree automatically close on failure on some tests. One
>> >> of the issue here is latency.
>> >> Erik, if you can track it down, that'd be really appreciated.
>> >
>> > Possibly hclam:
>> >
>> > UMR in chrome/common/render_messages.h:1257
>> > IPC::ParamTraits::Write(Message::IPC *,ViewHostMsg_Resource_Request
>> > const&)
>> >
>> >
>> >
>> > AGL
>> >
>> > >
>> >
>>
>> >>
>

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

[chromium-dev] Re: Chromium App Executables Disk Layout

[Erik Kay]

On Wed, Mar 25, 2009 at 6:11 PM, cpu  wrote:
>
> On windows the exe/dll separation it was meant to simplify upgrade but
> in practice the
> exe changes frequently enough that we still need to support exe
> upgrading in place.

(resending)

While the exe changing issue is annoying, and we have to handle in-use
file swapping, it's not the main issue with updates.  When you update
in place, resources can be changed, removed, etc.  So let's say that
some dll hasn't been loaded yet, but then an autoupdate happens.  Now
you trigger loading the dll, and you crash, because this kind of
forwards compatibility is never tested (nor should it be).  This can
happen with simple data files as well (although we don't have many of
those at the moment).  This is why all of the loaded code and
resources are in a versioned directory (minus dictionaries, but that's
a separate issue).

How will in-place updating work on the Mac and Linux?

Erik



>
> We always wanted to have a do nothing exe that just loads the chrome
> dll but that never
> happened, reasons: 1) the sandbox 2) breakpad 3) google_update. All
> this things are living on
> the exe.
>
> We could move to a no-dll world easier than moving to a dumb exe
> world.
>
>
> On Mar 24, 9:50 pm, Craig Schlenter  wrote:
>> On Tue, Mar 24, 2009 at 8:45 PM, Thomas Van Lenten 
>> wrote:
>>
>> [snip]
>>
>> > Linux currently builds as one executable also.  But Adam proposed we create
>> > a second executable (via hardlink?) for AppArmor as a sandbox?
>>
>> Will a hard link work for selinux btw.? I'm under the impression that
>> selinux is inode based so Fedora etc. would have to do something
>> different there.
>>
>> As for the shared library overhead that Dean mentioned, there is some
>> interesting work on linux that is mentioned 
>> herehttp://lwn.net/Articles/192624/... hopefully some of that has made it
>> into the default toolchain by now.
>>
>> Pre-linking is enabled by default on Fedora btw. ... I'm unsure of
>> other distributions.
>>
>> --Craig
> >
>

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

[chromium-dev] Re: Chromium App Executables Disk Layout

[Erik Kay]

On Sun, Mar 29, 2009 at 1:02 PM, Thomas Van Lenten
 wrote:
> Most mac apps solve this by having the app exit as part of the upgrade
> process, this way a new copy is launched w/ the new resources.

yes, but this is the problem with silent autoupdate.  We don't want to
force the user to stop what they're doing when an update starts.

Erik


> On Sun, Mar 29, 2009 at 4:40 AM, John Grabowski  wrote:
>>>
>>> How will in-place updating work on the Mac and Linux?
>>
>> To be frank, we haven't solved this problem on Mac.
>> Right now we're doing an rsync to klobber on update, which is fine for
>> pre-dogfood.  E.g. our "normal" Mac crash rate far exceeds any possible
>> crashes caused by version mismatching in the 3 auto-updates we have sent out
>> internally.
>> Although we could load all resources on startup, that ignores one critical
>> piece.  Since renderers are separate processes and are launched on-demand,
>> we would still have the problem of "old browser" talking to "new renderer".
>
> All platforms would have this problem if they don't force the apps to bounce
> as part of the upgrade process, no?
> TVL
>
>>
>> I suspect we'll need to have either a versioned scheme line Windows, or a
>> "complete upgrade" step on initial launch.
>> jrg
>>
>>
>>
>>
>> >>
>
>

--~--~-~--~~~---~--~~
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: [Extensions] New API specs: bookmarks, history, downloads

[Erik Kay]

(Resend - ugh)

On Wed, Apr 8, 2009 at 11:52 PM, Aaron Boodman  wrote:
>> Should changes to the contents of a folder trigger eventbookmarkupdated for
>> that folder? How about the folders above it?
>
> This is a meta question for the entire system. My current thinking is
> that changes you make should not fire events back at you. That just
> seems annoying. I think there should also be defined behavior in cases
> where something you do will obviously affect other nodes, and that
> those changes shouldn't be fired at you either.

Agree in principle.  The callback within the CRUD method should handle
this.  I'd argue that all of the methods should have callbacks for
this reason (as well as error handling).


> For example, moving a bookmark item within the folder obviously
> affects some of the other nodes. We should have a defined behavior for
> what happens when you do this, and we shouldn't fire events back at
> you for any of those changes.

This is a bit tricky though since we need to distinguish between the
calling extension and other extensions.  Let's say you had two
extensions that hooked into bookmarks API (one was an alternate UI and
one was a backend sync tool).


> Other stuff
> * I camel cased the events (in all the APIs) :-)

It looks like you missed history.  I just updated it.


> * I added letters to the left of all the properties in each struct of
> each API. There is 'r', 'w', and 'c', which refer to read, write, and
> create. This determines whether it is valid to include this property
> in each of these scenarios. So for example, it doesn't make sense to
> create a bookmark with a predefined API. There will be other
> validation we have to do on top of this. Like it doesn't make sense to
> change a bookmark to a folder, but this handles a good percentage.

For createDownload, don't more of the Download fields need create
rights (path, url, etc.)?


>> What kind of events does clearAllDownloads trigger? do we need a separate
>> event for this? Do we even need this in the first place?
>
> See previous point about events. I'm  about the need for
> clearAllDownloads(). Take it or leave it.

I think we need it for privacy folks.  We generally need the "clear"
APIs for all of our data so that someone can implement the extensions
that periodically delete everything.


> Other stuff:
> * I added two booleans: showInShelf and showInDownloadUI.

What's the distinction between the two?  Is the second supposed to be
download history?


> I modified the signature of the getHistory callback to make it more
> consistent with the other APIs. Instead of returning the number of
> pages, I think it is more useful to return the total number of items.
> Also I don't think we need to return the page number since the caller
> already has that.

It looks like this change didn't get committed (or got clobbered by someone).


Erik

--~--~-~--~~~---~--~~
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: Open discussions on the api-pattern

[Erik Kay]

On Wed, Apr 8, 2009 at 7:11 PM, Aaron Boodman  wrote:
>
> Argh, resending from right adress this time.
>
> On Wed, Apr 8, 2009 at 7:10 PM, Aaron Boodman  wrote:
>> Thanks for forking this. I had started a reply, then forgot to send it.
>>
>> On Wed, Apr 8, 2009 at 4:57 PM, Nick Baum  wrote:
>>> [forking the "Basic how-to steps" thread]
>>> I was rereading this, and it seems this wasn't completely resolved. I've
>>> summarized the various topics:
>>> Syntax
>>> It feels like Erik has a somewhat different syntax in mind (still service
>>> based, but a little more OO). I think the most useful thing at this point
>>> would be for Erik to give an example of what he proposes so we can compare
>>> the two.
>>
>> Yes, agree counterproposals would be easier to digest.

I'll take a swing at something.


>> From what I understand of the save() proposal, it doesn't seem to
>> provide much value. You get to say foo.save() instead of
>> chromium.foos.updateFoo(foo). I guess it's less typing, but if all the
>> other functions to get, delete, and create foo objects are on
>> chromium.foos, I don't see why it's valuable to have the update
>> function not be there. There are other advantages to
>> chorium.foos.updateFoo(). It can easily be modified to accept multiple
>> foo instances. This could be useful if we need to make sure that a
>> bunch of updates happen without repaints between.

Fair enough.  I do like the update multiple feature.



>>> Updates
>>> I like Erik's suggestion of keeping change bits, it's clever and transparent
>>> to the developer. For update events, do we only send the ID and the fields
>>> that have changed? I can see it being useful to have the whole object, but
>>> that makes figuring out the changes tricky. Maybe we send all fields in the
>>> new object, but only the changed fields in the old object. That makes it
>>> easy to find out which ones have changed, while still giving you the whole
>>> object.
>>
>> The change bit idea is interesting. I'm not sure exactly what Erik had
>> in mind for how it would work, but I can imagine a few ways:
>>
>> a) Use javascript prototypes. When you call getThing(), you get back
>> an empty object whose __proto__ is the actual object with its fields
>> filled in. But when you mutate your thing instance, your writes get
>> saved on the empty object. That way if you try to save it again, we
>> can tell the difference.

interesting idea.  I hadn't thought about this.  It's pretty simple.
Essentially copy on write semantics.


>> b) __defineSetter__. We'd intercept writes to fields and save a
>> modified bit somewhere.

This was what I had in mind.


>> I think a) is better. If we find that this is a common problem, we
>> could try it out. I'd rather get more APIs built out in the
>> dead-simple JSON style though before going deeper on the API
>> infrastructure.

I agree that a) is nicer.  It has a number of nice advantages to it.

I'm OK about delaying implementation of this approach so that we can
get the APIs nailed down, but I don't think we should decide whether
or not we do it based on whether it's an especially common problem.
What I'm arguing isn't that it will happen all of the time (it
requires multiple updaters to really be a problem), but rather that
when it does happen, it will be a subtle and annoying bug to track
down, and the way that devs will need to fix it will be worse.

Erik

--~--~-~--~~~---~--~~
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: FilePath::Extension() and dots

[Erik Kay]

Avi,

It took me a while to page this one back in, but my my vague
recollection is that there were some odd bugs in the old file_util
with adding and removing extensions that made it behave in a way that
wasn't consistent.  I'm not sure this is all right, so don't hold me
to it.  I think it was due to some odd examples involving multiple
dots in the middle of filenames.  The assertion was that you should be
able to remove an extension from a path and add it back in and the
path should be the same as the one you started with.  If you take a
file like "foo..jpg" and then remove and add the extension to it, the
old code would mess it up.  Then there was an issue of what should
happen if you added the extension "jpg" to "foo.".  I do remember Mark
and I going back and forth about the on this and me finding the
details more irritating than I was expecting. ;-)

I could care less if you'd like to change this the way you described
if you can make it work.  Just make sure you get Mark as the reviewer
to help find all of the goofy edge cases. :-)

Erik


On Fri, Apr 17, 2009 at 1:27 PM, Avi Drissman  wrote:
> Erik—
>
> I don't understand why in http://codereview.chromium.org/17243 you defined
> Extension() to have a leading dot. It's easier to add a dot than take one
> off, and I don't understand why you insist on the equivalence you describe.
> How is ensuring that you could append the string values of the file and its
> extension together useful?
>
> Avi
>

--~--~-~--~~~---~--~~
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: Remove svn from deps/third_party?

[Erik Kay]

I think this is still an issue.  We also have a similar issue with the
python in depot_tools vs. the one in third_party vs. the one in cygwin
and local system for mac and linux (different versions and different
built-in modules for each of them).  If we're going to depend on
depot_tools versions, then we need to have a way to explicitly
reference those versions from our scripts.  The problem is that since
depot_tools are installed independently, there's no current way to get
to where they're installed from the chromium tree.

Possible solutions:
- require another environment variable when installing depot_tools
(DEPOT_TOOLS_PATH)
- add a script in the depot_tools bin directory that simply emits the
path to the bin directory
- add a script to chromium_dev that searches your PATH for the
location of gcl/gclient, etc.

I'm not really a fan of any of these.  Anybody have another suggestion?

Erik


On Wed, Apr 22, 2009 at 11:13 PM, Darin Fisher  wrote:
> IIRC, some people (peter?) have had /usr/bin/svn on their path ahead of
> depot_tools, since they don't want our svn interfering with their webkit
> checkout.  this used to work if you always accessed our svn by calling gvn
> instead (yes, i meant gvn).  i believe that gcl, like gvn, will also pass
> through to svn, but when i try it now, i get a strange error.  so, perhaps
> no one is counting on this anymore.
> -darin
>
> On Wed, Apr 22, 2009 at 9:58 PM, Mark Larson (Google) 
> wrote:
>>
>> I filed http://bugs.chromium.org/10872 for this...
>>
>> From src/chrome/tools/build/win/version.bat:
>> :: Determine the current repository revision number
>> set PATH=%~dp0..\..\..\..\third_party\svn;%PATH%
>> svn.exe info | grep.exe "Revision:" | cut -d" " -f2- | sed "s/\(.*\)/set
>> LASTCHANGE=\1/" >> %VarsBat%
>> call %VarsBat%
>> This calls trunk/deps/third-party/svn/svn.exe, which is not the same
>> version as svn in depot_tools.
>> Result?
>> Generating version template file
>> svn: This client is too old to work with working copy '.'.  You need
>> to get a newer Subversion client, or to downgrade this working copy.
>> See http://subversion.tigris.org/faq.html#working-copy-format-change
>> for details.
>>
>>
>> My preference would be to remove svn from the tree. We require you to use
>> gclient to pull the tree, so you already have svn in one place. If it's
>> not
>> in your path, I think it's OK for this step to fail (modify the bat file
>> to
>> point to your copy of svn).
>> For most users and the buildbots, svn will be in the path.
>> So just calling 'svn' means version.bat will use the same version that
>> gclient used to check out the files.
>> Any objections to
>> 1. Pulling deps/third_party/svn out of the tree?
>> 2. Changing version.bat to just call 'svn' (expecting it in the path)?
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: WebContents is dead, long live TabContents!

[Erik Kay]

woot!

On Thu, Apr 23, 2009 at 11:02 PM, Brett Wilson  wrote:
>
> I just moved the remaining methods from WebContents to TabContents. I
> kept the methods and data members the same, just merged the classes,
> so it should be easy to find what you're looking for (or to resolve
> conflicts if you have local changes to web_contents.cc). Hopefully
> this will make the complexity in this area much more manageable.
>
> We still have a shell class called WebContents (derived from
> TabContents) and references to it, which are temporary so I don't have
> to immediately change all references to it. It will hopefully soon go
> away.
>
>
> FAQ: Why did we do this?
>
> Chromium 1 used a variety of specialized tab contents types which we
> wrote native interfaces for. This included the history and downloads
> page. TabContents was the base class providing shared functionality
> and an external API, and there were a variety of subclasses for the
> different tab types. WebContents was the TabContents specialization
> for web pages.
>
> There were several problems with this. The original idea is that our
> native UI would be more awesome than a web page could ever be. But it
> turned out to be teh suck because a variety of things didn't work
> (find in page, printing, selection) and because we didn't end up doing
> anything fancy in there anyway. With native UI, we would have to write
> it again for every platform, which nobody was excited about doing.
> There were also very difficult bugs associated with switching tab
> contents types. For example, in Chromium 1, if you go to the history
> page, navigate to a regular web page, go back, then navigate to a
> different regular web page, you would see a flash of the first web
> page during the second transition. This was the tab contents types
> being switched between a HistoryContents and a previously-used
> WebContents.
>
> So now we only display web pages inside tabs. This makes the switching
> problem go away. Glen rewrote history and downloads we be special web
> pages with additional permissions, and I did a whole heckuva lof of
> refactoring to delete all the old TabContents switching. We still swap
> RenderViewHosts inside the TabContents when we need to switch
> processes.
>
> Brett
>
> >
>

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

[chromium-dev] Re: [extensions] Proposed changes to PageActions API

[Erik Kay]

On Wed, Apr 22, 2009 at 4:38 PM, Aaron Boodman  wrote:

>
> So Finnur is looking at the Page Actions API
> (
> http://dev.chromium.org/developers/design-documents/extensions/page-actions-api
> ).
> Right now, the proposed API for creating one of these bad boys is:
>
> create({string name, [string javascript], [string faviconUrl], [bool
> executeInPage]}, [function callback(PageAction new)])
>
>
> I would like to change two main things about this:
>
> a) Usually page actions are associated with a tab. When you switch
> tabs, they should automatically be switched. The extension developer
> shouldn't have to manually manage that. There are also page actions
> which apply to every page, but we could support that separately.
>
> b) I would like the callback to be in the form of a function, not a
> string of JavaScript. Functions are better because they can have
> closures that allow you to keep references to local state, and are
> just more JavaScripty in general.
>
>
> So I would change it to something like:
>
> create({string name, int tabId, string iconUrl, function onExecute()},
> [function callback(PageAction new)])
>
> Note that the second callback is just basically telling you "yes, it
> was registered!". There would eventually be a third optional callback
> for errors ("no, that tab id doesn't even exist!").
>
>
> Thoughts on these changes? It would require some changes to enable
> ExtensionFunctions to have lifetimes beyond the stack frame, but I
> think that is a good thing because we want to support this style of
> API for other things in the future, like navigation or history
> searches.
>

(sorry a bit late with this reply)

I think these changes are an improvement, however it does feel a bit weird
for it to be tab-based rather than URL based.  With only a tab id, I think
there will be some races.  So if an extension script realizes that this page
is special and should have a PageAction created, it calls the API, but as it
does that, the tab navigates.  Since all the API has is a tab id, there's no
way for the browser to know whether the request is still valid or not.
 We'll likely continue to need a tab id as well since you could have
multiple tabs open to the same URL.

Erik

--~--~-~--~~~---~--~~
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: [extensions] API sprucing

[Erik Kay]

On Wed, Apr 22, 2009 at 3:35 PM, Aaron Boodman  wrote:

>
> A few of us extension guys were talking offline Monday about how now
> that we've all had a chance to implement some APIs, we are probably
> better positioned to come to consensus on the remaining style points.
>
> I went through the existing three browser APIs (windows, tabs, and
> bookmarks --
> http://dev.chromium.org/developers/design-documents/extensions)
> and tried to identify all the places where they differ. I've also put
> my vote for whether and how they should be aligned.
>
> Let me know what you think...


(Sorry for the slow response)


Naming:
> - We have chromium.windows.getWindows(),
> chromium.windows.createWindow(), etc and chromium.bookmarks.get(),
> chromium.bookmarks.create().
> - My vote: I like chromium.bookmarks.create(). The downside to this is
> that we can never put more than one primary object in a namespace, but
> I'm OK with that. We should also change the event names to be like
> onMove instead of onTabMoved.


love it


Querying:
> - We have getWindows(WindowQuery), getTabs(TabQuery), and
> bookmarks.get(ids)+bookmarks.search(text).
> - My vote: It doesn't look to me like there is a general solution
> here. Searching for windows and tabs using multiple criterion
> (WindowQuery, TabQuery) feels pretty hard to use to me. Doing so in
> history feels more natural. Doing so for bookmarks is kinda in
> between.


Agree.  I don't think this should be a generalized concept.  Some APIs will
have it naturally.



> I feel like for these we might want to do things that are
> more optimized for the module in question. For example
> windows.getTop(), windows.getCurrent(), bookmarks.getTree(), etc. I'll
> start separate conversations for these, though.


I personally like these specific APIs.  They're much more clear.




> Updating:
> - We have bookmarks.setTitle(id, title) and windows.updateWindow({id,
> top, left, width, height, ...})
> - My vote. I like the single update method for objects that naturally
> have lots of fields you can update. For bookmarks, for example, you
> will eventually be able to update both url and title. It seems natural
> to me to be able to do both at the same time. It also lends itself
> well to batch operations, should we ever want to do that.


I like how this approach feels, and I think we should do it.  That said, I
have a few concerns that I think we need to keep an eye on.

What if there are some properties that are heavier weight and potentially
have more specific notification and error conditions with you try to change
them.  The side effect of grouping changes to multiple fields with different
update semantics is that you'll get a weird mishmash.

For example, let's say you're updating three properties in tab, and two of
them could actually fail according to the underlying browser API for some
reason.  This means that updates might have partially succeeded (I doubt we
want to try to implement transactions), and you might have multiple
independent error messages.




> I also
> really like Rafael's idea to separate out the id parameter, so it
> would look like windows.updateWindow(id, {top, left, width, height,
> ...}). This elegantly solves the problem of accidentally using an old
> object and clobbering more recent state. If we do this, probably we
> should also split out id in the move apis, to be consistent.


Would the API be: {id, window: {top, left, ...} }?  Or would they be
separate params as you have it above?  I think I like the separate params in
this case, but it does lead to some odd work when we support batching (you
have to construct two separate arrays with matching indices).



Update Event:
> - Sometimes we pass old and new objects according to the docs, but I
> think it will be difficult to actually do that.
> - My vote: onUpdate(int id, {properties and values that changed}). The
> second param would be an object containing the names of the properties
> that changed and their new values.


This feels reasonable to me.


Move Event:
> - We have onBookmarkOrderChanged(int folderid, int[] newchildids) and
> onTabMoved(int tabid, int windowid, int fromindex, int toindex)
> - My vote: I think we should go with onTabMoved(int tabid, int
> newindex). In other places we have assumed that the client is keeping
> state, so this should be the same. We'd still send only one move event
> and assume the client either understands the implied shuffling, or
> will refetch the entire list.


I agree with this in principle, but this is one of those places where we'll
likely have to reflect the capabilities of the underlying API.  For example,
BookmarkObserver has two different notifications:

BookmarkNodeMoved - this is following what you're proposing (it doesn't call
for each node that was moved as a side effect, just the original)
BookmarkNodeChildrenReordered - this is called if there was a bulk resort of
the children of a node, once for the parent, not for each node

So in this case, if

[chromium-dev] Re: [extensions] Proposed changes to PageActions API

[Erik Kay]

(repost - stupid gmail)

On Mon, Apr 27, 2009 at 10:20 AM, Aaron Boodman  wrote:

> On Mon, Apr 27, 2009 at 9:26 AM, Erik Kay  wrote:
> > I think these changes are an improvement, however it does feel a bit
> weird
> > for it to be tab-based rather than URL based.  With only a tab id, I
> think
> > there will be some races.  So if an extension script realizes that this
> page
> > is special and should have a PageAction created, it calls the API, but as
> it
> > does that, the tab navigates.  Since all the API has is a tab id, there's
> no
> > way for the browser to know whether the request is still valid or not.
> >  We'll likely continue to need a tab id as well since you could have
> > multiple tabs open to the same URL.
>
> Wow, this is a great point, thanks for bringing it up. It seems like a
> better solution would be to introduce the concept of history or page
> or something. That is really the object you want to point to. Each tab
> would have a history or page ID, and this is what you would send into
> this API.


What does using a page ID buy us over using an URL directly?




> Separately, I was thinking over the weekend that we could simplify
> this API and consolidate the temporary and permanent versions like
> this:
>
> // Manifest
> "page_actions": [
>  {
>"id": "foo",  // Required. Chosen by the developer,
> namespaced/unique by extension
>"title": "Add to delicious...",  // Required.
>"type": "temporary"  // Optional, "temporary" or "permanent".
> Defaults to "permanent".
>  }
> ]
>

I like this way of pre-defining the page actions via the manifest.  As you
said, it simplifies the API, but I think it also gives us more opportunities
for caching, and will likely improve performance of the feature in general.
 It appears you're missing the icon though.  I'm not sure you need the
'type' field in the pre-definition though since the API calls will provide
that implicitly.



> // API
> event chromium.pageActions.onExecute(int tabID, string type) // or
> history/pageID?


I can't think of an example where you'd need 'type' passed back to you, but
you do need the pageActionId.

If we use a pageID here, then how is that used by the developer?  Do they
need to make a round-trip to look up the URL associated with it?  Or are
they supposed to keep a local map of recent pageID to URL?




> void chromium.pageActions.enableTemporary(int tabID)  // or history/pageID?
>
> I think this is all the API we would need for a v1.



Yep.

Erik

--~--~-~--~~~---~--~~
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: [extensions] API sprucing

[Erik Kay]

On Mon, Apr 27, 2009 at 10:26 AM, Aaron Boodman  wrote:

> On Mon, Apr 27, 2009 at 10:00 AM, Erik Kay  wrote:
> > On Wed, Apr 22, 2009 at 3:35 PM, Aaron Boodman  wrote:
> >> Updating:
> >> - We have bookmarks.setTitle(id, title) and windows.updateWindow({id,
> >> top, left, width, height, ...})
> >> - My vote. I like the single update method for objects that naturally
> >> have lots of fields you can update. For bookmarks, for example, you
> >> will eventually be able to update both url and title. It seems natural
> >> to me to be able to do both at the same time. It also lends itself
> >> well to batch operations, should we ever want to do that.
> >
> > I like how this approach feels, and I think we should do it.  That said,
> I
> > have a few concerns that I think we need to keep an eye on.
> > What if there are some properties that are heavier weight and potentially
> > have more specific notification and error conditions with you try to
> change
> > them.  The side effect of grouping changes to multiple fields with
> different
> > update semantics is that you'll get a weird mishmash.
> > For example, let's say you're updating three properties in tab, and two
> of
> > them could actually fail according to the underlying browser API for some
> > reason.  This means that updates might have partially succeeded (I doubt
> we
> > want to try to implement transactions), and you might have multiple
> > independent error messages.
>
> Right. My instinct was that we would have to pre-validate all the
> changes. I don't think this is too hard for the cases I can imagine,
> since we're essentially single threaded by the time we get to the
> place we need to make the changes. But maybe there are some
> difficulties I'm not considering.


I don't think we should hold up the change for this, but I don't think we
can externally validate.  If the underlying setter can fail, then it seems
unlikely that we can validate in exactly the same way as it can.  Aside from
duplicating code, some failures could be externalities (filesystem issues
for example).  Again, let's move forward.  If we run into anything like
this, I think the fix will be simply to move that field out of the legal
fields for the general update method.


>> Question: Do we need to send fromIndex?
> >
> > 'need' is a strong word.  Does it hurt to do so?  I could imagine that
> it's
> > useful for maintaining state to minimize the amount of re-shuffling you
> need
> > to do.  Incidentally, doesn't this notification also need a fromWindow?
>
> Yeah, I'm just trying to figure out where to draw the line on how much
> preexisting state to send. I don't have a strong opinion. As for
> fromWindow, no. The underlying support distinguishes between moving
> between windows and moving within a tab, and we decided that we had to
> expose this.


OK.  In the bookmark case, the fromParent will need to be in the
notification.  Unfortunately, I guess this shows how we can't generalize /
standardize the APIs too much across different systems.

Erik

--~--~-~--~~~---~--~~
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: Changes to FilePath?

[Erik Kay]

(resend - arg)

On Tue, Apr 28, 2009 at 2:47 PM, Greg Spencer  wrote:

> On Tue, Apr 28, 2009 at 2:41 PM, Amanda Walker wrote:
>
>>
>> On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer 
>> wrote:
>> > 1) I'd like to add some explicit routines for converting to/from UTF8
>> and
>> > UTF16.  While it's nice (and important) that FilePath uses the
>> platform's
>> > native string, we've found that many third party libraries have made
>> other
>> > assumptions, where they always expect UTF8 (char) or UTF16 (wchar_t)
>> paths
>> > regardless of platform, and converting a FilePath to and from those
>> forms is
>> > a platform-dependent exercise which should be centralized into the class
>> > (i.e. adding "ToUTF8" and "ToWide" functions to the class, and explicit
>> > constructors that take each type).
>>
>> One thing many of us have found, across multiple projects, is that
>> wchar_t is fraught with complication as soon as more than one platform
>> is involved. "wchar_t == UTF16" is a Windowsism (gcc defaults to 4
>> bytes, for example, and L"mumble" gets stored in UCS-4, not UTF-16).
>> Chrome started with more or less what you are suggesting, and we moved
>> off of it after much pain.
>
>
> I understand those issues quite well (but I probably should call the
> conversion method ToUTF16, now that you mention it).  And char* isn't
> necessarily UTF8 on all platforms either.
>
> OK, so what's the currently recommended path for converting to UTF16 or
> UTF8 from a FilePath?
>

The biggest problem with this change is that it's not possible to do this
conversion on Linux in a safe way.  In Linux, there is no charset defined by
the filesystem.  Each filename is just a blob of bytes.  Apps are supposed
to respect an environment variable, but since this environment variable
could change over time and be different from user to user, there's no
reliable way to know what the charset is, so you can't convert from a
FilePath on Linux to UTF8 or UTF16 unless you were the one who created the
path to begin with.

Erik

--~--~-~--~~~---~--~~
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: Changes to FilePath?

[Erik Kay]

On Tue, Apr 28, 2009 at 3:19 PM, Greg Spencer  wrote:

> On Tue, Apr 28, 2009 at 3:11 PM, Erik Kay  wrote:
>
>> The biggest problem with this change is that it's not possible to do this
>> conversion on Linux in a safe way.  In Linux, there is no charset defined by
>> the filesystem.  Each filename is just a blob of bytes.  Apps are supposed
>> to respect an environment variable, but since this environment variable
>> could change over time and be different from user to user, there's no
>> reliable way to know what the charset is, so you can't convert from a
>> FilePath on Linux to UTF8 or UTF16 unless you were the one who created the
>> path to begin with.
>>
>
> But that's exactly the point.  FilePath is the class that created the path
> to begin with.  So it can know what the LC_*/LANG variables were was when it
> was created, and do the right conversion when you ask the FilePath to
> convert to UTF16.  Also, if the developer calls something called
> FilePath::CreateFromUTF8, then it can know it was supposed to be UTF8 and
> remember that.
>


If you created it yourself, that's fine.  FilePaths aren't always created
manually by users.  They often are populated from system APIs where you
can't know.  See file_util* for some examples.  So the problem is that if
you add this API, people will mistakenly use the conversion functions when
they can't be safe.  I agree it sucks.  I just don't know of a reasonable
solution.

Erik

--~--~-~--~~~---~--~~
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: Today we run zero LayoutTests in chrome

[Erik Kay]

If anyone is interested in doing this extension work, come find myself or
Aaron.  It's getting easier to add extension APIs.  We'd be happy to show
you how.
Erik

On Thu, Apr 30, 2009 at 11:37 AM, Darin Fisher  wrote:

> I think if we should definitely make it possible to run layout tests in
> Chrome.  However, supporting all of layout test controller will be a
> considerable amount of work, and I think we always want to maintain the
> simpler test_shell environment for exercising webkit divorced from the rest
> of chrome (to help minimize flakiness).
> Two ways forward: 1) build the layout test controller as an extension, 2)
> build a new multi-process test_shell.  I think the first choice would be
> best if we can pull it off.
>
> -Darin
>
>
> On Wed, Apr 29, 2009 at 2:05 PM, Mike Belshe  wrote:
>
>> We're still using the test-shell to run the LayoutTests.I just fixed a
>> bug, wrote a layout test, and then realized how dumb I was because the code
>> I was testing was only in Chrome, and not in the test_shell.
>>
>> I think we're accumulating a lot of code that is chrome specific, but
>> which could effect rendering and layout.  In my case, I'm working on v8
>> extensions that have been put into the browser, but there is tons of code
>> which differs between chrome and test shell.  Not having layout tests for
>> chrome itself is making me a bit nervous.
>>
>> 2 Questions:
>>
>> 1) Any plans already underway to run chrome rather than test_shell through
>> the Layout Tests?
>>
>> 2) Should we create those plans :-)
>>
>> Cheers,
>> Mike
>>
>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Today we run zero LayoutTests in chrome

[Erik Kay]

In retrospect, this would probably be better as a V8 extension behind a
command-line flag.  That's probably what Darin meant to begin with. ;-)
Erik


On Thu, Apr 30, 2009 at 1:32 PM, Erik Kay  wrote:

> If anyone is interested in doing this extension work, come find myself or
> Aaron.  It's getting easier to add extension APIs.  We'd be happy to show
> you how.
> Erik
>
> On Thu, Apr 30, 2009 at 11:37 AM, Darin Fisher  wrote:
>
>> I think if we should definitely make it possible to run layout tests in
>> Chrome.  However, supporting all of layout test controller will be a
>> considerable amount of work, and I think we always want to maintain the
>> simpler test_shell environment for exercising webkit divorced from the rest
>> of chrome (to help minimize flakiness).
>> Two ways forward: 1) build the layout test controller as an extension, 2)
>> build a new multi-process test_shell.  I think the first choice would be
>> best if we can pull it off.
>>
>> -Darin
>>
>>
>> On Wed, Apr 29, 2009 at 2:05 PM, Mike Belshe  wrote:
>>
>>> We're still using the test-shell to run the LayoutTests.I just fixed
>>> a bug, wrote a layout test, and then realized how dumb I was because the
>>> code I was testing was only in Chrome, and not in the test_shell.
>>>
>>> I think we're accumulating a lot of code that is chrome specific, but
>>> which could effect rendering and layout.  In my case, I'm working on v8
>>> extensions that have been put into the browser, but there is tons of code
>>> which differs between chrome and test shell.  Not having layout tests for
>>> chrome itself is making me a bit nervous.
>>>
>>> 2 Questions:
>>>
>>> 1) Any plans already underway to run chrome rather than test_shell
>>> through the Layout Tests?
>>>
>>> 2) Should we create those plans :-)
>>>
>>> Cheers,
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Unpacking Extensions and the Sandbox

[Erik Kay]

On Fri, May 1, 2009 at 10:19 AM, Aaron Boodman  wrote:

>
> Right now, we are unpacking extensions in the browser process. This
> basically consists of unzipping the package into a directory structure
> and parsing a JSON manifest.
>
> Both of these things feel like things we should not be doing in the
> browser. Additionally, extensions can contains PNG images that will be
> used in the browser process, for example, for themes. Decoding these
> images also shouldn't be done in the browser process.
>
> I'm looking for advice on how best to sandbox all of this.
>
>
> Here are my current thoughts:
>
> To me, the conceptually simplest solution would be to do all of the
> unpacking in whichever renderer happened to be the one that the user
> clicked "Install" in. In the case of autoupdate, we'd use the
> extension's own process, which are also just renderers.
>
> The browser would tell the renderer about the zip file that needed to
> be unpacked, and the renderer would unzip it, parse it, and decode
> images into bitmaps, which would all be shipped back to the browser.


For normal extensions where images are always just rendered in HTML, we
don't need to do anything special with the images.  They'll always be read
and rendered in the renderer.

The issue with images is with themes, since they're displayed by the browser
process.  I'm not sure I followed your flow with this.  At install time, you
ship decoded images over to the browser process so it can display them.
 Does it need to re-encode the images itself for storage to disk?  Or is it
going to need to ask the renderer to decode each time?



The immediate practical problem with this approach is that the zip
> library we use works in terms of files, not memory. This could be
> changed, but I am not sure how good an idea that is since packages
> could be large. Average Firefox extensions are ~300k, but we are
> planning for a max of 1M.


I think the max was actually 10M.  Perhaps we'd need to implement it as a
streaming API.  Isn't that kind of logic already in place for audio/video?



> Maybe the renderers could be allowed to have a temporary directory
> they are allowed to do work in? The browser could put the zip file
> there and they could be unpacked in place?


Perhaps the renderer could just have read access to the zip file, and then
pass the files it's unpacking one-by-one up to the browser.  If the zip has
any single large files, that gets expensive though.


Another orthogonal idea I have heard kicked around is a separate
> "utility" process. This seems like it would have the same problems
> with how to get the data in and out, though, and I don't see why
> bother having a new process when we already have a renderer we could
> use.
>

There have been other cases people have brought up where the work being
requested wasn't associated with a renderer (PAC parsing for example).  With
the extension example, I think it could be associated with a renderer, but
in some cases, we'd be opening up a new one (say you double click on a crx
file).

Erik

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

[chromium-dev] Re: adding a menu from an extension?

[Erik Kay]

On Fri, May 15, 2009 at 6:58 AM, Mark Smith  wrote:

>
> I am experimenting with extension development.  It is exciting to see
> quick progress is this area.
>
> I didn't see anything in the design documents about allowing
> extensions to add menus (like the Page and Tools menu).  Is that on
> your radar?
>
> Also, are you planning to allow extensions to add items to the browser
> context menu?


Yes, interacting with menus is on our radar.  I notice that it's missing
from the API wishlist however (not an intentional omission).  Even with a
minimal amount of UI chrome in Chrome, there are a surprising amount of
surface areas to consider extending (toolbar, omnibox, download shelf, main
menus, context menus, web pages, chrome: pages, etc.).  Since we're adding
support for these things with specific, narrow APIs, expect them to come
slowly and not all at once.

Erik

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

[chromium-dev] Re: adding a menu from an extension?

[Erik Kay]

On Sat, May 16, 2009 at 2:13 AM, Michael  wrote:

>
> I was wondering the same myself but I think the cross-platform (and
> toolkit) nature of chrome will make this difficult to implement?


Not really.  The fact that we have to build up specific extension APIs and
UIs for this is what takes time (more on this below).



> It would certainly make sense for some types of extensions. On the other
> hand, many extension authors seem to abuse the extension system
> (*cough* Firefox *cough*) and add pointless menu/toolbar/statusbar
> items. Getting the balance right will be hard...


Yes.  This is one of the key issues we wish to address.  We want to make it
easy for the developer to do the right thing, and give the user power to
change things when they don't.  We can't prevent developers from writing bad
extensions, but user control and social mechanisms should hopefully limit
the damage.



The current solution of providing a "tool strip" feels wrong to me
> btw. Try opening a Chrome window with bookmark bar and toolstrip open
> and then start a download which adds another bar... this is starting
> to remind me of those funny IE screenshots with all those toolbars.
>
> I would love to be able to (optinally) move extension UIs to the
> bookmark toolbar for example. The GMail checker would be really cool
> sitting left to "Other bookmarks".


Our initial implementation put the toolstrip UI inside of the bookmarks bar.
 Perhaps it would be cool for the ultra-minimalist to add an extension as a
single button in the main toolbar area next to the OmniBox, so they didn't
even need the bookmarks bar to be visible to use an extension.  For people
who use their extension to do something more heavyweight, perhaps they'd
like to show their extension in a side bar and take up a lot of real estate.

Ideally, the UI surface area that the extension exposes itself in should be
under user control.  Rather than the extension automatically filling each
and every nook and cranny of the browser with its UI, the idea is that we
let the user pick where to dock the extension, and how much space it gets in
that location.  The extension UI should be flexible enough to adapt to the
limitations that the user puts on it.  In most cases, we want the UI
available to extensions to be a limited and valuable resource.  If they try
to take up too much of it, the user will have the power to take it away from
them.

Of course, this will all take time to appear.  Keep an eye out as we roll
out these features.  Trust us that we have no desire to replicate the
zillions of toolbars approach that has happened to other browsers.  One of
our first principles is that Chrome with extensions should still look like
Chrome. ;-)

Erik

--~--~-~--~~~---~--~~
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: [extensions] Moved all tasks to issue tracker

[Erik Kay]

Thanks for doing this.  Very useful.
Erik


On Mon, May 18, 2009 at 9:38 AM, Aaron Boodman  wrote:

>
> FYI, I've moved all the tasks I'm aware of for the extensions project
> to the normal issue tracker. Here's a nice query:
>
>
> http://code.google.com/p/chromium/issues/list?q=Area:extensions&sort=pri+size&colspec=ID%20Pri%20Area%20Status%20Summary%20Owner%20Size
>
> Here is how I filled out the fields:
>
> P1: Some other team is blocked on this, or a high frequency crash that
> is already showing up on crash reports
> P2: Everything besides P1 that we want to do for a v1 of extensions
> P3: Other things
>
> Size-Small: 1 day
> Size-Medium: Between 1 day and 1 week
> Size-Large: More than 1 week
>
> And I also assigned owners in cases where people were obviously the
> one to do the work, or they had already started.
>
>
> - 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: Default.dll and toolstrips

[Erik Kay]

The theming and extensions code is undergoing a number of changes right now,
but yes, you should expect that these pieces will be part of themes.
Erik


On Mon, May 18, 2009 at 10:39 AM, Meok  wrote:

>
> Hi, the background for the toolstrips / bookmark bar isn't included in
> default.dll theme file. As a result, when you create themes, the
> bookmarks bar remains blue. I'm guessing the toolstrip has a .css file
> somewhere and i'm not sure about the bookmarks bar.
>
> Are there any plans to merge all of these backgrounds etc. into the
> default.dll file for the benefit of the people making themes?
> >
>

--~--~-~--~~~---~--~~
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: [extensions] Text translate API proposal

[Erik Kay]

Similar to the translate, this feature could be used to support sites that
use non-standard character set / font combinations (some indic websites
depend on downloadable fonts and custom character sets).

Also, if the API allowed styling of the text as opposed to just replacing
it, then I could imagine that it could be used for interesting markup /
highlighting (highlighting searched words, marking up grammar errors,
auto-likifying, etc.).  Perhaps this would defeat part of the point of this
approach to an API.
Erik


On Mon, Jun 1, 2009 at 11:51 AM, Aaron Boodman  wrote:

>
> On Mon, Jun 1, 2009 at 11:46 AM, Evan Martin  wrote:
> > This feels kinda one-off-y to me.  Is there any use of this *other*
> > than running through Google Translate?  I worry about adding a lot of
> > API surface area for little gain.
>
> That is one of the things I was concerned about too. I thought about
> factoring out the code that finds the blocks. There are other use
> cases near there. But for actually modifying the text nodes -- no, I
> can't think of any other use cases.
>
> - 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: DLLs missing and DCHECKs in recent builds

[Erik Kay]

I haven't seen anyone else mention this, but I also had to manually
"rebuild" tcmalloc for my build to succeed, otherwise I'd get:
LINK : fatal error LNK1181: cannot open input file
'E:\src\cr\src\chrome\Debug\obj\tcmalloc\libcmt.lib'

Erik


On Wed, Jun 3, 2009 at 10:23 AM, Glen Murphy  wrote:

>
> To add to this - someone else running into this mentioned that they
> needed to also build chrome_resources to get theme_dll to build.
>
> You'll also need to manually build crash_service if you're building
> any of the tests.
>
> On Tue, Jun 2, 2009 at 9:19 PM, Glen Murphy wrote:
> > I thought it was just me, but I just heard from someone else who hit
> > this. It appears that a recent change causes a few things to not get
> > built when you do a clean build, leading to DCHECKs when you try to
> > run. I believe the GYP team is working on a fix, but in the meantime
> > you can work around it by manually building chrome/theme_dll and
> > chrome/app/locales/en-US.
> >
> > xox,
> > Glen
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Are we now using Visual Studio 2008?

[Erik Kay]

It sounds like we need a vs2008 buildbot.
Erik


On Thu, Jun 4, 2009 at 10:51 AM, Mike Belshe  wrote:

> Can we change this so that you have to opt-in to vs2008?
> I have vs2008 on my system, but I never really wanted to use it for chrome.
>  It's just that gyp automatically switched me to it.
>
> The vs2008 build seems to be subject to many more errors than the vs2005
> system.  I suspect this is due to low developer use and that it's not what
> we run on the bbots, right?  Over the past few months, I've probably lost
> more than a week of developer time due to vs2008 problems.  I don't want
> other engineers to have to go through that unless they opt-in.
>
> Mike
>
>
> On Wed, May 27, 2009 at 1:49 PM, Sverrir Á. Berg wrote:
>
>> GYP detects if you have VS2008 installed and defaults to
>> that over 2005.  To force 2005 set this in your environment before building:
>> GYP_MSVS_VERSION=2005
>>
>> If you don't have 2008 installed:
>> * close visual studio (important)
>> * revert changes to build files you might have locally
>> * gclient sync
>> * gclient runhooks --force
>> * build again
>>
>> Sverrir
>>
>>
>>
>> On Wed, May 27, 2009 at 4:43 PM, Peter Kasting wrote:
>>
>>> On Wed, May 27, 2009 at 1:36 PM, Book'em Dano wrote:
>>>
 Did I miss the announcement that we were going to VS
 2008?
>>>
>>>
>>> Not that I know of.  Perhaps your local copy is modified somehow?
>>>
>>> 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: 2 problems with extension development

[Erik Kay]

Yeah, sorry about that.  The inspector is currently broken in the dev
release.  It's fixed in the tip of tree and should be out in the next
release (likely this week).
Erik


On Wed, Jun 10, 2009 at 2:00 PM, Nebojša Ćirić  wrote:

> I tried that too, but as I said, tools are broken for me. JavaScript
> console window looks badly rendered (has frame, you can click on a button
> that shows command line, but that's about it). See bug
> http://code.google.com/p/chromium/issues/detail?id=7800
>
> Cira
>
>
> On Wed, Jun 10, 2009 at 1:21 AM, Guria  wrote:
>
>>
>> Have you tried to right click on toolstrip.
>> As I know that should bring up devtools running in yurs toolstrip
>> envionronment.
>>
>> On 10 июн, 03:53, Nebojša Ćirić  wrote:
>> > I am on Vista 64, Chrome dev ver. 3.0.183.1
>> >
>> > I am building simple continuous build extension (fetches last status
>> > from the server, as text file, parses result, and sets toolstrip
>> > button).
>> >
>> > Problems:
>> >
>> > 1. My javascript console is blank. Even simple javascript: console.log
>> > (1); doesn't do anything. In fact there was a bug filed, but it seems
>> > it was closed in April (I can look up exact bug number).
>> >
>> > 2. In my background page when I iterate over views I get back 1
>> > element, backend page itself. Code looks like:
>> >
>> > ...
>> >   var views = chrome.self.getViews();
>> >   for (var i in views) {
>> >   if (views[i].toggleStripStatus)
>> > views[i].toggleStripStatus(status);
>> >   }
>> > ...
>> >
>> > It's pretty hard to debug this (since console is out, and this is
>> > backend page so alerts don't work), but I managed to inspect views
>> > variable, and it has only 1 element, and that element is backend page
>> > itself.
>>
>>
>>
>
> >
>

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

[chromium-dev] Re: Naming things _views

[Erik Kay]

So the class name is the same too in this case?  (InfoBubble and InfoBubble)
Erik


On Thu, Jun 11, 2009 at 10:46 AM, Ben Goodger (Google) wrote:

>
> sure why not... the _platform suffix is supposed to be for files in a
> location where multiple platfomrs are built.
>
> -Ben
>
> On Thu, Jun 11, 2009 at 2:47 AM, Dean McNamee wrote:
> > Does this mean we can do something similar for GTK?
> >
> > It feels a bit unfair that we have to name everything
> > browser/gtk/blah_gtk.cc  and BrowserToolbarGtk, etc, while views gets
> > the short name.  For example
> >
> > views: views/info_bubble.cc and class name InfoBubble
> > gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk
> >
> > On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)
> wrote:
> >>
> >> If you're porting a file in the browser/ directory and going to be
> >> renaming a file foo _views.cc/h, consider just moving the file into
> >> browser/views and not renaming it.
> >>
> >> -Ben
> >>
> >> >>
> >>
> >
>
> >
>

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

[chromium-dev] Re: Exclude Tab Bar Area

[Erik Kay]

There's no easy way to do this today.
Erik


On Thu, Jun 11, 2009 at 12:52 PM, Peter  wrote:

>
> Is this possible in chrome currently (perhaps some theme hack would
> allow this??)  or through and extension?
>
> I want to exclude the tab bar from using some space near the window
> controls in the upper left corner of the window.
> This space is permanently occupied by winamp on my system (set to
> always on top).  So If I have tabs spanning the title bar, some are
> blocked by winamp.
>
> see this image (picasaweb):
>
> http://lh3.ggpht.com/_WL2DyBcS1cw/SjFVU9X6-CI/AKs/EGtobJR828k/s800/Capture.PNG
>
> please advise.
> >
>

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

[chromium-dev] Re: sandboxing external libraries (like Growl)

[Erik Kay]

(resending from the right address)

John,
You definitely want to be careful with the image download.  Since
you'll be handing it off to another (not sandboxed) process (Growl for
mac, DBus for Linux), you need to do some sanity checking on the image
by transcoding it in a sandboxed process.  Otherwise, an malicious
image may be able to compromise the process you hand it off to and
gain access to the machine.  We're doing this transcoding for themes
and extensions via the "utility process" (check out
utility_process_host.cc as a starting point).  The idea is that the
image you get from the web may be malicious or just poorly formed, and
by transcoding it, you can detect these problems and limit the damage
to a sandboxed process.

Erik


On Thu, Jun 18, 2009 at 1:58 PM, John Gregg  wrote:

> Hi all,
>
> I'm working on a desktop notifications javascript API for web apps; on Mac
> these calls will go out to the Growl notification system if it's installed
> and user has granted permission to get notifications from that origin.  I'm
> still trying to completely grasp the sandbox architecture, so the question I
> need some input on is how to design the integration with respect to
> sandboxing & security.
>
> The Growl code that would be included in Chrome is just a stub that works
> by marshalling data over to a separate Growl process, so the surface area is
> small, but as a design question, is calling to a third-party library
> something that should happen in the sandboxed renderer process, or should it
> be kept in the browser process?  One other factor is that the notification
> requires an icon to be downloaded, which should happen outside the sandbox.
>
> So there are two possible flows:
>
> A. renderer gets notification(iconURL, text) call => hop to browser to
> download icon => call Growl from browser
>
> B. renderer gets notification(iconURL, text) call => hop to browser to
> download icon => pass back icon data to renderer => call Growl from renderer
>
> My instinct is that B is safer for the remote possibility that Growl chokes
> on the input and causes a crash.  What do people think?  Is there an
> existing precedent for similar library calls?
>
> Thanks,
>  -John
>
> >
>

--~--~-~--~~~---~--~~
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: Extensions i18n Design Doc Draft

[Erik Kay]

In general, this is a bad plan.  The translated strings are designed to be
used in a particular context, and while the words themselves might make
sense in multiple contexts in one language, the same wouldn't be true for
another.  Encouraging people outside of the project to make the call about
when it makes sense to use a string in a different context or not is going
to be extremely error prone.
Erik


On Tue, Jun 30, 2009 at 8:54 AM, PhistucK  wrote:

> But now when I come to think about it, the Chrome strings are changing
> sometimes, added or removed.This could pose a problem. Unless you want to
> start a new ground rule - all of the strings must be maintained from now on
> and never be removed - only added.
>
>
> ☆PhistucK
>
>
>
> On Tue, Jun 30, 2009 at 18:49, Nebojša Ćirić  wrote:
>
>> We could probably expose them as
>> __chrome_MSG_some_chrome_message__, but will wait for initial review to 
>> decide that.
>> Thanks for the input,
>>  Cira
>>
>> On Mon, Jun 29, 2009 at 10:19 PM, PhistucK  wrote:
>>
>>> How about extending this support and also adding an option to use native
>>> Chrome strings that are in use in the actual program so extension developers
>>> could benefit from your own translations and corrections in the appropriate
>>> cases?
>>> ☆PhistucK
>>>
>>>
>>> 2009/6/30 Nebojša Ćirić 
>>>
  Hi all, I have initial draft for extensions internationalization
 effort. Take a look at
 http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/i18n

 Regards,
  Nebojsa Ciric



>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 do I deploy an NPAPI plugin over the internet from HTML ?

[Erik Kay]

Your best bet is to file a bug with references to the needed files so that
someone here can try to reproduce your problem.
Erik


On Wed, Jul 1, 2009 at 9:12 AM, Non-Stick  wrote:

>
> My plugin stopped working as of the beginning of this week.
>
> This is peculiar, as I have not changed anything of significance in
> the plugin, and the plugin still runs fine under Firefox.
>
> My .CRX file appears to successfully install the plugin files into C:
> \Documents and Settings\\Local Settings\Application Data
> \Google\Chrome\User Data\Default\Extensions
> \npglpdedljnopmnaaeffdeggjkhnkpci.
>
> However, when I run my HTML page, Chrome does not invoke the plugin.
>
> I have examined the Chromium release notes at
> http://dev.chromium.org/getting-involved/dev-channel/release-notes but
> could not see anything of relevance.
>
> The only thing I can think is that it is something to do with Chrome
> updating itself to the latest version : 3.0.190.4 (Official Build
> 19293).
> Has anything changed in the latest dev-channel version of Chrome that
> has either:
>* broken the extension/plugin handling
> or * increased the security requirements of extensions/plugins (eg do
> they now need to be signed, etc) such that I need to do something
> extra when packaging my CRX file
>
> I'm struggling to track down what has caused it to stop working, so
> any suggestions would be welcome.
>
> >
>

--~--~-~--~~~---~--~~
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: Extensions i18n Design Doc Draft

[Erik Kay]

On Wed, Jul 1, 2009 at 10:56 AM, Aaron Boodman  wrote:

>
> 2009/7/1 Jói :
> > b) A way to distinguish between two messages that are textually the
> > same, but have separate meanings, e.g. "Open" (as a verb) and "Open"
> > (as an adjective).  An attribute of the message that is empty by
> > default is ideal.  I would keep this separate from the description
> > attribute, as this facilitates calculating a message ID as a hash over
> > the message contents plus the 'meaning' attribute (this is a useful
> > approach to avoid translating each message more than once, see how it
> > is used in GRIT).
>
> Good point.
>
> > c) A way to demarcate bits of the message that should not be
> > translated - generally these are called "placeholders" but that
> > conflicts with how that term is currently used in the document.  It's
> > important to do this, otherwise translators are going to receive
> > messages that contain "code" bits that shouldn't be translated, and
> > which will cause errors in the running program if they are incorrectly
> > translated.  Consider for example a message like "Hello $USER$, how
> > are you?" and the implications if the translator translates $USER$.
> > Ideally, you could use a format such as XML which allows the extension
> > author to mark any piece of text as a placeholder, but for a simpler
> > approach compatible with more formats, you could require a specific
> > format for non-translateables, e.g. $SOMETHING$ and/or printf-style
> > format specifiers.
>
> So I think this is what Cira meant by "sprintf" in his original
> document. However, I have to admit I'm not crazy about that. It seems
> like overkill. I prefer something simpler like $SOMETHING$.
>
> > For more ideas on the resource format, you could look at GRIT's .grd
> > format or at http://xml.coverpages.org/xliff.html for inspiration.
> > Both are probably more complex than what we'd like to have for
> > extension message catalogs, and so as long as the format supports the
> > things I mentioned above, I believe it should be fine.
> >
> > Finally, keep in mind that messages may contain embedded line-breaks,
> > so it's good to have a format that supports this naturally.
>
> I realized that for the message format, there is one other consideration:
>
> We cannot parse untrusted JSON or XML in the browser, so we will need
> to do this in a sandboxed process. We already have a nice mechanism
> for doing this with JSON, but we'd have to come up with something new
> for XML.


We're already planning to do sandboxed XML for extension autoupdate, so we
could depend on that too.

Erik

--~--~-~--~~~---~--~~
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: Extensions i18n Design Doc Draft

[Erik Kay]

On Wed, Jul 1, 2009 at 11:34 AM, Aaron Boodman  wrote:

> On Wed, Jul 1, 2009 at 11:12 AM, Erik Kay wrote:
> > On Wed, Jul 1, 2009 at 10:56 AM, Aaron Boodman  wrote:
> >>
> >> 2009/7/1 Jói :
> >> > b) A way to distinguish between two messages that are textually the
> >> > same, but have separate meanings, e.g. "Open" (as a verb) and "Open"
> >> > (as an adjective).  An attribute of the message that is empty by
> >> > default is ideal.  I would keep this separate from the description
> >> > attribute, as this facilitates calculating a message ID as a hash over
> >> > the message contents plus the 'meaning' attribute (this is a useful
> >> > approach to avoid translating each message more than once, see how it
> >> > is used in GRIT).
> >>
> >> Good point.
> >>
> >> > c) A way to demarcate bits of the message that should not be
> >> > translated - generally these are called "placeholders" but that
> >> > conflicts with how that term is currently used in the document.  It's
> >> > important to do this, otherwise translators are going to receive
> >> > messages that contain "code" bits that shouldn't be translated, and
> >> > which will cause errors in the running program if they are incorrectly
> >> > translated.  Consider for example a message like "Hello $USER$, how
> >> > are you?" and the implications if the translator translates $USER$.
> >> > Ideally, you could use a format such as XML which allows the extension
> >> > author to mark any piece of text as a placeholder, but for a simpler
> >> > approach compatible with more formats, you could require a specific
> >> > format for non-translateables, e.g. $SOMETHING$ and/or printf-style
> >> > format specifiers.
> >>
> >> So I think this is what Cira meant by "sprintf" in his original
> >> document. However, I have to admit I'm not crazy about that. It seems
> >> like overkill. I prefer something simpler like $SOMETHING$.
> >>
> >> > For more ideas on the resource format, you could look at GRIT's .grd
> >> > format or at http://xml.coverpages.org/xliff.html for inspiration.
> >> > Both are probably more complex than what we'd like to have for
> >> > extension message catalogs, and so as long as the format supports the
> >> > things I mentioned above, I believe it should be fine.
> >> >
> >> > Finally, keep in mind that messages may contain embedded line-breaks,
> >> > so it's good to have a format that supports this naturally.
> >>
> >> I realized that for the message format, there is one other
> consideration:
> >>
> >> We cannot parse untrusted JSON or XML in the browser, so we will need
> >> to do this in a sandboxed process. We already have a nice mechanism
> >> for doing this with JSON, but we'd have to come up with something new
> >> for XML.
> >
> > We're already planning to do sandboxed XML for extension autoupdate, so
> we
> > could depend on that too.
>
> I don't think it's the same.
>
> For autoupdate, we only need to parse the XML so that we can pick a
> few fields out of it.
>
> For i18n, we need to actually use the XML later, at runtime. We don't
> want to convert it to some other format because we also need to handle
> the --load-extension case, where we won't want to convert to an
> intermediate format.
>
> This means we need to sanitize the XML, more like what we do with the
> manifest today. So we'd need to serialize it to some intermediate
> format and send it back to the browser process. We already have a way
> to do this for JSON -- I'm just saying we'd need to do something
> similar for XML.


Fair enough.  I guess all I was saying is that we're going to be doing
sandboxed parsing of XML already.  Rewriting it as part of that work doesn't
seem like a large addition.

Erik

--~--~-~--~~~---~--~~
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: Trac

[Erik Kay]

+evan

Have any of you tried Evan's git web interface (sorry, it's currently inside
google only)?  It's really fast, and very nice (although it appears to be a
bit stale now).  Perhaps it would be worth it to set that up externally as
an alternative to viewvc.
Erik


On Wed, Jul 1, 2009 at 9:32 PM, Eric Seidel  wrote:

>
> I will note that in WebKit's experience Trac is super-slow (at least
> the version webkit.org is using).  Trac does not seem to do much (if
> any) caching.
>
> -eric
>
> On Wed, Jul 1, 2009 at 7:27 PM, Jeremy Orlow wrote:
> > Is there any reason we use ViewVC rather than something like trac (for
> > example, trac.webkit.org)?  I wouldn't exactly call Trac amazing, but
> there
> > are a few cool features that I definitely missin ViewVC.
> > J
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Clobber third_party/ffmpeg/binaries before syncing

[Erik Kay]

With a gclient sync this morning, it seems very confused about
ffmpeg/binaries.  First the sync failed saying that ffmpeg/binaries was from
a different repository.  Then I removed the directory and did a sync where
it pulled down ffmpeg/binaries again and told me that ffmpeg/binaries was no
longer part of the client and I should delete it.  It's now telling me this
on ever sync regardless of whether I delete it or not.
Erik


On Mon, Jul 6, 2009 at 2:04 PM, Evan Martin  wrote:

>
> On Mon, Jul 6, 2009 at 2:02 PM, Andrew Scherkus
> wrote:
> > On Mon, Jul 6, 2009 at 1:54 PM, Evan Martin  wrote:
> >>
> >> third_party/ffmpeg/binaries is an extra 6mb of download for our source
> >> checkout, even on platforms that can't use these binaries.  If you
> >> multiply by 3 for Mac/Linux it'll become 18mb.
> >>
> >> In the past we've used conditional DEPS entries to pull these
> >> depending on platform.  (See the references to cygwin in src/DEPS, for
> >> example.)  Does that make sense here?
> >
> > Makes sense to me.  I guess I'd have to move them outside of /src
> though...
> > maybe to /deps
>
> Yes, that is what I was suggesting.
>
> >
>

--~--~-~--~~~---~--~~
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: Rewrite of DOMUI l10n strings

[Erik Kay]

This seems like a reasonable plan.

It would be cool if whatever mechanism you chose could be leveraged by
extensions as well (see the earlier extensions i18n proposal that was sent
around last week).  For this reason I'd prefer that if we moved to a C++
solution (as others in this thread have suggested) that it run in the
renderer and not in the browser process (for security reasons).
Erik


On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson  wrote:

>
> Currently we use JsTemplate
> (http://code.google.com/p/google-jstemplate/) to do our l10n of the
> DOMUI. JST has been working well but it is a bit of an overkill to do
> l10n of our UI. It has a couple of features that makes it slow down
> the UI:
>
> 1. It uses eval for every single RHS
> 2. It uses two nested with statements
> 3. It traverses the whole DOM using JavaScript
>
> It also has some advanced features like jsselect, which allows
> iteration, that we are using for non l10n things.
>
> My plan is to create a simpler solution, with almost exactly the same
> syntax that solves the 3 bullet points above. It will not allow
> arbitrary expressions on the RHS and it will only support jsvalues and
> jscontent. Instead of traversing the entire tree it ill use
> document.querySelector which does the tree traversal in C++ and uses
> CSS selectors as the matching which is a lot faster than doing the
> tree traversal in JS.
>
> Since there are still cases where we use JST to do more advanced
> templating it will still be available but it will require opt in.
>
> Any thoughts?
>
> --
> erik
>
> >
>

--~--~-~--~~~---~--~~
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: extensions and memory usage

[Erik Kay]

As we add more subprocesses (workers, utilities, extensions, etc.), it would
be great if we could reduce the minimum memory that these processes consume.
 I know that there was some work done a while back to look at what was the
minimum cost of a new process on Windows given our dll size, etc. (maruel?),
but I'm sure that there's more than can be done for us to reduce memory
usage above this level.
Erik


On Fri, Jul 10, 2009 at 1:03 PM, Paweł Hajdan Jr.
wrote:

>
> As extensions are visible in the task manager, it's also possible to
> see their memory usage. I was experimenting with some sample
> extensions, and the usage seems to be in range 1 MB - 12 MB. Typically
> 3-5 MB.
>
> I wonder if it would be possible to reduce that memory usage. In case
> it negatively affects performance, we could have some opt-in way for
> extension developers to say "I want my extensions to run as fast as
> possible, even with increased memory usage".
>
> What do you think?
>
> >
>

--~--~-~--~~~---~--~~
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: Minor proposed changes to page actions API

[Erik Kay]

On Mon, Jul 13, 2009 at 1:44 PM, Aaron Boodman  wrote:

>
> I'd like to close on some mumbling we've been doing about changes to
> the page actions API.
>
> What:
>
> * Make it not required to pre-specify this icon list in the manifest.
> This will require some refactoring to the utility process to be able
> to use it to decode images at any time, not just install time.
> * Rename enableForTab and disableForTab to show and hide
>
> Why:
>
> Increased awesomeness, shorter, more descriptive method names. Also it
> seems like having a utility function lying around that can decode a
> user-supplied image would be really useful for a variety of
> applications in the future.
>
> Yay? Nay?
>


It seems reasonable, but I have some questions / concerns:

- How/where are the resulting images cached?  We don't want each request to
have to be reencoded.  In the current install model, they're simply encoded
in place.

- It seems like there may be related issues if multiple requesters ask for
the image at the same time.

- What's the increased latency for requesting a single image?  I imagine
it's not much, but at installation time, an extra 100ms would be no big
deal, while in response to UI actions, it would be noticeable jank.

- One benefit of having domain-specific image lists is that we could do
other validation that was not just for security reasons.  For example, we
could enforce that page action images were of a particular size and not
2000x2000 (although I don't think we're doing this now).

Erik

--~--~-~--~~~---~--~~
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: Minor proposed changes to page actions API

[Erik Kay]

On Mon, Jul 13, 2009 at 2:20 PM, Aaron Boodman  wrote:

> On Mon, Jul 13, 2009 at 2:09 PM, Erik Kay wrote:
> > It seems reasonable, but I have some questions / concerns:
> > - How/where are the resulting images cached?  We don't want each request
> to
> > have to be reencoded.  In the current install model, they're simply
> encoded
> > in place.
>
> Yes, they would be written back into the extension. We already do this
> for page actions so I presumed it would be some generalization of that
> (we'd have some shadow directory somewhere containing the
> sanitized/decoded versions of images in the extension).


We'd probably need to store the list of sanitized images in prefs to avoid
the extra stat for every image, but OK.



> > - It seems like there may be related issues if multiple requesters ask
> for
> > the image at the same time.
>
> Yeah, I guess you'd have to keep a map of outstanding requests on the
> UI thread and queue them.
>
> > - What's the increased latency for requesting a single image?  I imagine
> > it's not much, but at installation time, an extra 100ms would be no big
> > deal, while in response to UI actions, it would be noticeable jank.
>
> An extra file read and write the first time. I think it would be
> tolerable, but we'd have to build it to be sure.
>
> > - One benefit of having domain-specific image lists is that we could do
> > other validation that was not just for security reasons.  For example, we
> > could enforce that page action images were of a particular size and not
> > 2000x2000 (although I don't think we're doing this now).
>
> Good point. We could still do this validation at processing time no
> matter when we do it. We just wouldn't be able to have a validation
> error at install time. But that doesn't seem like a big loss.


The other loss here is that we could have caught those problems at package
time.  Without the declarative list, we can't do that either.

Erik

--~--~-~--~~~---~--~~
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: Minor proposed changes to page actions API

[Erik Kay]

On Mon, Jul 13, 2009 at 4:12 PM, Aaron Boodman  wrote:

> On Mon, Jul 13, 2009 at 4:08 PM, Erik Kay wrote:
> > We'd probably need to store the list of sanitized images in prefs to
> avoid
> > the extra stat for every image, but OK.
>
> There's on extra stat, read, and write the first time an image is
> used. This does not seem like a big deal to me (not worth piling more
> state into preferences for). These images are not used to draw the
> main UI, and startup doesn't block on them. If we ever add the magical
> file cache thing that would be used generally for extension resources,
> it would presumably help with this too. But it doesn't feel like
> something that needs optimizing by itself.
>
> > The other loss here is that we could have caught those problems at
> package
> > time.  Without the declarative list, we can't do that either.
>
> True. You know I'm big on error handling, but I feel like ease-of-use wins
> here.
>

As I said originally, I think the proposal sounds reasonable.  It'a always
worth going through the downsides.

Erik

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

[chromium-dev] Working on a new feature? Add extensions support.

[Erik Kay]

If you're not working on any new features or new UI, you can probably skip
the rest of this email.

If you are, then please take the time to think about whether your feature
should be accessible from extensions.  Hopefully, "no" should be more of the
exception than the rule.

It turns out that adding extensions support is pretty easy.  Here's a recent
sample CL that adds a getLanguage() function that uses compact language
detection:
http://codereview.chromium.org/150062
(it's a fair number of files, but the changes are small and easy to
understand)

Feel free to send questions to the list.  We're happy to help with
everything from basic how-to questions, to API design, etc.

Erik

--~--~-~--~~~---~--~~
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: Working on a new feature? Add extensions support.

[Erik Kay]

I think Aaron's mail makes the point, but just to be clear: before starting
coding any new APIs, please send a rough proposal to Aaron and myself.
 We'll put together an API design based on your proposal and then send it
around for broader feedback.  Then we'll start looking at the CLs.
Our turnaround time is pretty fast on this, so don't expect this to be a
heavyweight process.

thanks,
Erik


On Mon, Jul 13, 2009 at 5:17 PM, Erik Kay  wrote:

> If you're not working on any new features or new UI, you can probably skip
> the rest of this email.
>
> If you are, then please take the time to think about whether your feature
> should be accessible from extensions.  Hopefully, "no" should be more of the
> exception than the rule.
>
> It turns out that adding extensions support is pretty easy.  Here's a
> recent sample CL that adds a getLanguage() function that uses compact
> language detection:
> http://codereview.chromium.org/150062
> (it's a fair number of files, but the changes are small and easy to
> understand)
>
> Feel free to send questions to the list.  We're happy to help with
> everything from basic how-to questions, to API design, etc.
>
> Erik
>
>

--~--~-~--~~~---~--~~
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: Themes and their removal

[Erik Kay]

On Wed, Jul 15, 2009 at 7:44 AM, Avi Drissman  wrote:

> I'm playing around fixing the rough edges of the Mac theme implementation
> and I'm hitting areas where it doesn't seem to be implemented for any
> platform.
>
> First, you said that you were going to make it so that when you install one
> theme it uninstalls all others. Is that coming soon?


I don't know if that's the case.  I believe the intention is that the theme
stays installed, but simply that the app switches to use the new theme.  Is
this right Glen?


I ask because I'm running into the issue where uninstalling a theme (when
> it's the only one left) pulls out the images but leaves residue in the
> Preferences. The bitmap in the window doesn't go away on the uninstall (and
> no "theme change" notification fires), and on restart of the browser I get
> remnants of the color scheme. I'd change the code, but I don't know how that
> would interact with having a second theme sitting around unused (thus the
> first question).


I assume you're talking about uninstalling the theme from
chrome://extensions.  This sounds like a straightforward bug.  We should
just invoke the "reset to default theme" code when we uninstall the current
theme.  On the other hand, I think Glen would prefer that we not show themes
at all on chrome://extensions, which would reduce the need for this
altogether (although it may still be a good idea for correctness).  What do
you think Glen?


How do we want to go with this?


I'd file a bug for the second, but punt on the first.

Erik

--~--~-~--~~~---~--~~
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: [extensions] Notes on storing extension manifest in preferences

[Erik Kay]

resending

On Wed, Jul 15, 2009 at 3:08 PM, Erik Kay  wrote:

> On Wed, Jul 15, 2009 at 12:04 PM, Aaron Boodman  wrote:
>
>>
>> On Wed, Jul 15, 2009 at 11:30 AM, Matt Perry
>> wrote:
>> > On Wed, Jul 15, 2009 at 9:59 AM, Aaron Boodman  wrote:
>> >>
>> >> a) I think it is important to not break the extension system with this
>> >> mod, so that means that for awhile (1 or 2 dev channel releases?) we
>> >> will both write the entire manifest to the prefs and load from disk
>> >> normally.
>> >
>> > What if on extension load, we checked the prefs first, and if the
>> manifest
>> > entry was absent, then we loaded from disk?  New extension installs
>> would
>> > write only to the pref.  Seems like that would get us transparent
>> backwards
>> > compat.
>>
>> You're right, that is another way to do it.
>
>
> +1 to Matt's approach here.
>
>
> >> b) Extension prefs are currently written in
>> >> ExtensionsService::OnExtensionInstalled. At this point, we no longer
>> >> have the JSON form of the manifest, it has already been parsed into an
>> >> Extension object.
>> >
>> > It's easy enough to pass along the JSON object from OnExtensionUnpacked,
>> > which calls OnExtensionInstalled.
>>
>> True, but it felt really messy to me. Basically this means that we end
>> up with two representations of the extension: the Extension manifest
>> and the Extension object. The object contains all kinds of extra state
>> like the location, the path, etc. It seems like an area for potential
>> confusion.
>>
>> >> b) and c) lead me to the conclusion that we should refactor the
>> >> Extension class so that it is a lightweight wrapper around a JSON
>> >> dictionary and has no state of its own. This would fix the problem of
>> >> not having access to the JSON representation and therefore having to
>> >> write serialization code for it.
>> >
>> > A less radical approach would be to keep a copy of the JSON dictionary
>> in
>> > the Extension class while we're in this migration period.  That's not to
>> say
>> > we shouldn't refactor the Extension class (I have no opinion on that).
>>
>> True.
>
>
> Refactoring Extension to be a light-weight wrapper around DictionaryValue
> seems reasonable.  It's somewhat annoying that every time someone wants a
> property that the code will need to go through all of the (if has key, get
> key) work (potentially through multiple levels of hierarchy), but I don't
> think that there's a practical downside (we don't ask for properties very
> often).  It also means that we'll wind up duplicating a fair amount of code
> between validation and access, but again I don't see this as a huge problem
> either.
>
> Random wacky thought: perhaps validation could be done using JSON schema?
>  (although it doesn't really fit in this case since this is running in the
> browser)
>
> Erik
>
>

--~--~-~--~~~---~--~~
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: Proposal: chrome.tabs.executeContentScript()

[Erik Kay]

This is really great!
One naming thought for you.  I wonder if the methods should be named
"loadScript" and "loadCSS"?  I know that this is effectively the same thing
with JS, but "execute" sounds like it's just running something temporarily
(maybe in the page's context) and forgetting about it, while load is loading
it into the page and leaving it there for later reference.  I don't have a
strong opinion about this, it's just what popped into my head.

When you say no attempt is made to dedupe these, again it sounds like the
only downside is that the code has been run twice.  Even for transient code,
the newly created context would stick around until the next GC,  If the code
did anything more substantial, it would also keep this context and extra
memory alive.  Perhaps this is just solved by stronger wording in the doc.

Erik


On Wed, Jul 15, 2009 at 12:37 PM, Aaron Boodman  wrote:

>
> Thanks everyone for the quick feedback. I've modified the proposal to
> support also executing strings of JavaScript. Detailed comments
> inline.
>
>
> On Wed, Jul 15, 2009 at 11:41 AM, Jói wrote:
> > This seems very useful to me.
>
> Thanks!
>
>
> On Wed, Jul 15, 2009 at 11:41 AM, Jói wrote:
> > Perhaps it would be useful to also let extensions directly execute
> > snippets of script, both for convenience and so that they don't need
> > to be static files that are baked into the extension.  You could
> > imagine e.g. a content script that is dynamically generated based on
> > preferences.
>
> On Wed, Jul 15, 2009 at 11:52 AM, Evan Martin wrote:
> > Content to inject:
> > What do I do if I have a string I'd like to inject?  This may seem
> > silly, but imagine you have a JS file that does most of the work and
> > you'd like to do the equivalent of "var kDataToOperateOn = ...;
> > 

[chromium-dev] Re: [extensions] Proposal: get extension views by type

[Erik Kay]

one more time

On Wed, Jul 15, 2009 at 3:35 PM, Erik Kay  wrote:

> Very cool.
> One quick question is about race conditions at load time.  Will this handle
> the case where a background page asks for its toolstrips right away (or vice
> versa)?
>
> Erik
>
>
> On Wed, Jul 15, 2009 at 12:41 PM, Aaron Boodman  wrote:
>
>>
>> We currently have the ability to get a list of references to all the
>> DOMWindows in your own extension via chrome.extension.getViews().
>>
>> But there have been requests to be able to get just the toolstrips, or
>> just the background page. Additionally, I've heard requests for
>> getting just the toolstrips associated with a particular window.
>>
>> Hence:
>> http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/get-extension-views-by-type-proposal
>>
>> Feedback desired!
>>
>> - 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: [extensions] Notes on storing extension manifest in preferences

[Erik Kay]

On Wed, Jul 15, 2009 at 3:20 PM, Aaron Boodman  wrote:

> On Wed, Jul 15, 2009 at 3:08 PM, Erik Kay wrote:
> > On Wed, Jul 15, 2009 at 12:04 PM, Aaron Boodman  wrote:
> >>
> >> On Wed, Jul 15, 2009 at 11:30 AM, Matt Perry
> >> wrote:
> >> > On Wed, Jul 15, 2009 at 9:59 AM, Aaron Boodman 
> wrote:
> >> >>
> >> >> a) I think it is important to not break the extension system with
> this
> >> >> mod, so that means that for awhile (1 or 2 dev channel releases?) we
> >> >> will both write the entire manifest to the prefs and load from disk
> >> >> normally.
> >> >
> >> > What if on extension load, we checked the prefs first, and if the
> >> > manifest
> >> > entry was absent, then we loaded from disk?  New extension installs
> >> > would
> >> > write only to the pref.  Seems like that would get us transparent
> >> > backwards
> >> > compat.
> >>
> >> You're right, that is another way to do it.
> >
> > +1 to Matt's approach here.
>
> On second thought, I don't like Matt's approach. It would require
> writing lots of new, temporary, code to lazily load extensions, and to
> wait for them to load before firing EXTENSIONS_READY. My original
> suggestion, to just let loading carry on as it does today and to write
> preferences when done would result in little new code.


As we discussed offline, you guys are actually saying the same thing since
today we only load extensions that are in prefs.  So the only new point here
is that we notice if the manifest isn't in prefs and then load it from disk
and write it to prefs when we finish.




> > Random wacky thought: perhaps validation could be done using JSON schema?
> >  (although it doesn't really fit in this case since this is running in
> the
> > browser)
>
> We really need a C++ implementation of JSON Schema to do that. It
> isn't that hard, but I don't really have the motivation since we
> already have the validation code.
>

Agree, that's why I called it a wacky thought.  I guess if we found
ourselves with a second wad of JSON like this it might make sense to
implement it this way.

Erik

--~--~-~--~~~---~--~~
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: Purify - instrumentation fails on XP Unit (purify) bot

[Erik Kay]

What you're seeing is Purify crashing during instrumentation.  The problem
is usually transient, related to the state of the machine and the particular
build revision.  Unfortunately, we don't have great insights as to what's
causing it.  Here are things you can do to try to resolve the issue:
* rdp into the machine and dismiss any alert dialogs that are there
* do a clobber build
* reboot the machine
* wait for a couple of builds and see if it goes away on its own

Also unfortunately, the debug cycle on this is fairly long, so it will be
unclear what exactly caused the problem to get fixed.

As sheriff, if you see it get into this state and stay in this state despite
you doing the previous steps, the next step is to see if it reproduces on
another machine (perhaps your own desktop).  You don't necessarily need to
do a full build, you could grab the build output from the build machine if
that would be faster.

If it does repro, then it's likely that we have a reproducible bug that we
can send off to IBM to try to get a fix for.  They've been fairly responsive
when the crash is reproducible.  Unfortunately, the more recent instances we
have of these crashers have not been reproducible, so we've not been able to
get them fixed.

Erik



On Thu, Jul 16, 2009 at 1:04 PM, Sverrir Á. Berg wrote:

>
> http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Unit%20(purify)
> Any insights would be appreciated...
>
> Sverrir (sheriff)
>
> >
>

--~--~-~--~~~---~--~~
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: Enabled isolation for content scripts

[Erik Kay]

awesome work!

On Thu, Jul 16, 2009 at 1:05 PM, Adam Barth  wrote:

>
> Today I landed a patch that enables a security feature for extensions.
>  Now when an extension runs a content script, that script runs in a
> "parallel universe" with the page.  In its isolated world, the content
> script can see the page's DOM, but it can't see any of the page's
> JavaScript objects.  This helps protect the extension from getting
> hacked by the page's JavaScript.  If you're interested in how a page
> can hack a non-isolated content script, you might enjoy reading
> http://www.adambarth.com/papers/2009/adida-barth-jackson.pdf
>
> This is a "breaking change" in the sense that it changes the content
> script's API (by hiding the page's JavaScript).  If you notice your
> favorite user script acting up after this change, please let me know
> and we'll try to get to the bottom of the issue.
>
> Adam
>
> >
>

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

[chromium-dev] Re: Mac Valgrind Bots

[Erik Kay]

On Fri, Jul 17, 2009 at 8:12 AM, Nicolas Sylvain wrote:

>
>
> On Fri, Jul 17, 2009 at 7:40 AM, Dan Kegel  wrote:
>
>> On Fri, Jul 17, 2009 at 2:34 PM, Thomas Van Lenten
>> wrote:
>> >> We're already running at -O1 on Linux, so there isn't much improvement
>> >> left to be had, I suspect.   It might be worth it, dunno.
>> >
>> > There is a lot of code cut out by being NDEBUG instead of DEBUG, that's
>> > where I think the mac is getting its speed up.  Yesterdays mac valgrind
>> runs
>> > on the main waterfall were actually -O0 while we waited for the v8 issue
>> to
>> > be fixed and they saw that speed up.
>>
>> FWIW, I saw a noticable speedup from goint to -O1.  Glad to
>> hear there's more to be had.  I guess I'll try it.
>
>
> On Windows we also use a release build without optimization. Purify can
> barely run with a debug build.
>

One other tradeoff to consider with these build options for valgrind is
quality and consistency of stack traces.  I don't know how much of an issue
this has been for valgrind, but I'll share the Purify side of it with you.

As Nicolas points out, Purify runs a Release build with no optimizations,
and some linker options disabled.  Running release is a huge performance
improvement since it gets rid of a lot of extra code that's being run.
 Minimizing the optimizations allows for more consistent stack traces since
levels of the stack aren't getting optimized away and line number info is
more accurate.  Further, we disable COMDAT folding in the linker, which with
visual studio combines identical code into the same entry point.  This is a
great optimization for code like ours that uses templates heavily, but it
winds up making the stacks less understandable and less deterministic.

Erik

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

[chromium-dev] Purify help office hours

[Erik Kay]

To echo Dan's valgrind office hours, I'll be available to help with Purify
issues for this week's fixit as well.  See
http://code.google.com/p/chromium/wiki/StabilityFixitWeek for more details
(thanks to dank for setting up this page).

I'll be on IRC from 9-3:30PST, and should respond to email questions as
well.

You may still be able to help review bugs even if you don't have Purify
installed (Purify isn't a free tool).  It's likely that a number of the bugs
will be findable simply by inspection.

thanks,
Erik

--~--~-~--~~~---~--~~
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: Mozilla design challenge

[Erik Kay]

You may be on to something, but I think it's more complex than this.  For
example bookmark systems don't work because people use them for a number of
conflicting purposes (my list of things to read every day, a simple history
system, a 'to read' list, a collection of links for research), which have
different UI requirements.  I think the same thing has happened with tabs
(and there's a surprising amount of overlap).  Here are the use cases I know
I wind up using: - a few long running apps that need to keep running,
potentially notifying me of new events (calendar, mail, chat, buildbot,
etc.)
- a few pages that I'm currently actively using (a screenshot from a bug I'm
looking at, some reference documentation, a writely page I'm editing between
compiles, etc.)
- a "to read" list of pages that I started reading but didn't finish yet
(sometimes this is a collection of related pages when researching something)
- I'm sure there are others.

In my use case, 80% of my tabs could easily be killed / suspended (or even
hidden altogether) without any downside to me.  The problem is that there
isn't a way to automatically figure out which ones are which.  Which ones
have pending state that might be lost? (yes, some of this is bad app design,
but there are many like this)  Which ones do I expect to keep running all of
the time because of notifications?  What about that flash game that I left
running in the background?

Maybe we could come up with some heuristics that could detect some of this
automatically, but I worry that there will be so many exceptions that it
won't work.  That means we'd need to come up with a better UI to express
these concepts where the user chose to treat tabs differently in some
explicit way.  There are a number of extensions that try to do this for some
specific use cases (to read lists, pinned tabs, etc.).  I'm not sure that
these are better than bandaids though.

Erik


On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee  wrote:

>
> I feel like people are using tabs as a replacement for a good history
> system.  At least in all current browser implementations, tabs are
> "running".  Even if we can make the UI scale to 1000 tabs, the 500
> flash instances that are likely running aren't really going to
> perform.  The making tab performance scale is a separate technical
> issue that will hopefully also improve.
>
> Looking at a lot of these design videos, they looked more like good
> ideas to me for history navigation than tab navigation.  If history
> was good, I think people wouldn't be so worried about "losing
> something" by closing a tab.  Having had bad history systems for so
> many years, people are now trained to keep tabs open if they ever
> might want to look at that page again in the future :\
>
> On Sat, Jul 18, 2009 at 1:16 AM, Peter Kasting wrote:
> > http://design-challenge.mozilla.com/summer09/
> > The results of the "Reinventing Tabs in the Browser" challenge have been
> > announced.
> > "Collapsible Tab Groups" includes among others some things I've proposed,
> > including grouping and collapsing groups.
> > "Favitabs" reminds me of some old brainstorming ideas from pamg about
> > converting certain tabs into favicon buttons.
> > Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do
> well
> > to take a look at some of these.
> > 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: No more buildbot auto-refresh - Update your bookmark!

[Erik Kay]

On Tue, Jul 21, 2009 at 11:53 AM, Nicolas Sylvain wrote:

> On Tue, Jul 21, 2009 at 11:37 AM, Aaron Boodman  wrote:
>
>> Nicolas,
>>
>> Are you going to be turning back on the extension support at any
>> point? If not, just let us know so that we can remove the feature from
>> the sample. Right now it looks broken.
>
>
> Is the reload in the extension still 30secs?  If it can be changed to 2 or
> 5 minutes I will reenable it.
>

We can fix it, but until extension autoupdate gets enabled, existing users
with it installed will still have it on a 30 second timer.  I'll let you
know when we've pushed out the change, and we'll send a PSA asking people to
update manually.

Erik




>
> Nicolas
>
>
>>
>>
>> - a
>>
>> On Tue, Jul 21, 2009 at 8:27 AM, Nicolas Sylvain
>> wrote:
>> > Hi,
>> > Last week a lot of people on this list said that they like the idea of
>> > disabling the auto-reload for
>> > our buildbot waterfall and console view. This is now implemented.
>> > If you do want to keep the page auto-refreshing, please update your
>> > bookmark. just add the
>> > query parameter "reload=X", where X is the number of second to wait
>> between
>> > each reloads.
>> > X used to be 90. Depending on your needs, you can increase or decrease
>> this
>> > number.
>> > Examples:
>> > console view:
>> > http://build.chromium.org/buildbot/waterfall/console?reload=180
>> > waterfall
>> > : http://build.chromium.org/buildbot/waterfall/waterfall?reload=180
>> > For sheriffs:
>> >
>> http://build.chromium.org/buildbot/waterfall/waterfall?failures=1&reload=30
>> > Thanks
>> > Nicolas
>> > >
>> >
>>
>
>
> >
>

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

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

[Erik Kay]

You can still have a single file/URL with this info for convenience.  Just
auto-generate it from the svn-logs.  You lose the ability to edit it and
make it look nice, but that could be done manually as a separate file if
you'd like.
Erik


On Tue, Jul 21, 2009 at 11:08 PM, Anthony LaForge wrote:

> The main advantage that I could see for a file would be that I could point
> people to a single file (at any given revision) which could tell then the
> exact state of feature work and history.  It seems to me that the
> RELEASE_NOTE tag would be more cumbersome.
> Kind Regards,
>
> Anthony Laforge
> Technical Program Manager
> Mountain View, CA
>
>
> On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin  wrote:
>
>> On Tue, Jul 21, 2009 at 10:22 PM, Adam Langley wrote:
>> >
>> > On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForge
>> wrote:
>> >> In order to make it easier for the community to see the changes are
>> going on
>> >> inside Chromium I'd like to propose that we add one or more ChangeLog
>> files
>> >> into our code base.  The proposed usage would go something like this:
>> >
>> > I'm not saying anything that Jeremy and Adam haven't already said,
>> > just reinforcing their point in case there's any question.
>> >
>> > What you want is `git log | grep RELEASE_NOTE`
>>
>> git log --grep=RELEASE_NOTE
>> will show the full log entries that match that text.
>>
>> PS: I've gotta be 100% on responding to threads that mention git, huh.
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Purify help office hours

[Erik Kay]

If you were looking into any of the new Purify Fixit bugs in ui_tests,
please hold off.  It appears that a number of the bugs are bogus.  If you're
interested in the gory details, feel free to mail me.
Erik


On Mon, Jul 20, 2009 at 9:16 AM, Erik Kay  wrote:

> To echo Dan's valgrind office hours, I'll be available to help with Purify
> issues for this week's fixit as well.  See
> http://code.google.com/p/chromium/wiki/StabilityFixitWeek for more details
> (thanks to dank for setting up this page).
>
> I'll be on IRC from 9-3:30PST, and should respond to email questions as
> well.
>
> You may still be able to help review bugs even if you don't have Purify
> installed (Purify isn't a free tool).  It's likely that a number of the bugs
> will be findable simply by inspection.
>
> thanks,
> Erik
>
>
>

--~--~-~--~~~---~--~~
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: Purify help office hours

[Erik Kay]

I've marked all of the suspect bugs as Invalid.
For now, I've left the memory leak bugs filed as part of this fixit.  Let me
know if you think that any of these look bogus.

Erik


On Wed, Jul 22, 2009 at 3:14 PM, Erik Kay  wrote:

> If you were looking into any of the new Purify Fixit bugs in ui_tests,
> please hold off.  It appears that a number of the bugs are bogus.  If you're
> interested in the gory details, feel free to mail me.
> Erik
>
>
> On Mon, Jul 20, 2009 at 9:16 AM, Erik Kay  wrote:
>
>> To echo Dan's valgrind office hours, I'll be available to help with Purify
>> issues for this week's fixit as well.  See
>> http://code.google.com/p/chromium/wiki/StabilityFixitWeek for more
>> details (thanks to dank for setting up this page).
>>
>> I'll be on IRC from 9-3:30PST, and should respond to email questions as
>> well.
>>
>> You may still be able to help review bugs even if you don't have Purify
>> installed (Purify isn't a free tool).  It's likely that a number of the bugs
>> will be findable simply by inspection.
>>
>> thanks,
>> Erik
>>
>>
>>
>

--~--~-~--~~~---~--~~
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: Design Doc: out of process (v8) proxy resolving

[Erik Kay]

On Wed, Jul 29, 2009 at 9:44 AM, Linus Upson  wrote:

> I realize this is not a small request, but it would be better if we could
> move to a model where the browser was sandboxed and talked to a much simpler
> process to carry out trusted operations on its behalf.


While I like the general goal of what you're proposing, the downside of this
approach is that if there's a crash, you lose the browser process.  If we
still wind up storing much of the state of the browser in this main process,
then we lose a lot of state and potentially cause much of the browser to
become unusable (I'm assuming that the whole browser wouldn't crash since
the 'microkernel' would likely keep everything running).  When one of these
utility process crashes, we only lose that operation.

Erik



> Linus
>
>
> On Wed, Jul 29, 2009 at 3:29 AM, Eric Roman  wrote:
>
>>
>> Here is a design document for http://crbug.com/11746
>>
>>
>> http://sites.google.com/a/chromium.org/dev/developers/design-documents/out-of-process-v8-pac
>>
>> Feedback welcome.
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Design Doc: out of process (v8) proxy resolving

[Erik Kay]

On Wed, Jul 29, 2009 at 1:42 PM, Linus Upson  wrote:

> Sorry. The point of my sandbox the browser suggestion wasn't to increase
> robustness in the case of failure. It was only to limit the damage an
> exploit might cause. The browser process is complicated enough that it is
> hard to secure. A small broker would be easier to understand and make
> resistant to attack.


Right. Utility processes and a secure broker for a sandboxed browser solve
different problems.  My guess is that in an ideal world, we'd wind up with
both, where places that had direct contact with untrusted data (like Eric's
PAC proposal here) being put into isolated processes.  Given that this was
the thread you replied to, it seemed like you were suggesting that we'd be
better off keeping this in process with a sandboxed browser (assuming we had
time to do so, etc.).

Erik



>
> Linus
>
>
> On Wed, Jul 29, 2009 at 1:40 PM, Erik Kay  wrote:
>
>> On Wed, Jul 29, 2009 at 9:44 AM, Linus Upson  wrote:
>>
>>> I realize this is not a small request, but it would be better if we could
>>> move to a model where the browser was sandboxed and talked to a much simpler
>>> process to carry out trusted operations on its behalf.
>>
>>
>> While I like the general goal of what you're proposing, the downside of
>> this approach is that if there's a crash, you lose the browser process.  If
>> we still wind up storing much of the state of the browser in this main
>> process, then we lose a lot of state and potentially cause much of the
>> browser to become unusable (I'm assuming that the whole browser wouldn't
>> crash since the 'microkernel' would likely keep everything running).  When
>> one of these utility process crashes, we only lose that operation.
>>
>> Erik
>>
>>
>>
>>> Linus
>>>
>>>
>>> On Wed, Jul 29, 2009 at 3:29 AM, Eric Roman  wrote:
>>>
>>>>
>>>> Here is a design document for http://crbug.com/11746
>>>>
>>>>
>>>> http://sites.google.com/a/chromium.org/dev/developers/design-documents/out-of-process-v8-pac
>>>>
>>>> Feedback welcome.
>>>>
>>>>
>>>>
>>>
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
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)

[Erik Kay]

Does each shard get its own profile?  Or do they share?  Does this mean that
when you shard they're sharing the same browser process?
Erik


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: [chromium-extensions] how to prototype new extension APIs?

[Erik Kay]

+chromium-dev
bcc: chromium-extensions
(this is more of a topic for chromium-dev since it's about modifying
the browser and not about writing extensions, which is what
chromium-extensions is for)

I replied separately to Xiomei, but for others' benefit, the step
that's missing here is adding definitions to
chrome/common/extensions/api/extension_api.json.  That's the step that
actually exposes an API to javascript in extensions.

Erik


On Thu, Aug 13, 2009 at 9:32 AM, Xiaomei Ji wrote:
> I would like to get some pointers on how to start to prototype new extension
> APIs.
> Say for example, if I need to add an extension API:
>  chrome.i18n.getAcceptLanguages().
> I need to:
> 1. declare/define "i18n.getAcceptLanguages" as a const char[] in
> extension_i18n_module_constants.h/cc
> 2. declare/define the API class and RunImpl() method in
> extension_i18n_module.h/cc
> 3. add the new files into chrome.gyp
> 4. register the new extension functions into factory in
> extension_function_dispatcher.cc
> After build chrome, looks like "chrome.i18n" was not recognized.
> There must be something (binding?) I missed, appreciate any inputs.
> Thanks,
> Xiaomei
>
> >
>

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

[chromium-dev] FYI: XP unit purify bot broken

[Erik Kay]

The XP unit Purify bot has been failing for the last week or so.
Unfortunately, this has turned out to be more than just a simple case
where we can filter out a particular broken test.  To fix it, we
either need a fix from IBM/Rational (unlikely, due to the nature of
the bug - see below), or we need to do a bit of surgery on the test
itself.  Huan has agreed to help with the latter, but this will likely
take some time to work out.  In the meantime, we're more vulnerable to
new memory bugs.  Please do your best to be extra careful until we can
get the bot enabled again.  When we do enable the bot, we should
expect to have a number of new bugs that need to be looked at in short
order.

We'll give more updates as we have them.

Erik

Details for those who care:

The issue appears to be that unit_tests.exe under Purify is running
out of address space.  I spent some time over the past few days
disabling tests hoping that the failure was specific to some
particular test.  Unfortunately it seems that the issue is just that
unit_tests.exe has gotten too large.  Purify keeps a bunch of
accounting data for warnings and errors in memory.  It even keeps
records for errors that are filtered out.  Microsoft's STL
implementation generates many warnings (primarily UMRs), and we use
STL heavily (from Rational's and our analysis, these warnings appear
to be benign).  Each of these warnings slows down Purify execution and
consume (a fairly large amount of) memory.  We now appear to have
enough tests that generate enough warnings that we're running out of
memory from them.

So the approach Huan's looking into now is to run unit_tests.exe in
chunks similar to how we do layout and ui tests (although it would run
all chunks in one build rather than split across multiple runs).  The
other approach would involve splitting unit_tests.exe into smaller
pieces (browser, renderer, common, etc.).  This could have other
benefits potentially as the executable size would be smaller, which
would have faster iteration cycles (faster link times, faster
instrumentation times, etc.).  Let me know if you have any interest in
doing work with this approach.

--~--~-~--~~~---~--~~
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: FYI: XP unit purify bot broken

[Erik Kay]

We do boot with /3GB on the bots already.  I talked with M-A about
/LARGEADDRESSAWARE and apparently in the past we've had issues with it
and the sandbox and v8, so we're not using it anywhere.  It's possible
that those issues have been addressed since the last time M-A looked
into this, but verifying that is a fair amount of work.

Erik


On Wed, Aug 19, 2009 at 7:26 PM, Nick Carter wrote:
> Would a quick fix of /3GB in the boot.ini and /LARGEADDRESSAWARE on the
> linker cmdline be viable, or are we already doing that?
>
>  - nick
>
> On Wed, Aug 19, 2009 at 4:12 PM, Erik Kay  wrote:
>>
>> The XP unit Purify bot has been failing for the last week or so.
>> Unfortunately, this has turned out to be more than just a simple case
>> where we can filter out a particular broken test.  To fix it, we
>> either need a fix from IBM/Rational (unlikely, due to the nature of
>> the bug - see below), or we need to do a bit of surgery on the test
>> itself.  Huan has agreed to help with the latter, but this will likely
>> take some time to work out.  In the meantime, we're more vulnerable to
>> new memory bugs.  Please do your best to be extra careful until we can
>> get the bot enabled again.  When we do enable the bot, we should
>> expect to have a number of new bugs that need to be looked at in short
>> order.
>>
>> We'll give more updates as we have them.
>>
>> Erik
>>
>> Details for those who care:
>>
>> The issue appears to be that unit_tests.exe under Purify is running
>> out of address space.  I spent some time over the past few days
>> disabling tests hoping that the failure was specific to some
>> particular test.  Unfortunately it seems that the issue is just that
>> unit_tests.exe has gotten too large.  Purify keeps a bunch of
>> accounting data for warnings and errors in memory.  It even keeps
>> records for errors that are filtered out.  Microsoft's STL
>> implementation generates many warnings (primarily UMRs), and we use
>> STL heavily (from Rational's and our analysis, these warnings appear
>> to be benign).  Each of these warnings slows down Purify execution and
>> consume (a fairly large amount of) memory.  We now appear to have
>> enough tests that generate enough warnings that we're running out of
>> memory from them.
>>
>> So the approach Huan's looking into now is to run unit_tests.exe in
>> chunks similar to how we do layout and ui tests (although it would run
>> all chunks in one build rather than split across multiple runs).  The
>> other approach would involve splitting unit_tests.exe into smaller
>> pieces (browser, renderer, common, etc.).  This could have other
>> benefits potentially as the executable size would be smaller, which
>> would have faster iteration cycles (faster link times, faster
>> instrumentation times, etc.).  Let me know if you have any interest in
>> doing work with this approach.
>>
>> >>
>
>

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