[chromium-dev] How can I run TestShell in Xcode on MacOS

[daniel]

Hi,

How can I run TestShell in Xcode on MacOS? Which xcode project I
should use?

I find these:
./src/base/base.xcodeproj
./src/breakpad/src/client/mac/Breakpad.xcodeproj
./src/breakpad/src/client/mac/handler/minidump_test.xcodeproj
./src/breakpad/src/tools/mac/crash_report/crash_report.xcodeproj
./src/breakpad/src/tools/mac/dump_syms/dump_syms.xcodeproj
./src/breakpad/src/tools/mac/symupload/symupload.xcodeproj
./src/build/all.xcodeproj
./src/build/temp_gyp/googleurl.xcodeproj
./src/build/temp_gyp/v8.xcodeproj
./src/chrome/chrome.xcodeproj
./src/chrome/third_party/hunspell/hunspell.xcodeproj
./src/media/media.xcodeproj
./src/net/net.xcodeproj
./src/printing/printing.xcodeproj
./src/sdch/sdch.xcodeproj
./src/skia/skia.xcodeproj
./src/testing/gtest/xcode/gtest.xcodeproj
./src/testing/gtest/xcode/Samples/FrameworkSample/
WidgetFramework.xcodeproj
./src/testing/gtest.xcodeproj
./src/third_party/bzip2/bzip2.xcodeproj
./src/third_party/ffmpeg/ffmpeg.xcodeproj
./src/third_party/GTM/GTM.xcodeproj
./src/third_party/GTM/GTMiPhone.xcodeproj
./src/third_party/GTM/SpotlightPlugins/AppleScript/
AppleScript.xcodeproj
./src/third_party/GTM/SpotlightPlugins/Installer/
DeveloperSpotlightImporters.xcodeproj
./src/third_party/GTM/SpotlightPlugins/InterfaceBuilder/
InterfaceBuilder.xcodeproj
./src/third_party/GTM/SpotlightPlugins/XcodeProject/TestData/
test.xcodeproj
./src/third_party/GTM/SpotlightPlugins/XcodeProject/
XcodeProject.xcodeproj
./src/third_party/icu38/icu38.xcodeproj
./src/third_party/libevent/libevent.xcodeproj
./src/third_party/libjpeg/libjpeg.xcodeproj
./src/third_party/libpng/libpng.xcodeproj
./src/third_party/libxml/libxml.xcodeproj
./src/third_party/libxslt/libxslt.xcodeproj
./src/third_party/modp_b64/modp_b64.xcodeproj
./src/third_party/npapi/npapi.xcodeproj
./src/third_party/pdfsqueeze/pdfsqueeze.xcodeproj
./src/third_party/sqlite/sqlite.xcodeproj
./src/third_party/WebKit/JavaScriptCore/JavaScriptCore.xcodeproj
./src/third_party/WebKit/WebCore/manual-tests/NPN_Invoke/
NPN_Invoke.xcodeproj
./src/third_party/WebKit/WebCore/WebCore.xcodeproj
./src/third_party/zlib/zlib.xcodeproj
./src/v8/tools/v8.xcodeproj


But none of them seems to be the right one.

Thank you.

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

[chromium-dev] Re: depricating CppBindingClass

[Aaron Boodman]

On Wed, Apr 29, 2009 at 7:41 PM, Mike Belshe  wrote:
> On Wed, Apr 29, 2009 at 6:47 PM, Marshall Greenblatt
>> 3. Is there a way to specify native getter/setter functions for a property
>> defined on the JS side?  For instance, "myobject.foo = bar" would somehow
>> call a natively defined "setFoo" function with the "bar" argument.  If this
>> isn't possible, are there any plans to support native properties directly?
>
> No plans to do that.  Keep in mind that exposing C++ directly to JS should
> be done with great care.  Remember you're expanding the surface area of
> attack.

There are extensive C++ APIs to V8 do this kind of thing at minute
levels of detail. What Extensions are providing are a simple and
powerful high-level API to bridge a JS frontend to a C++ backend. You
write your beautiful JavaScripty API in JS, and funnel all the calls
down to these native functions.

If you want the kind of control you're talking about, you could use v8 directly:
http://code.google.com/apis/v8/intro.html

- 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: depricating CppBindingClass

[Mike Belshe]

On Wed, Apr 29, 2009 at 6:47 PM, Marshall Greenblatt  wrote:

> Hi All,
>
> I'm excited about using v8::Extension instead of CppBoundClass but the
> JavaScript side of v8::Extension (via the |source| argument) seems a bit
> magical to me.  Is there a document that explains the usage and capabilities
> of v8::Extension in greater detail?  I have the following questions so far:


Yeah, we need to write a document.  Sorry about that.


>
>
> 1. Can native functions be called directly by a renderer-loaded script, or
> must calls to them always be wrapped within |source|-defined JS
> objects/functions?


You can declare a native function in your JS as follows:

   native function foo();

Then you can just call foo() as though it were javascript.  You'll at least
need that one line of JS to declare it.  I'd recommend wrapping always,
otherwise you're putting it into the global namespace, and you need to more
carefully sanitize your inputs for security problems.

If you look at any of the existing examples, it's pretty straightforward to
copy.



>
> 2. Are there any limits in scope or size to what can be done within a
> |source|-defined script?


RAM? :-)


>
> 3. Is there a way to specify native getter/setter functions for a property
> defined on the JS side?  For instance, "myobject.foo = bar" would somehow
> call a natively defined "setFoo" function with the "bar" argument.  If this
> isn't possible, are there any plans to support native properties directly?


No plans to do that.  Keep in mind that exposing C++ directly to JS should
be done with great care.  Remember you're expanding the surface area of
attack.

Mike




>
>
> Thanks,
> Marshall
>
>
> On Tue, Apr 28, 2009 at 9:39 PM, Mike Belshe  wrote:
>
>> Yup.  I am not saying we need to get rid of all of it immediately; just
>> put some comments in the header so that we don't use it *more*.
>> Mike
>>
>>
>> On Tue, Apr 28, 2009 at 6:38 PM, Feng Qian  wrote:
>>
>>> CppBindingClass was started for test_shell if I remember correctly,
>>> and I think the functionality can be replaced by using NPAPI instead.
>>> I had an implementation of replacing CppBindingClass by NPAPI in
>>> test_shell (to avoid two implementations for JSC and V8), I don't
>>> remember where the code went.
>>>
>>> On Tue, Apr 28, 2009 at 6:15 PM, Mike Belshe  wrote:
>>> > I've felt this way for a while, and I figured I'd throw it out to see
>>> if we
>>> > all agree.
>>> > I'm hoping we can deprecate CppBindingClass.  At this point, most
>>> extensions
>>> > are better served (I think!) via the v8::extension facility than the
>>> > CppBindingObject.  If there are cases where this isn't true, I'd
>>> happily
>>> > work on v8::extension to make it so it could be.
>>> > If nobody objects, I hope we can agree to stop adding any new
>>> > CppBindingClass based bindings, and then over time get rid of
>>> > CppBindingObject altogether.
>>> > Anyone feel strongly in opposition?
>>> >
>>> > 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: depricating CppBindingClass

[Marshall Greenblatt]

Hi All,

I'm excited about using v8::Extension instead of CppBoundClass but the
JavaScript side of v8::Extension (via the |source| argument) seems a bit
magical to me.  Is there a document that explains the usage and capabilities
of v8::Extension in greater detail?  I have the following questions so far:

1. Can native functions be called directly by a renderer-loaded script, or
must calls to them always be wrapped within |source|-defined JS
objects/functions?
2. Are there any limits in scope or size to what can be done within a
|source|-defined script?
3. Is there a way to specify native getter/setter functions for a property
defined on the JS side?  For instance, "myobject.foo = bar" would somehow
call a natively defined "setFoo" function with the "bar" argument.  If this
isn't possible, are there any plans to support native properties directly?

Thanks,
Marshall

On Tue, Apr 28, 2009 at 9:39 PM, Mike Belshe  wrote:

> Yup.  I am not saying we need to get rid of all of it immediately; just put
> some comments in the header so that we don't use it *more*.
> Mike
>
>
> On Tue, Apr 28, 2009 at 6:38 PM, Feng Qian  wrote:
>
>> CppBindingClass was started for test_shell if I remember correctly,
>> and I think the functionality can be replaced by using NPAPI instead.
>> I had an implementation of replacing CppBindingClass by NPAPI in
>> test_shell (to avoid two implementations for JSC and V8), I don't
>> remember where the code went.
>>
>> On Tue, Apr 28, 2009 at 6:15 PM, Mike Belshe  wrote:
>> > I've felt this way for a while, and I figured I'd throw it out to see if
>> we
>> > all agree.
>> > I'm hoping we can deprecate CppBindingClass.  At this point, most
>> extensions
>> > are better served (I think!) via the v8::extension facility than the
>> > CppBindingObject.  If there are cases where this isn't true, I'd happily
>> > work on v8::extension to make it so it could be.
>> > If nobody objects, I hope we can agree to stop adding any new
>> > CppBindingClass based bindings, and then over time get rid of
>> > CppBindingObject altogether.
>> > Anyone feel strongly in opposition?
>> >
>> > 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: Setting Default Search Engine

[stylo~]

Does anyone have any idea why Chrome isn't working right?

On Apr 23, 1:32 pm, "stylo~"  wrote:
> Btw, I just triedhttp://mycroft.mozdev.org/youtube-search-plugins.html
> and those WILL install for me in Chrome, I get the popup, but I copied
> the script there to my page and it wouldn't work for me in Chome, only
> FF. I have no apparent js errors on my site in Chome either.
>
> Tried various scripts, none have worked in Chrome for me; currently
> using:
>
> function addOpenSearch(engine){
> try{window.external.AddSearchProvider("http://url.com/"+engine
> +".xml");}
> catch(e){alert("It didn't work on your browser, sorry.");}
>
> }
>
> I compared my xml file, and it seems fine. I copied it from the
> opensearch site, and works in FF. Here it is with the site changed:
>
> 
> http://a9.com/-/spec/opensearch/1.1/";>
> NAME
> NAME Search
> http://url.com/
> favicon.ico
> http://url.com/
> results.cfm?q={searchTerms}"/>
> 
>
> Ideas???
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Tech talk videos

[Jeremy Orlow]

Just wanted to let everyone know that we posted videos of 5 tech talks
related to Chromium.  There's a blog post on the Chromium Blog (
http://blog.chromium.org/2009/04/chromium-tech-talks.html), but here are
some direct links:
Darin Fisher  talking about
Chromium's multi-process architecture
Brett Wilson  talking about the
various layers of Chromium
Dimitri Glazkov  talking about
hacking on WebKit
Ben Goodger  talking about Views
(and how to write good tests for them)
Wan-Teh Chang and Eric Roman
 talking
about Chromium's network stack (and its history)

A big thanks to all the presenters who did the hard work.  :-)

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] Improving build time on Linux

[Scott Violet]

I was greatly disheartened when I set up a build environment on my
Linux box and realized it takes 36 seconds for scons to figure out
nothing has changed. After talking with Stephen he suggested the
following command line:

hammer --implicit-conversion app LOAD=app,browser

This dropped the time it takes scons to figure out nothing has changed
from 36 seconds to 6 seconds. Much more livable.

Caveats: this won't pick up changes you make to files outside of
browser, you'll need to modify the arguments to LOAD appropriately.

I've updated the Wiki with this information.

  -Scott

--~--~-~--~~~---~--~~
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: Some help with Layout Test regressions

[Dimitri Glazkov]

There's a change to DOMWindow.idl, which pretty much always warrants a
clobber on Win builds. I just clobbered WebKit builder, let's see what
happens.

:DG<

On Wed, Apr 29, 2009 at 4:11 PM, Jeremy Moskovich  wrote:
> Hi,
> Today's WebKit merge (42932:42994 -
> http://trac.webkit.org/changeset?new=42...@trunk&old=42...@trunk) has
> brought in some new regressions.
> If anyone has any spare cycles I'd really appreciate it if you might be able
> to look at these - http://crbug.com/11178:
> xss stuff:
> LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-addEventListener.html
> LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-shortcut.html
> LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-addEventListener.html
> LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-shortcut.html
> LayoutTests/http/tests/security/listener/xss-window-onclick-addEventListener.html
> LayoutTests/http/tests/security/listener/xss-window-onclick-shortcut.html
> chrome/http/tests/security/listener/xss-inactive-closure.html
> LayoutTests/http/tests/security/xss-eval.html
> and:
> DEBUG WIN : LayoutTests/transitions/repeated-firing-background-color.html =
> FAIL
> MAC : LayoutTests/fast/dom/Document/open-with-pending-load.html = CRASH
> Thanks,
> Jeremy
>
>
> >
>

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

[chromium-dev] Some help with Layout Test regressions

[Jeremy Moskovich]

Hi,
Today's WebKit merge (42932:42994 -
http://trac.webkit.org/changeset?new=42...@trunk&old=42...@trunk) has
brought in some new regressions.

If anyone has any spare cycles I'd really appreciate it if you might be able
to look at these - http://crbug.com/11178:

xss stuff:
LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-addEventListener.html
LayoutTests/http/tests/security/listener/xss-JSTargetNode-onclick-shortcut.html
LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-addEventListener.html
LayoutTests/http/tests/security/listener/xss-XMLHttpRequest-shortcut.html
LayoutTests/http/tests/security/listener/xss-window-onclick-addEventListener.html
LayoutTests/http/tests/security/listener/xss-window-onclick-shortcut.html
chrome/http/tests/security/listener/xss-inactive-closure.html
LayoutTests/http/tests/security/xss-eval.html

and:
DEBUG WIN : LayoutTests/transitions/repeated-firing-background-color.html =
FAIL
MAC : LayoutTests/fast/dom/Document/open-with-pending-load.html = CRASH

Thanks,
Jeremy

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

[Greg Spencer]

On Wed, Apr 29, 2009 at 12:22 PM, Mark Mentovai  wrote:

> I understand your problem.  You're saying "I have user-supplied data
> that I want to build a filename from," and "I have this pathname that
> I want to display back to the user."  I agree that it would be good to

have a way to handle these cases in base.  I don't know if FilePath
> proper is the right place to do it.  If we do it in FilePath, it still
> won't really be right.


OK, so it sounds like you're telling me not to use FilePath to represent
file paths from a disk for my purposes because they can't ever be converted
reliably to a particular encoding on Linux (which is a requirement for me,
because of the third party libraries that require a particular encoding).

That's fine, but what do I do instead?  Roll my own FilePath clone that has
some encoding assumptions?  I can do that, but it has the same issues as the
ones you're worried about with FilePath, so it seems better to solve the
issue in one place rather than have two versions that are both insufficient.
 Man, it would be better if FilePath could reliably know its encoding!  (I
realize that Linux makes this impossible, it just seems like it would be
better that way. :-)

Since Linux is the only platform where the encoding is unclear, what if we
did the best we could on Linux:

When constructing a FilePath from a char* string on Linux:
- Test the input string for values > 127 to determine if it's really just
ASCII (and if so, we're out of the woods).
- Then check LANG, LC_CTYPE, LC_ALL (through appropriate Linux APIs) for an
encoding that we can support, and note the encoding for later if we are
requested to do a conversion.
- If we run into an invalid sequence during a conversion, or an encoding we
can't convert from, then use a CHECK to crash.

This should work on most filenames, in almost all situations -- I'll bet
most filenames are ASCII, even on foreign systems, and the ones that aren't
ASCII have set LANG to something in /etc/profile, so all filenames created
by any app running on that machine should match that encoding.

Where they don't do that correctly, they're already getting garbage (and
should expect garbage) from any application they use, not just Chrome, since
there is no way *any *app can decode a path with multiple encodings in it,
or where the encoding is different than LANG (or LC_*) says it is.

Chrome already crashes like this when it encounters situations where it's
just impossible to know what's right, so it's consistent with Chrome's
behavior in other areas.


> it should be the caller's responsibility to only deal with user-created
> names with
> this interface.


What do you mean here?  Isn't that the case now with FilePath?  (It's the
file_util routines that actually read the filesystem and make FilePaths out
of them, afterall).  As for your suggestion to only deal with path
components, how would you propose to parse user-supplied paths into one of
these?


> > 2) I'd like to make it possible to instantiate a POSIX FilePath object on
> > Windows and a Windows FilePath on POSIX platforms.  This is because some
> > libraries (e.g. the zip library, or tar files), use POSIX semantics for
> > their paths even on Windows (I haven't seen a use case for Windows paths
> on
> > POSIX yet, actually).   This would make it possible to use the nice API
> that
> > FilePath has to manipulate paths appropriately for these other libraries.
> > This could be easily accomplished by having POSIX and Windows versions of
> > FilePath, and then typedef'ing FilePath differently on different
> platforms
> > to one of these versions.
>
> Sounds pretty Pythonic.
>
> FilePath already sort of has some support for this - it does a bunch
> of things based on feature macros, mostly so that as I was writing it,
> I could test the Windows semantics without having to (shudder) resort
> to running on Windows.  These could probably be adapted to do what
> you're asking.


Cool.


> > 3) It would be helpful to have real path normalization for each of the
> > platforms (although I know what a testing nightmare that can be).  I
> might
> > try and tackle this if people think it would be beneficial.
>
> It's also a specification and implementation nightmare.  Everyone has
> a different idea of what "normalization" means.  What's your idea?


Yes, I know it's a nightmare all around, but I think it would be useful to
have something that addresses this.  My idea would be the same as Python's
os.path.normpath, mainly because it's a well-tested, seasoned example with
test cases.  Windows also has a routine for this (PathCanonicalize) that
could be used (but I know it doesn't work for UNC paths).

> 4) Make sure we handle case sensitivity vs case preservation correctly.
> > It's unclear to me that FilePath does this correctly on the Mac -- Mac
> file
> > names are case preserving, but case insensitive, Unix filenames are both
> > (and windows filenames are neither :-).
>
> Again with the normalization. 

[chromium-dev] Re: Today we run zero LayoutTests in chrome

[Mike Belshe]

Whoops - I was wrong on this.  page cycler tests on the bbots do run chrome
now.
Bug on making v8::extensions less costly is http://crbug.com/11189

Mike

On Wed, Apr 29, 2009 at 3:02 PM, Mike Belshe  wrote:

> The more I think about this, the more trouble we might be in :-)
>
> Page cyclers are also misleading as they test Test Shell, not Chrome.
> To illustrate I ran a few tests with the moz page cycler:
>
>
> Test-shell:
>  29.41
> Chrome default:
>  37.43
> Chrome w/ Extensions and Web Workers 39.41// these
> are not enabled yet.
> Chrome w/o chrome-specific v8 extensions:  36.35
>
> Conclusions:
> * Chrome is 27% slower than test shell.  We knew this.
> * When we turn on extensions and web workers, Chrome will regress by 5.3%.
>  This would not be detected by our automated tests.
> * We already have a 3% hit due to using v8 extensions (Interval, CSI, etc)
> which we hadn't detected via automation.
>
> Mike
>
>
>
>
> On Wed, Apr 29, 2009 at 2:18 PM, Mark Larson (Google) 
> wrote:
>
>>
>>
>> On Wed, Apr 29, 2009 at 14:05, 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?
>>>
>>
>> No.
>>
>>
>>>
>>> 2) Should we create those plans :-)
>>>
>>
>> Based on the response to this thread, sounds like "yes." I filed a bug.
>>
>> I don't know what's involved to support running layout tests effectively
>> in the browser itself.
>>
>> If you have an idea of what needs to be done, please update
>> http://bugs.chromium.org/11186.
>>
>>>
>>> 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

[Mike Belshe]

The more I think about this, the more trouble we might be in :-)

Page cyclers are also misleading as they test Test Shell, not Chrome.
To illustrate I ran a few tests with the moz page cycler:


Test-shell:
 29.41
Chrome default:
 37.43
Chrome w/ Extensions and Web Workers 39.41// these
are not enabled yet.
Chrome w/o chrome-specific v8 extensions:  36.35

Conclusions:
* Chrome is 27% slower than test shell.  We knew this.
* When we turn on extensions and web workers, Chrome will regress by 5.3%.
 This would not be detected by our automated tests.
* We already have a 3% hit due to using v8 extensions (Interval, CSI, etc)
which we hadn't detected via automation.

Mike




On Wed, Apr 29, 2009 at 2:18 PM, Mark Larson (Google) wrote:

>
>
> On Wed, Apr 29, 2009 at 14:05, 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?
>>
>
> No.
>
>
>>
>> 2) Should we create those plans :-)
>>
>
> Based on the response to this thread, sounds like "yes." I filed a bug.
>
> I don't know what's involved to support running layout tests effectively in
> the browser itself.
>
> If you have an idea of what needs to be done, please update
> http://bugs.chromium.org/11186.
>
>>
>> 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: [extensions] API sprucing

[Ben Goodger (Google)]

I said this back when we set up the Chromium project before launching
the public beta. We deliberately decided not to change any of the code
(see all our include lines that start with CHROME_ or chrome/ etc.)

There should be no difficulty or careful judgment to be made here.
It's very simple. "In code, it's chrome." The emphasis is always on
consistency in google coding style. It seems any time a legal
department is involved in something the failplane takes off -_-.

-Ben

On Wed, Apr 29, 2009 at 2:04 PM, Evan Martin  wrote:
>
> On Wed, Apr 29, 2009 at 1:51 PM, Ben Goodger (Google)  
> wrote:
>> I'll raise this again:
>>
>> your js object that methods hang off should be called "chrome" not
>> "chromium"... we use "chrome" in all of our other API points
>> (chrome-ui:// and chrome-extensions:// protocol schemes, the user
>> agent string etc).
>>
>> FYI - Chromium is the name of the project, not the product, and should
>> never appear in code. I should probably add this to the style guide on
>> dev.chromium.org!
>
> It might be worth bringing this up as a top-level thread, as it's news to me.
> Not that I disagree, but grepping for "chromium" in the code indicates
> it might be a surprise to others.
>
> >
>

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

[Mark Larson (Google)]

On Wed, Apr 29, 2009 at 14:05, 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?
>

No.


>
> 2) Should we create those plans :-)
>

Based on the response to this thread, sounds like "yes." I filed a bug.

I don't know what's involved to support running layout tests effectively in
the browser itself.

If you have an idea of what needs to be done, please update
http://bugs.chromium.org/11186.

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

[Jeremy Moskovich]

+1 That would be extremely useful to the Mac port as well.
WebKit calls a bunch of OS X APIs that are not specced in regards to their
interaction with the Sandbox (i.e. they may try to open arbitrary files,
talk to the network, etc and fail in the process).  We have no good source
of test coverage for this at the moment.

In addition, if memory serves, we've run into a few sitatuions in the Mac
port where things have worked fine in test shell while failing in Chrome
(I'm sure similar situations exist on other platforms).

Running Layout Tests in Chrome would address both of these issues.

Best regards,
Jeremy

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

[Adam Barth]

This came up before when testing cross-site XHR and progress events.
The test_shell.exe code and the chrome.exe code are sufficiently
different that I had to run the tests in both to be sure we fixed the
bugs.

Adam


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

[Mike Belshe]

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

[Evan Martin]

On Wed, Apr 29, 2009 at 1:51 PM, Ben Goodger (Google)  wrote:
> I'll raise this again:
>
> your js object that methods hang off should be called "chrome" not
> "chromium"... we use "chrome" in all of our other API points
> (chrome-ui:// and chrome-extensions:// protocol schemes, the user
> agent string etc).
>
> FYI - Chromium is the name of the project, not the product, and should
> never appear in code. I should probably add this to the style guide on
> dev.chromium.org!

It might be worth bringing this up as a top-level thread, as it's news to me.
Not that I disagree, but grepping for "chromium" in the code indicates
it might be a surprise to others.

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

[Ben Goodger (Google)]

Thanks!

I updated the docs at http://dev.chromium.org/developers/coding-style

-Ben

On Wed, Apr 29, 2009 at 1:54 PM, Aaron Boodman  wrote:
> That's fine. As I said before, As it appears that nobody else does
> either, I'll make this a TODO to sweep through and fix.
>
> - a
>
> On Wed, Apr 29, 2009 at 1:51 PM, Ben Goodger (Google)  
> wrote:
>> I'll raise this again:
>>
>> your js object that methods hang off should be called "chrome" not
>> "chromium"... we use "chrome" in all of our other API points
>> (chrome-ui:// and chrome-extensions:// protocol schemes, the user
>> agent string etc).
>>
>> FYI - Chromium is the name of the project, not the product, and should
>> never appear in code. I should probably add this to the style guide on
>> dev.chromium.org!
>>
>> -Ben
>>
>> 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...
>>>
>>> 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.
>>>
>>> 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. 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.
>>>
>>> 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 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.
>>>
>>> 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.
>>>
>>> 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. Question: Do we need to send fromIndex?
>>>
>>>
>>> - 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] API sprucing

[Aaron Boodman]

That's fine. As I said before, As it appears that nobody else does
either, I'll make this a TODO to sweep through and fix.

- a

On Wed, Apr 29, 2009 at 1:51 PM, Ben Goodger (Google)  wrote:
> I'll raise this again:
>
> your js object that methods hang off should be called "chrome" not
> "chromium"... we use "chrome" in all of our other API points
> (chrome-ui:// and chrome-extensions:// protocol schemes, the user
> agent string etc).
>
> FYI - Chromium is the name of the project, not the product, and should
> never appear in code. I should probably add this to the style guide on
> dev.chromium.org!
>
> -Ben
>
> 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...
>>
>> 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.
>>
>> 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. 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.
>>
>> 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 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.
>>
>> 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.
>>
>> 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. Question: Do we need to send fromIndex?
>>
>>
>> - 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] API sprucing

[Ben Goodger (Google)]

I'll raise this again:

your js object that methods hang off should be called "chrome" not
"chromium"... we use "chrome" in all of our other API points
(chrome-ui:// and chrome-extensions:// protocol schemes, the user
agent string etc).

FYI - Chromium is the name of the project, not the product, and should
never appear in code. I should probably add this to the style guide on
dev.chromium.org!

-Ben

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...
>
> 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.
>
> 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. 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.
>
> 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 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.
>
> 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.
>
> 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. Question: Do we need to send fromIndex?
>
>
> - 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: Need help in finding a performance problem...

[Mike Pinkerton]

On Wed, Apr 29, 2009 at 3:39 PM, Marc-Andre Decoste  wrote:
> So I thought some people on this list might have some more hints to help me
> pinpoint the culprit quicker...
> Until then, I keep digging...

I'm pretty sure you've seen these, but from my discussions with Hyatt
on the Mac side, I'm pasting the things he told me to watch for:

"Your repaint code really should not just be doing a union.  That's
going to hurt your performance on DHTML and stuff.
Both Windows (HWNDs) and Mac (NSViews) will build up a region when you
do invalidates.  When you draw you can then grab individual decomposed
rects from the overall region or use the unioned bounding box.
Look at WebHTMLView and how it has a drawRect and drawSingleRect methods."

Though from talking to Darin a bit (our Darin), he was against
decomposing the rects since there was no obvious win given the async
nature of our repainting. I still think there's something here, but I
don't know enough about our layout and how we differ (purposely) from
WebKit to argue one way or the other.

"Make sure that your paint method is actually doing the recursive
layout of all frames before actually painting so that (a) your layout
info is up to date and (b) any additional rects added by the layouts
can become part of that current paint.  You'll probably want to study
the Windows WebView for this."

Again, I'm ignorant of what we do here, though I'm pretty sure we
already do this.

Hope that helps.

-- 
Mike Pinkerton
Mac Weenie
pinker...@google.com

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

[chromium-dev] Re: Changes to FilePath?

[Mark Mentovai]

Greg Spencer wrote:
> So there's currently no right way to do the conversion, but I still think
> that the FilePath constructor is probably in the best position to inspect
> LC_ALL, etc. and do as close to the right thing as possible.  I doubt most
> Linux developers even think about this, and so the chances that they will
> implement anything other than assuming that it's ASCII are slim -- this
> would allow us to at least implement a baseline for them.

Not doing the conversion is kinda the point.  Well, it's exactly the point.

(Hi, I'm the author of FilePath.)

If you've got an arbitrary path, it might be encoded in some scheme,
and it might not, and it might contain a mix of encodings.  The point
of FilePath is "we know it's a path and we don't necessarily know
anything else."  Chromium didn't used to have FilePath.  Everything
was a wstring which implied UTF-16/32, and the conversions implied
UTF-8 because we couldn't do anything smarter, and there was all sorts
of potential for messing things up.  Not a pretty story.  When
FilePath was born, the *Hack methods showed up to give us a way to
transition the old-style wstring APIs to new-style FilePath APIs at
reasonable cut points, instead of having to do everything all at once.

I understand your problem.  You're saying "I have user-supplied data
that I want to build a filename from," and "I have this pathname that
I want to display back to the user."  I agree that it would be good to
have a way to handle these cases in base.  I don't know if FilePath
proper is the right place to do it.  If we do it in FilePath, it still
won't really be right.  If we had something, it should probably be
made to operate only on single pathname components, and it should be
the caller's responsibility to only deal with user-created names with
this interface.

> 2) I'd like to make it possible to instantiate a POSIX FilePath object on
> Windows and a Windows FilePath on POSIX platforms.  This is because some
> libraries (e.g. the zip library, or tar files), use POSIX semantics for
> their paths even on Windows (I haven't seen a use case for Windows paths on
> POSIX yet, actually).   This would make it possible to use the nice API that
> FilePath has to manipulate paths appropriately for these other libraries.
> This could be easily accomplished by having POSIX and Windows versions of
> FilePath, and then typedef'ing FilePath differently on different platforms
> to one of these versions.

Sounds pretty Pythonic.

FilePath already sort of has some support for this - it does a bunch
of things based on feature macros, mostly so that as I was writing it,
I could test the Windows semantics without having to (shudder) resort
to running on Windows.  These could probably be adapted to do what
you're asking.

> 3) It would be helpful to have real path normalization for each of the
> platforms (although I know what a testing nightmare that can be).  I might
> try and tackle this if people think it would be beneficial.

It's also a specification and implementation nightmare.  Everyone has
a different idea of what "normalization" means.  What's your idea?

> 4) Make sure we handle case sensitivity vs case preservation correctly.
> It's unclear to me that FilePath does this correctly on the Mac -- Mac file
> names are case preserving, but case insensitive, Unix filenames are both
> (and windows filenames are neither :-).

Again with the normalization.  What do you want this stuff for?
What's your idea of how this should work?

Remember: FilePath is specified to be light and to never touch the
disk.  If you've got a disk-touching operation, it probably doesn't
belong in FilePath proper.

Mark

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

[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some "browser helper" process

[Michael Nordman]

Yup, I'm looking to work thru things in a similar fashion with anders
(original appcache author).

On Wed, Apr 29, 2009 at 11:53 AM, David Levin  wrote:
> I think how to split/refactor depends on the feature, understanding the
> current code, and working with the appropriate webkit dev.
> For workers, we thought about how/where it made sense to split the impl for
> chrome and talked with a...@webkit about it.  There was some iteration as we
> figured out things better and as he made suggestions and it has worked out
> fine so far.
>
> On Wed, Apr 29, 2009 at 11:49 AM, Michael Nordman 
> wrote:
>>
>> +chromium-dev
>>
>> Designing things in this front/back fashion and re-using the code
>> entirely in chrome removes at least one high-coefficient of friction
>> surface rubbing between the chromium and webkit teams. We will likely
>> pay a higher price up front, but it should pay dividends down the
>> road. Add an interesting feature and iphone, andriod, chrome, and
>> safari all pick it up.
>>
>> I'm worried about the logistics of pulling this off for the appcache
>> given the existing impl is live and in use in iphone and safari and
>> soon andriod. We're talking about 'refactoring' or 'replacing'
>> existing impls with new ones that support a remote backend. How can we
>> reduce the upfront cost?
>>
>> * maybe build these new impls out in webcore w/o disrupting the existing
>> impl
>> * use the new impl for chrome (and any other webkit consumer that
>> wishes to compile the new impls in would be free to do so)
>> * somewhere down the road, deprecate the existing impl in favor of the
>> new impl in webcore
>>
>> We haven't talked to the webkit guys about logistics like this, no
>> data on where their head is?
>>
>>
>
>
> >
>

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

[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some "browser helper" process

[David Levin]

I think how to split/refactor depends on the feature, understanding the
current code, and working with the appropriate webkit dev.
For workers, we thought about how/where it made sense to split the impl for
chrome and talked with a...@webkit about it.  There was some iteration as we
figured out things better and as he made suggestions and it has worked out
fine so far.


On Wed, Apr 29, 2009 at 11:49 AM, Michael Nordman wrote:

>
> +chromium-dev
>
> Designing things in this front/back fashion and re-using the code
> entirely in chrome removes at least one high-coefficient of friction
> surface rubbing between the chromium and webkit teams. We will likely
> pay a higher price up front, but it should pay dividends down the
> road. Add an interesting feature and iphone, andriod, chrome, and
> safari all pick it up.
>
> I'm worried about the logistics of pulling this off for the appcache
> given the existing impl is live and in use in iphone and safari and
> soon andriod. We're talking about 'refactoring' or 'replacing'
> existing impls with new ones that support a remote backend. How can we
> reduce the upfront cost?
>
> * maybe build these new impls out in webcore w/o disrupting the existing
> impl
> * use the new impl for chrome (and any other webkit consumer that
> wishes to compile the new impls in would be free to do so)
> * somewhere down the road, deprecate the existing impl in favor of the
> new impl in webcore
>
> We haven't talked to the webkit guys about logistics like this, no
> data on where their head is?
>
> >
>

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

[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some "browser helper" process

[Michael Nordman]

+chromium-dev

Designing things in this front/back fashion and re-using the code
entirely in chrome removes at least one high-coefficient of friction
surface rubbing between the chromium and webkit teams. We will likely
pay a higher price up front, but it should pay dividends down the
road. Add an interesting feature and iphone, andriod, chrome, and
safari all pick it up.

I'm worried about the logistics of pulling this off for the appcache
given the existing impl is live and in use in iphone and safari and
soon andriod. We're talking about 'refactoring' or 'replacing'
existing impls with new ones that support a remote backend. How can we
reduce the upfront cost?

* maybe build these new impls out in webcore w/o disrupting the existing impl
* use the new impl for chrome (and any other webkit consumer that
wishes to compile the new impls in would be free to do so)
* somewhere down the road, deprecate the existing impl in favor of the
new impl in webcore

We haven't talked to the webkit guys about logistics like this, no
data on where their head is?

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

[chromium-dev] Re: Need to run parts of WebCore in either the browser process or some "browser helper" process

[Peter Kasting]

On Wed, Apr 29, 2009 at 9:44 AM, Dimitri Glazkov wrote:

> I think it's a great idea and the only drawback I can see is the WTF
> dependency and the security implications, which shouldn't be anything
> we couldn't overcome.


Yes, the biggest worry I'd have here has little to do with whether it's our
code or WebKit's code running in the browser process, but just with making
sure data coming to this backend cannot be used to exploit the browser.
 That would be an equal concern no matter what the origin of the backend
source code.

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: Need to run parts of WebCore in either the browser process or some "browser helper" process

[Dimitri Glazkov]

I think it's a great idea and the only drawback I can see is the WTF
dependency and the security implications, which shouldn't be anything
we couldn't overcome.

The biggest challenges IMHO would be:

1) clearly identifying what backend and frontend mean and where the
separation occurs. I worry (perhaps without substance) that the
definition may vary from port to port.
2) general logistics of actually lopping off huge parts of existing
WebKit code and refactoring them in-flight.

But I totally think we (you) are up to the challenge :)

:DG<

On Tue, Apr 28, 2009 at 5:05 PM, Jeremy Orlow  wrote:
> Yes, yes, I know this is a "horrible idea", but please hear me out  :-)
>
> Last week, a couple of us (Darin F, Michael N, Jeremy M, and I) had lunch at
> Apple to talk to talk about sharing more code. HTML 5 brings with it a lot
> of APIs that reach outside of the top level browsing context boundary (i.e.
> the render process boundary in Chromium). We talked specifically about
> localStorage and appCache. Although I believe the following generalizes well
> for any such API, I recognize that there are some unique constraints for
> stuff like databases...so I'm not even going to talk about them right now.
> Anyhow...
> For a while now, I've looked at a bunch of ways to make localStorage
> multi-process aware, but really none of them have any hope except one:
> splitting localStorage into a frontend and backend. The frontend would be
> the portion in each renderer process that connects into the JS bindings. A
> single backend would store all the data and be shared by the frontends.
> Originally, my plan was to do this split and then write my own back end in
> the browser process, but there are several problems with this. From a
> technical standpoint, it's unclear how testing would work since our
> test_shell would be testing a different backend from what's in Chromium. It
> also means we have more code to maintain, and that code is completely off of
> WebKit's radar. It also makes Apple mad and Dimitri sad. So really, this
> doesn't seem like a good solution.
> Assuming the only viable solution is having several frontends talking to one
> backend (I'm confident this is true) and assuming having our own backend is
> not viable (this also seems true), then the only choice is for us to use the
> WebCore backend. We can't run this in any renderer process since the
> response times for browser->renderer communication are unbounded. So that
> leaves either the browser process or some browser helper process.
> Creating a helper process for the browser seems like a pretty interesting
> idea to me since there's already a lot of somewhat dangerous stuff running
> in the browser process. (The only thing I can remember right now is v8 for
> parsing .pac files, but I know there's more.) Basically, the helper process
> would be a sandboxed process where anything "dangerous" but not bound to a
> single renderer process would run. Ideally it would store little to no state
> so that the browser could easily restart it and resend any pending messages
> if it crashed. For localStorage, the backend (which is part of WebCore)
> would run there and all localStorage messages would be proxied through the
> browser process. The VFS could be used to retrieve file handles.
> The other option is to simply run part of WebCore's localStorage within the
> browser process. LocalStorage only depends on WTF, so this really isn't
> _that_ terrible of an idea. Thoughts?
> Anyhow, the WebKit guys we talked to like the idea of a split
> frontend/backend, especially if it means we'll continue sharing code. I
> believe Michael is going to be doing something similar for AppCache.
> 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: Need to run parts of WebCore in either the browser process or some "browser helper" process

[Peter Kasting]

On Wed, Apr 29, 2009 at 7:43 AM, David Levin  wrote:

> Ideally, there would be one implementation in webkit for html features
> which would allow multiple things:
> 1. Better compatibility across webkit impls.  This makes it easier for web
> devs.
> 2. Bugs fixes in one implementation help for both.
> 3. It helps move the web forward better because we may implement a feature
> and our webkit impls will get it.
> 4. The above means that we can make better use of layout tests both in
> knowing that the ones there should probably pass and contributing new ones
> too.
> 5. Giving back to the webkit community is a good thing.
> etc.
>

Totally agree on all these (although I think most are more applicable/have
more impact on the "frontend" piece of local storage than the "backend"
piece, but I could be wrong).  Bonus points for them generally being
technical rather than emotional reasons :D

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: Need to run parts of WebCore in either the browser process or some "browser helper" process

[Jeremy Orlow]

On Wed, Apr 29, 2009 at 7:43 AM, David Levin  wrote:

>
>
> On Wed, Apr 29, 2009 at 7:02 AM, Peter Kasting wrote:
>
>> On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow wrote:
>>
>>> Darin was there on that lunch and was actually the one who first
>>> suggested running parts of WebCore in the browser to me during a 1:1.  :-)
>>>
>>
>> Indeed, we're already planning to do it in other ways -- using a text
>> field as a directly-instantiable class in the UI, for example.
>>
>> I don't really have much of an opinion on this discussion except that I'm
>> not so negative about the original plan of writing our own backend as Jeremy
>> is.  Here are his objections: "From a technical standpoint, it's unclear
>> how testing would work since our test_shell would be testing a different
>> backend from what's in Chromium. It also means we have more code to
>> maintain, and that code is completely off of WebKit's radar. It also makes
>> Apple mad and Dimitri sad. So really, this doesn't seem like a good
>> solution."
>>
>> I'm not sure how test_shell matters w.r.t. testing this backend, since the
>> primary test of the backend (and the frontend?) would presumably be through
>> unittests (w/mocks where necessary), which test the code directly and don't
>> care what backend it's in. test_shell already doesn't have the same code as
>> the main browser for 100 other things.
>>
>> Having code to maintain off WebKit's radar is again not a new situation.
>> I'm not talking about forked stuff, just anything that isn't in WebKit.
>> Having the code in WebKit is a two-edged sword, since when it's there it's
>> gatekeepered on WebKit code review (not a big problem anymore since we have
>> a couple reviewers now) and the WebKit community doesn't seem to try to keep
>> their tree green. So IMO having code in WebKit is still just as much of a
>> maintenance burden on us except with the additional hurdle that it's not in
>> our direct tree.
>>
>> As far as making people mad, feh. Let's decide the right implementation
>> first.
>>
>
> "making people mad" is a simplification of a complex set of things.
>
> Ideally, there would be one implementation in webkit for html features
> which would allow multiple things:
> 1. Better compatibility across webkit impls.  This makes it easier for web
> devs.
> 2. Bugs fixes in one implementation help for both.
> 3. It helps move the web forward better because we may implement a feature
> and our webkit impls will get it.
> 4. The above means that we can make better use of layout tests both in
> knowing that the ones there should probably pass and contributing new ones
> too.
> 5. Giving back to the webkit community is a good thing.
> etc.
>

David hit on most of the points I planned to make.  "making people mad" was
obviously a gross oversimplification of the situation.  :-)

One thing that I forgot to mention was that the WebKit guys are now starting
to think about making WebKit more attractive to others that want to use a
multi-process model.  To me, this is a very noble goal, and fits in with the
original goals of Chromium, so it's something we should try to support--even
if it means a bit more work for us.


>
>
>> But even if the original plan is IMO not so bad, I'm not opposed to the
>> new plans either. People like Darin are much more qualified to comment on
>> what would be *best* and I will be OK with whatever gets decided.
>>
>
I hate speaking for Darin because it's possible that there's some details
here he did not agree with, but I'm pretty sure that most of this is exactly
what we talked about, and that he was supportive of it.

I agree that having our own backend still _could_ be the way to go, but I
guess I'd like to give this a shot first.

Note also that localStorage is actually a pretty simple example.  It'll be
interesting to see what things look like for other features, like AppCache.
There, having our own backend probably has more impact, though I'm not sure
if it's a positive or negative impact.

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: Need to run parts of WebCore in either the browser process or some "browser helper" process

[David Levin]

On Wed, Apr 29, 2009 at 7:02 AM, Peter Kasting wrote:

> On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow  wrote:
>
>> Darin was there on that lunch and was actually the one who first suggested
>> running parts of WebCore in the browser to me during a 1:1.  :-)
>>
>
> Indeed, we're already planning to do it in other ways -- using a text field
> as a directly-instantiable class in the UI, for example.
>
> I don't really have much of an opinion on this discussion except that I'm
> not so negative about the original plan of writing our own backend as Jeremy
> is.  Here are his objections: "From a technical standpoint, it's unclear
> how testing would work since our test_shell would be testing a different
> backend from what's in Chromium. It also means we have more code to
> maintain, and that code is completely off of WebKit's radar. It also makes
> Apple mad and Dimitri sad. So really, this doesn't seem like a good
> solution."
>
> I'm not sure how test_shell matters w.r.t. testing this backend, since the
> primary test of the backend (and the frontend?) would presumably be through
> unittests (w/mocks where necessary), which test the code directly and don't
> care what backend it's in. test_shell already doesn't have the same code as
> the main browser for 100 other things.
>
> Having code to maintain off WebKit's radar is again not a new situation.
> I'm not talking about forked stuff, just anything that isn't in WebKit.
> Having the code in WebKit is a two-edged sword, since when it's there it's
> gatekeepered on WebKit code review (not a big problem anymore since we have
> a couple reviewers now) and the WebKit community doesn't seem to try to keep
> their tree green. So IMO having code in WebKit is still just as much of a
> maintenance burden on us except with the additional hurdle that it's not in
> our direct tree.
>
> As far as making people mad, feh. Let's decide the right implementation
> first.
>

"making people mad" is a simplification of a complex set of things.

Ideally, there would be one implementation in webkit for html features which
would allow multiple things:
1. Better compatibility across webkit impls.  This makes it easier for web
devs.
2. Bugs fixes in one implementation help for both.
3. It helps move the web forward better because we may implement a feature
and our webkit impls will get it.
4. The above means that we can make better use of layout tests both in
knowing that the ones there should probably pass and contributing new ones
too.
5. Giving back to the webkit community is a good thing.
etc.


> But even if the original plan is IMO not so bad, I'm not opposed to the new
> plans either. People like Darin are much more qualified to comment on what
> would be *best* and I will be OK with whatever gets decided.
>
> 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: Need to run parts of WebCore in either the browser process or some "browser helper" process

[Peter Kasting]

On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow  wrote:

> Darin was there on that lunch and was actually the one who first suggested
> running parts of WebCore in the browser to me during a 1:1.  :-)
>

Indeed, we're already planning to do it in other ways -- using a text field
as a directly-instantiable class in the UI, for example.

I don't really have much of an opinion on this discussion except that I'm
not so negative about the original plan of writing our own backend as Jeremy
is.  Here are his objections: "From a technical standpoint, it's unclear how
testing would work since our test_shell would be testing a different backend
from what's in Chromium. It also means we have more code to maintain, and
that code is completely off of WebKit's radar. It also makes Apple mad and
Dimitri sad. So really, this doesn't seem like a good solution."

I'm not sure how test_shell matters w.r.t. testing this backend, since the
primary test of the backend (and the frontend?) would presumably be through
unittests (w/mocks where necessary), which test the code directly and don't
care what backend it's in. test_shell already doesn't have the same code as
the main browser for 100 other things.

Having code to maintain off WebKit's radar is again not a new situation. I'm
not talking about forked stuff, just anything that isn't in WebKit. Having
the code in WebKit is a two-edged sword, since when it's there it's
gatekeepered on WebKit code review (not a big problem anymore since we have
a couple reviewers now) and the WebKit community doesn't seem to try to keep
their tree green. So IMO having code in WebKit is still just as much of a
maintenance burden on us except with the additional hurdle that it's not in
our direct tree.

As far as making people mad, feh. Let's decide the right implementation
first.

But even if the original plan is IMO not so bad, I'm not opposed to the new
plans either. People like Darin are much more qualified to comment on what
would be *best* and I will be OK with whatever gets decided.

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: webkit gyp conversion planned for tomorrow (Tuesday) evening

[Bradley Nelson]

Hi All,
That went less well than I'd hoped
Things are rolled back to where they were before, save for a few gyp
file+tool fixes that could be left in.
This time was closer, non-windows stayed green (until I checkd in a bad gyp
change...),
1 failed ui_test, and several dozens of webkit_tests.

Got started a little late due to some left overs with the v8 repo switch,
followed by my reluctance to pull the trigger.
I'd have probably kept things in were it not for the range of webkit_tests
and the lateness of the hour.
I intend to try again tomorrow night, (assuming I can make sense of the
postmortem) unless there are objections.

yawn...

-BradN


On Tue, Apr 28, 2009 at 5:09 PM, Bradley Nelson wrote:

> Hi All,
> Due to some last minute integration issues this will get pushed to 8pmPDT.
> Wish me luck!
>
> -BradN
>
>
> On Mon, Apr 27, 2009 at 4:51 PM, Steven Knight  wrote:
>
>> Brad Nelson is planning to close the tree some time tomorrow night
>> (Tuesday 28 April) to land the conversion of webkit to gyp-based build.
>>
>> To get out from under playing constant catch-up with the rapidly-moving
>> code base, it's possible that we'll leave the tree converted even if there
>> are a small number--two or three?--of unit test failures.  (By comparison,
>> the last attempt to convert webkit had about five unit test failures plus a
>> V8 performance regression -- since fixed -- that tipped the scales in favor
>> of backing out the change.)
>>
>> If there are any outstanding problems, we'll send out an announcement--and
>> could really use help making sure we weed out any known (and unkown)
>> problems as quickly as possible.
>>
>> After we let the webkit conversion soak a bit, we'll schedule the
>> conversion of the chrome/ subdirectory itself, based on how things have gone
>> with webkit.
>>
>> WHILE WE'RE STILL IN TRANSITION:  please continue to add new webkit/ and
>> chrome/ files to *both* Visual Studio and the {webkit,chrome}.gyp files.  We
>> have just recently caught up both of these components with the last few
>> weeks of added and deleted files.  It helps immensely if we don't have to
>> keep tracking these down  by hand.
>>
>> If the planned timing is bad for you, let me or Brad know.
>>
>> Thanks,
>>
>> --SK
>>
>
>

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