[chromium-dev] Re: buildbot failure in Chromium on Chromium Builder (dbg), revision 36644

[Jeremy Orlow]

on it.  Sorry.

On Wed, Jan 20, 2010 at 10:52 AM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "compile" on "Chromium Builder (dbg)"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729
>
> Revision: 36644
> Blame list: jor...@chromium.org
>
>  Chromium Builder (dbg)
> Build 
> 15729
> svnkill
> stdio
>   update
> scripts
> stdio
> taskkill
> stdio
> update
> stdio
> compile
> failed
> stdio
>
> Changed by: *jor...@chromium.org*
> Changed at: *Wed 20 Jan 2010 10:50:07*
> Branch: *src*
> Revision: 
> *36644*
> Changed files:
>
>- *chrome/app/generated_resources.grd*
>- *chrome/browser/cookies_tree_model.cc*
>- *chrome/browser/cookies_tree_model.h*
>- *chrome/browser/gtk/options/cookies_view.cc*
>- *chrome/browser/gtk/options/cookies_view.h*
>- *chrome/browser/in_process_webkit/dom_storage_context.cc*
>- *chrome/browser/in_process_webkit/dom_storage_context.h*
>- *chrome/browser/views/options/cookies_view.cc*
>- *chrome/browser/views/options/cookies_view.h*
>- *chrome/chrome_browser.gypi*
>- *chrome/chrome_tests.gypi*
>
> Comments:
>
> Adds local storage nodes to cookie tree model and cookies view.
>
> BUG=none
> TEST=The show cookie dialog box should have a new node "local storage" when 
> appropriate. When selected, it should display details of local storage (name, 
> size on disk, last modified) in the details frame.
>
> Landing for Marcus
> Original CL: http://codereview.chromium.org/523139/show
>
> Review URL: http://codereview.chromium.org/546081
>
> Properties:
>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] how to disable SVG when building chromium

[Jeremy Orlow]

Oh, according to the file, build/features_override.gypi will also do the
trick.

On Mon, Jan 18, 2010 at 11:53 PM, Jeremy Orlow  wrote:

> http://trac.webkit.org/browser/trunk/WebKit/chromium/features.gypi
>
> WebKit is under third_party/WebKit in the src tree
>
> On Mon, Jan 18, 2010 at 11:45 PM, n179911  wrote:
>
>> Hi,
>>
>> Webkit has an option to disable SVG build with the executable. Can you
>> please tell me how can I disable SVG when build chromium?
>>
>> 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 Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] how to disable SVG when building chromium

[Jeremy Orlow]

http://trac.webkit.org/browser/trunk/WebKit/chromium/features.gypi

WebKit is under third_party/WebKit in the src tree

On Mon, Jan 18, 2010 at 11:45 PM, n179911  wrote:

> Hi,
>
> Webkit has an option to disable SVG build with the executable. Can you
> please tell me how can I disable SVG when build chromium?
>
> 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 Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Ajax maximum response size

[Jeremy Orlow]

Either way, it seems like these are bugs that are worthy of being filed.

Greg, any advice?

J

On Fri, Jan 15, 2010 at 10:20 AM, Rryk  wrote:

> Hello,
>
> I am implementing 3D rendering engine for Chromium and I need to
> download huge scenes via Ajax. However I've noticed that asyncronous
> Ajax requests are limited to 7-8 MB in size. If I try to download more
> -- tab crashes (and in --single-process-mode everything crashes in
> onNoMemory function).
>
> Synchronous requests work better -- I was able to download 100M file,
> but the browser footprint in memory grew like a monster -- it took a
> whole of 3GB to download a single 100M file. Interesting enough that
> after downloading it it remained to take all this place. Does it make
> 30 copies out of it? There should be something wring with it. I am
> using jQuery for ajax and the code is here http://tinypaste.com/6f7d9.
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Re: updates to tech talks page: added link to "Exploring Chrome Internals" slide deck, etc

[Jeremy Orlow]

On Wed, Jan 13, 2010 at 3:55 PM, Chase Phillips  wrote:

> On Wed, Jan 13, 2010 at 14:50, Chase Phillips  wrote:
>
>> Darin's June 2, 2009 Google I/O "Exploring Chrome Internals" presentation
>> slide deck is now available from
>> http://sites.google.com/a/chromium.org/dev/developers/tech-talk-videos.
>>
>> Along with that, I gave the page a facelift.  Will be easier to change and
>> include extra info about talks going forward.
>>
>
> With the help of Peter Kasting and Eric Roman (thanks!), I catalogued as
> complete a list of inaccuracies between what the slides describe and the
> current Chrome version:
>
> Slide 18: With new painting and scrolling optimizations, this process is
> more complex than what's shown
> Slide 23: Chrome 3 released in 2009, uses a WebKit version not yet in any
> current Safari release
> Slide 24: 6 WebKit reviewers @chromium.org, 37 WebKit committers @
> chromium.org, WebKit API is done
> Slide 25: OWP Local and session storage: completed
>

LocalStorage went out in mstone 4, but session storage is slated for mstone
5.  (Which is a safe bet, considering I'm landing some of the final code to
make it happen as we speak.  :-)


> Slide 27: Networking feature parity and sparse caching: completed
>
> Please update with any corrections and other differences if you see them.
>
> Chase
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] RFC: Extensions Incognito

[Jeremy Orlow]

On Wed, Jan 13, 2010 at 3:48 PM, Antony Sargent  wrote:

> What if the Incognito profile started with a copy-on-write version of
> extensions' localStorage? That way extensions in Incognito mode would see
> the writes they just made, but changes would not persist beyond Incognito
> mode.


This actually wouldn't be too hard to do and probably makes the most sense.
 (SessionStorage, which shares 99% of the same code, already uses COW when
you duplicate tabs.)


> Then we could either add the messaging API for Incognito <-> Regular
> extension communication, or add an explicit settings API that would have the
> same storage regardless of Incognito mode.
>
>
>
> On Wed, Jan 13, 2010 at 3:30 PM, Matt Perry wrote:
>
>> On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth  wrote:
>>
>>> Have you considered how incognito interacts with extensions that have
>>> NPAPI components?  It might not be feasible to create a second, isolated
>>> instance of those extensions because the NPAPI component has direct access
>>> to system calls.
>>
>>
>> Good point, I hadn't considered that. This is similar to Drew's point
>> about a systray API.
>>
>> I wonder if read-only access to localStorage will be confusing to authors.
>>>  I can imagine extensions doing wonky things if they assume they can write
>>> to localStorage.  Maybe we should have a separate API for reading
>>> information from the non-incognito localStorage?
>>>
>>
>> Would localStorage start off empty (and have no persistence) as it does in
>> regular renderers, then? I think read-only access to localStorage is
>> important because extensions currently use it for storing preferences, and
>> ideally they would share settings without the extension explicitly
>> supporting it.
>>
>> Adam
>>>
>>>
>>>
>>> On Wed, Jan 13, 2010 at 2:28 PM,  wrote:
>>>
  I've shared Extensions 
 Incognito
 Message from mpcompl...@chromium.org:

 Hi all,

 I'm working on adding support for running extensions in incognito mode 
 (bug: http://code.google.com/p/chromium/issues/detail?id=20175 ). Here is 
 a proposal for how it might work. Any and all feedback is welcome.

  Click to open:

- Extensions 
 Incognito


 Google Docs makes it easy to create, store and share online documents,
 spreadsheets and presentations.
 [image: Google Docs logo] 

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

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

Re: [chromium-dev] WebKit Gardeners <3 rebaseline.py -w

[Jeremy Orlow]

Same here.

On Fri, Jan 8, 2010 at 4:51 PM, Drew Wilson  wrote:

> Do you find that you have time to figure out if rebaselining a test is the
> right thing to do while you're actively gardening? Maybe I just work too
> slowly, but I often find that if I'm trying to rebaseline on the fly, it
> requires that I do at least *some* investigation of the test failure to make
> sure I'm not rebaselining in an error (or rebaselining a test that is merely
> flaky) which slows me down enough that I fall behind and inevitably am
> crushed by the WebKit juggernaut.
>
> -atw
>
> On Fri, Jan 8, 2010 at 4:33 PM, Dimitri Glazkov wrote:
>
>> Before heading out for the weekend, I just want to mention this:
>> rebaseline tool really, really rocks. And yesterday I discovered an
>> option that I, to my shame, hadn't seen before: -w. This option pulls
>> baselines from the canary. It's like getting test expectations from
>> the future!
>>
>> In other words, there are no more excuses for you, dear WebKit
>> gardeners, to commit those ghastly BUG_SOMENAME entries in
>> test_expectations.
>>
>> The workflow is mind-numbingly simple:
>>
>> 1) Identify tests that need rebaselining prior to rolling
>> 2) Add these tests to test_expectations.txt as if you were to commit
>> them -- except add a REBASELINE flag next to BUG_SOMENAME
>> 3) Run rebaseline -w
>> 4) Make sure that the tool ran and removed these entries from
>> test_expectations.txt
>> 5) Create CL -- you will notice how new expected result files are
>> conveniently added for you.
>> 6) Enjoy regression-free WebKit roll.
>>
>> Big thanks to Victor Wang for this amazing instrument of everlasting
>> harmony. Send him your accolades. Or cash. If you find bugs/quirks,
>> fix them.
>>
>> :DG<
>>
>> P.S. As part of gardener/sheriff process overhaul, I will be adding
>> these and other helpful tips/hints to our gardening doc.
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Jeremy Orlow]

What about renaming the function?  EmptyStringHACK() or something?

On Thu, Jan 7, 2010 at 1:49 PM, Peter Kasting  wrote:

> On Thu, Jan 7, 2010 at 1:43 PM, Jeremy Orlow  wrote:
>
>> You ignored the second half of my suggestion.
>>
>
> The second half of your suggestion leaks memory.  When we have easy and
> elegant ways to avoid memory leaks, it behooves us to use them.
>
> It also seems like a poor idea to me to suggest that, potentially, any
> function returning a string by reference might have to have its own memory
> leak, or allocation code, or static object, if it needs to be able to return
> an empty object.  Even if we could do that with no ill consequences, it
> would be nice to avoid it.
>
> After my patch, the total number of calls of these functions in the entire
> codebase is something like 10 instances.  They're rare enough to be
> invisible to most people and unusual otherwise.
>
> PK
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Jeremy Orlow]

On Thu, Jan 7, 2010 at 1:38 PM, Peter Kasting  wrote:

> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow  wrote:
>
>> (As discussed during lunch...)  Why not just do this in this case and
>> remove EmptyString() altogether?
>>
>> const std::string& MyClass::foo() const {
>>   static std::string empty = EmptyString();
>>   return (everything == OK) ? member_string : empty;
>> }
>>
>
> This is illegal per the Google style guide:
>
> "Objects with static storage duration, including ... function static
> variables, must be Plain Old Data (POD): only ints, chars, floats, or
> pointers, or arrays/structs of POD. ... This rule completely disallows
> vector (use C arrays instead), or string (use const char [])."
>
> If you see code like this in our codebase, please fix it to not use
> static/global non-POD types.
>

You ignored the second half of my suggestion.

IIRC there's a macro (maybe it was only in WebKit) to get around this issue
as well.

J


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

Re: [chromium-dev] Replicated State among tabs in Chromium

[Jeremy Orlow]

And before you suggest using software transactional memory, keep in mind
that side effects (XHRs and other network activity for example)
are prevalent in normal JavaScript usage.

I don't mean to discourage you too muchespecially if you were interested
in digging really deeply into this stuff...but I can assure you that a lot
of the more obvious, high level solutions to this stuff have been explored
many times over.  I think some of the more focused uses within specific
implementations might be a better place to start.

On Thu, Jan 7, 2010 at 1:36 PM, Charlie Reis  wrote:

> The catch is that you don't know what locks you need to acquire in advance,
> especially in the presence of things like eval.  (And of course, you can't
> roll back any JavaScript you've already run, so you would need to know the
> locks in advance.)
>
> Charlie
>
>
> On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel  wrote:
>
>> Hmm, I wonder if strict two-phase locking can be here to solve this?
>>
>> Fady
>>
>>
>>>
>>> That's correct.  However, Fady is referring to an observation in my paper
>>> that race conditions are actually possible in cross-window JavaScript calls
>>> in Internet Explorer and Opera.  Those browsers allow pages in different
>>> windows to run in separate threads, even if they are from the same site and
>>> can easily call into each other.  From my tests, it appears that IE at least
>>> tries to avoid race conditions by blocking one page until the other
>>> finishes, but it allows the race if a deadlock occurs.
>>>
>>> You can test this fairly easily by calling a long-running function in
>>> another page that is repeatedly calling the function itself.  In Opera, both
>>> pages' threads will be in the function at once.  In IE, the first page will
>>> be blocked until the second finishes, unless the second page tries to call
>>> back into the first page at the end of its function.  That would be a
>>> deadlock, so instead they allow the data race.
>>>
>>> I don't think the spec allows for these races-- as people have mentioned,
>>> JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
>>> races by only putting pages that can't communicate on different
>>> threads/processes.
>>>
>>> Charlie
>>>
>>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Jeremy Orlow]

(As discussed during lunch...)  Why not just do this in this case and remove
EmptyString() altogether?

const std::string& MyClass::foo() const {
  static std::string empty = EmptyString();
  return (everything == OK) ? member_string : empty;
}

I forget if this runs the constructor on first use or when the app starts
up.  If it's the latter and you care, you can even just make it a null
pointer and allocate it on first use.

No matter what PSA or comments you write, someone will use it again if it's
there.

J

On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting  wrote:

> If you have ever used any of the EmptyXXX() functions, or ever will, please
> read on.
>
> These functions (in string_util.h and gurl.h) are meant for a single,
> specific use case:
>
> const std::string& MyClass::foo() const {
>   return (everything == OK) ? member_string : EmptyString();
> }
>
> Here you cannot return "string()", because it's destroyed before the
> function returns, and the caller receives garbage; and you don't want to
> have the function return by value, because you can access the member
> variable directly and save a copy.  The utility functions give you a global
> empty string that you can safely return a const reference to.
>
> DON'T USE THESE OUTSIDE THIS CASE.  You should never use these as
> initializers, arguments to functions, or return values in functions that
> return by value.  Just use the default constructor; that's what it's there
> for.
>
> I have a change out for review that removes the erroneous uses of these
> from our codebase and clarifies the comment on their declaration, but it's
> worth calling this out directly so they don't creep back in.
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Jeremy Orlow]

On Thu, Jan 7, 2010 at 1:10 PM, Charlie Reis  wrote:

>
>
> On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie  wrote:
>
>>
>>
>> On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel  wrote:
>>
>>> Charles, I've read your paper and ultimately I think my goal may be
>>> somewhere along the lines of making the DOM tree thread-safe by applying my
>>> research in iterators and lock-free data structures.
>>>
>>>  A tricky question: What can be parallelized here? What level of
>>> atomicity is required by scripts.
>>>
>>> Does Javascript even provide a means to do any kind of concurrency
>>> control? Any locking mechanism? The paper suggests javascript knows nothing
>>> about multithreading (Disclaimer: I'm NOT a javascript expert).
>>>
>>> If not, what level of implicit atomicity does the browser need to provide
>>> for javascript? That is to say, can we allow two functions manipulating the
>>> same DOM interleave on a per statement basis? I'm  a bit worried that there
>>> are limitations in the language itself that make this problem extend beyond
>>> a consistent iteration problem.
>>>
>>> Do you have an example or two of race conditions you've seen in Internet
>>> Explorer? Heck, if you can provide me with javascript code samples that
>>> demonstrate issues so I can better understand what's going on that would be
>>> awesome.
>>>
>>
>> Javascript absolutely expects to be single-threaded, and Javascript
>> programmers expect it even more so.
>>
>>
>
> That's correct.  However, Fady is referring to an observation in my paper
> that race conditions are actually possible in cross-window JavaScript calls
> in Internet Explorer and Opera.  Those browsers allow pages in different
> windows to run in separate threads, even if they are from the same site and
> can easily call into each other.  From my tests, it appears that IE at least
> tries to avoid race conditions by blocking one page until the other
> finishes, but it allows the race if a deadlock occurs.
>
> You can test this fairly easily by calling a long-running function in
> another page that is repeatedly calling the function itself.  In Opera, both
> pages' threads will be in the function at once.  In IE, the first page will
> be blocked until the second finishes, unless the second page tries to call
> back into the first page at the end of its function.  That would be a
> deadlock, so instead they allow the data race.
>
> I don't think the spec allows for these races-- as people have mentioned,
> JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
> races by only putting pages that can't communicate on different
> threads/processes.
>

There are 2 exceptions in Chrome and IE (and maybe Opera?): Cookies and
LocalStorage.

The spec attempts to solve both of these with a "Storage Mutex" which
basically must be taken on the first access to a cookie or localStorage and
must not be released until the current script execution ends.  The network
stack is also supposed to take this lock when reading or writing cookies.
 The single mutex is shared across the entire browser.

A LOT of time and effort has been spent on coming up with a better answer,
but there are a lot of constraints to the problem (not all of them
technical) and I've pretty much given up hope of anything better replacing
it in the spec.

That said, we have no intention of being the first to implement the storage
mutex in Chrome, and I know of no one else intending to implement it either.
 So until then, cookie and localStorage access is simply racy (in Chrome,
IE, and maybe Opera).

Charlie
>
>
>
>>> Thanks,
>>>
>>> Fady
>>>
>>> On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis wrote:
>>>
 Peter's right: as far as I understand, parsing, rendering, and script
 execution are all expected to take place on a single thread of execution.
  This includes any calls across multiple pages, which is why we place
 "connected" same-site pages (those in the same unit of related browsing
 contexts) in the same process.  If one page calls a function in another
 page, we don't want to allow data races.

 For more info on the decisions we've made about which pages go to which
 process, see:
 http://dev.chromium.org/developers/design-documents/process-models

 We also have a Eurosys 2009 paper on the topic:
 http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf

 Hope that helps,
 Charlie


 On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting wrote:

> On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel wrote:
>
>> So a script cannot execute concurrently with the traversal of the DOM
>> tree? Could this be a performance bottleneck?
>
>
> Pretty much nothing in the renderer can execute concurrently with other
> things in the renderer.  There have been academic papers published about
> trying to parallelize parts of web rendering, and some though experiments
> from various smart Mozilla and Web

Re: [chromium-dev] [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

On Wed, Dec 30, 2009 at 4:15 PM, Nico Weber  wrote:

> I thought there were two separate issues here:
>
> 1.) The specific webgl switch. Darin suggested that it should imply
> --disable-sandbox until webgl works in the sandbox. This way, people
> don't have to add --disable-sandbox explicitly and will automatically
> be safe once webgl works in the sandbox.
>

I agree that this is a separate issue and that doing this would probably be
a good idea.

2.) If / how --enable-sandbox should uglify the UI. Your list is
> missing this suggestion by vandebo:
>
> """Instead of telling people to use --no-sandbox on the blog, we could
> tell them to use a new flag,  --disable-sandbox-until MM/DD/.  It
> could limit the maximum amount of time the sandbox was disabled, to
> say two weeks.  After that, the sandbox would automatically be
> reenabled."""
>
> (which could be in addition to the other stuff, if people think it's a
> good idea)
>

I definitely think this would need to be in addition to other (noisy) UI.
 Personally, I think having stuff like --enable-webgl implying disabling the
sandbox is a better plan though since it's hard to predict when the feature
will be complete and a user won't delete the --enable-webgl flag bug forget
to delete the --disable-sandbox-until flag.


> On Wed, Dec 30, 2009 at 3:56 PM, Jeremy Orlow  wrote:
> > On Wed, Dec 30, 2009 at 3:43 PM, Peter Kasting 
> wrote:
> >>
> >> On Wed, Dec 30, 2009 at 3:22 PM, Jeremy Orlow 
> wrote:
> >>>
> >>> I just got back from vacation and would like to take action on this.  I
> >>> read through the thread, but I don't see any sort of consensus on what
> to
> >>> do.  Here are the options as I see them:
> >>> 1) Modal dialog box.  Bad for debugging, will probably just be clicked
> >>> through by users, and not very good for users who leave the browser
> open for
> >>> long stretches of time.  I'd say it's not a good solution.
> >>
> >> I thought it was clear that this was the consensus best idea (see
> Darin's,
> >> Glen's, my posts for example).
> >
> > Glen didn't support it (only didn't object) and you and Darin were the
> only
> > ones that supported it.  A couple of us thought it was a bad idea.  I
> don't
> > see how this is anything close to a consensus.
> >
> >>
> >>  I don't see how it's "bad for debugging" (Viet-Trung's objection makes
> >> absolutely no sense to me),and we don't care about the edge case of
> users
> >> who both use --no-sandbox and never restart (this works well enough even
> for
> >> restarting once every several weeks, which takes care of practically
> >> everyone).  Clicking through is enough of an annoyance to serve our
> >> purposes, and this is trivially simple to add (simpler by far than all
> other
> >> options including an infobar).
> >>>
> >>> 2) Info bar.  This seems like one of the more popular options at the
> >>> moment.
> >>
> >> This is a bad idea, we shouldn't do it.  It's not as annoying as a modal
> >> dialog, it has problems with clashing with other infobars on start.
> >>  Basically it's inferior to a modal dialog in every way.
> >
> > FYI: The ui-leads (in an off-list thread) seem to like Evan's initial
> patch
> > that goes this route.
> >
> >>>
> >>> 3) Add some other persistent UI like the incognito spy guy, an annoying
> >>> theme (that overrides whatever you have selected), or something else.
>  This
> >>> seems like a pretty good option to me, but there hasn't been too much
> >>> discussion around it.  What type of UI would be the best?  Is this a
> good
> >>> option?
> >>
> >> No, we shouldn't do this.  Way too much effort and code (think about
> >> making this work on three OSes and with custom themes), we just want
> >> something trivial.
> >
> > Themes are cross platform.  Though I agree that this route may be more
> > trouble than it's worth.
> >>>
> >>> 4) Add some warning to the new tab page.  Once again, no one's really
> >>> thought about this seriously.  Any thoughts?
> >>
> >> Again, inferior to the other options.  Doesn't work well for users who
> >> don't start with the NTP (or ones who never see it -- I don't, I don't
> use
> >> ctrl-t or the new tab button, I use middle-click and alt-enter).
> >
> > Fair enough.
> >
> >>
> >> If you're planning to implement something, please implement the dialog.
> >
> > I'd like to hear what others think as well.
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

On Wed, Dec 30, 2009 at 3:43 PM, Peter Kasting  wrote:

> On Wed, Dec 30, 2009 at 3:22 PM, Jeremy Orlow  wrote:
>
>> I just got back from vacation and would like to take action on this.  I
>> read through the thread, but I don't see any sort of consensus on what to
>> do.  Here are the options as I see them:
>>
>> 1) Modal dialog box.  Bad for debugging, will probably just be clicked
>> through by users, and not very good for users who leave the browser open for
>> long stretches of time.  I'd say it's not a good solution.
>>
>
> I thought it was clear that this was the consensus best idea (see Darin's,
> Glen's, my posts for example).
>

Glen didn't support it (only didn't object) and you and Darin were the only
ones that supported it.  A couple of us thought it was a bad idea.  I don't
see how this is anything close to a consensus.


>  I don't see how it's "bad for debugging" (Viet-Trung's objection makes
> absolutely no sense to me),and we don't care about the edge case of users
> who both use --no-sandbox and never restart (this works well enough even for
> restarting once every several weeks, which takes care of practically
> everyone).  Clicking through is enough of an annoyance to serve our
> purposes, and this is trivially simple to add (simpler by far than all other
> options including an infobar).
>
> 2) Info bar.  This seems like one of the more popular options at the
>> moment.
>>
>
> This is a bad idea, we shouldn't do it.  It's not as annoying as a modal
> dialog, it has problems with clashing with other infobars on start.
>  Basically it's inferior to a modal dialog in every way.
>

FYI: The ui-leads (in an off-list thread) seem to like Evan's initial patch
that goes this route.


> 3) Add some other persistent UI like the incognito spy guy, an annoying
>> theme (that overrides whatever you have selected), or something else.  This
>> seems like a pretty good option to me, but there hasn't been too much
>> discussion around it.  What type of UI would be the best?  Is this a good
>> option?
>>
>
> No, we shouldn't do this.  Way too much effort and code (think about making
> this work on three OSes and with custom themes), we just want something
> trivial.
>

Themes are cross platform.  Though I agree that this route may be more
trouble than it's worth.

 4) Add some warning to the new tab page.  Once again, no one's really
>> thought about this seriously.  Any thoughts?
>>
>
> Again, inferior to the other options.  Doesn't work well for users who
> don't start with the NTP (or ones who never see it -- I don't, I don't use
> ctrl-t or the new tab button, I use middle-click and alt-enter).
>

Fair enough.


> If you're planning to implement something, please implement the dialog.
>

I'd like to hear what others think as well.

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

Re: [chromium-dev] [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

I just got back from vacation and would like to take action on this.  I read
through the thread, but I don't see any sort of consensus on what to do.
 Here are the options as I see them:

1) Modal dialog box.  Bad for debugging, will probably just be clicked
through by users, and not very good for users who leave the browser open for
long stretches of time.  I'd say it's not a good solution.

2) Info bar.  This seems like one of the more popular options at the moment.
 The main problem is what to do when there are multiple info bars that need
to be displayed...for example with session restore.  Also there's the
problem of users leaving the browser open for a long time.  We could
periodically re-show the info bar, but that seems clunky.

3) Add some other persistent UI like the incognito spy guy, an annoying
theme (that overrides whatever you have selected), or something else.  This
seems like a pretty good option to me, but there hasn't been too much
discussion around it.  What type of UI would be the best?  Is this a good
option?

4) Add some warning to the new tab page.  Once again, no one's really
thought about this seriously.  Any thoughts?


I think I'm going to take a stab at one of these in the next week or two.

On Fri, Dec 11, 2009 at 12:16 PM, Alice Lin  wrote:

> We actually rarely ask users to turn off the sandbox and after we confirm
> that they can run it with the flag, we tell them do remove it immediately
> due to security vulnerabilities. The only problem is that after this point,
> it's hard for users to figure out what's preventing Google Chrome to run
> properly. We need to find an easier way or some sort of utility to do this.
> I agree that we need to make it obvious to the user that they shouldn't be
> running without sandbox but we need to give them a better way to figure out
> what's wrong so that they can continue to use it.
>
> On Fri, Dec 11, 2009 at 11:48 AM, John Abd-El-Malek wrote:
>
>> (adding Alice)
>>
>> Alice: do you have a rough estimate for how often we ask users to turn off
>> the sandbox when debugging problems?
>>
>> Thanks
>>
>>
>> On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek wrote:
>>
>>>
>>>
>>> On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher wrote:
>>>
>>>> I don't think we should take away --no-sandbox in official builds.  It's
>>>> a valuable debugging tool in case an end-user is experiencing a startup
>>>> crash or other wackiness.
>>>
>>>
>>> I understand the argument, but do we really end up using this for
>>> end-users in debugging problems?  Given how many Chrome users we have, my
>>> impression is we've fixed any issues with the sandbox long ago.
>>>
>>> I don't feel that strongly about disabling --no-sandbox, but I'd like to
>>> be more convinced of the arguments against it :)
>>>
>>
>>>
>>>> I think we should just add a modal dialog at startup that you must
>>>> dismiss each time you launch Chrome until you remove the --no-sandbox
>>>> option.  That should be annoying enough to cause people to remove it once
>>>> they can.  We don't need to expend energy on anything fancier IMO.
>>>>
>>>> -Darin
>>>>
>>>>
>>>> On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow wrote:
>>>>>
>>>>>> On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting 
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek >>>>>> > wrote:
>>>>>>>
>>>>>>>> We disable --single-process and --in-process-plugins on release
>>>>>>>> Google Chrome builds to avoid the support headache that it causes.  I 
>>>>>>>> think
>>>>>>>> we should do the same for --no-sandbox.
>>>>>>>
>>>>>>>
>>>>>>> There are legit reasons we have asked users to try temporarily
>>>>>>> disabling the sandbox, more frequently than for those other flags.  I'd
>>>>>>> prefer to just make the UI turn ugly a la Jeremy's bug.
>>>>>>>
>>>>>>
>>>>>> It might even make sense to re-enable --single-process and use the
>>>>>> same UI technique to discourage it.
>>>>>>
>>>>

Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

On Fri, Dec 11, 2009 at 8:06 AM, Darin Fisher  wrote:

> I don't understand the argument for a periodic indicator.  We don't have a
> periodic indicator telling the user when to restart their browser to pick
> up
> auto-updates.
>

I don't think this is a fair comparison.  One is a normal usage of Chrome
and the other is something we're actively trying to discourage.

On the other hand, maybe some sort of periodic indicator for when you
auto-update is a good idea


> The only time it makes sense for the user to re-consider
> the command line options is when restarting because they might have
> been upgraded to a version that makes the --no-sandbox option unnecessary
> for their usage.
>

Even when they're using the flag because they want to use an experimental
feature we should still remind them that the flag is dangerous and that they
shouldn't be doing normal browsing with that window.


Major +1 to glens idea in theory.  But in practice, how would you pull that
off?

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

Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell  wrote:

> (Resending from chromium.org)
>
> On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher  wrote:
> > After reading the WebGL blog post today, and following the link to the
> wiki,
> > it struck me as fairly *bad* that we are telling people to disable the
> > sandbox.  A good number of folks are going to disable the sandbox and
> forget
> > that they had ever done so.
>
> I don't follow. The --no-sandbox command line argument only takes
> effect for the current invocation of the browser. Most people launch
> Chrome or Chromium from its icon, which will not have that argument
> associated with it.
>

On Windows, the most common way for people to launch with arguments is to
add them to a short cut.  The risk is that they'd do this to their main
shortcut and then forget about it.


> > Once we can support WebGL in the sandbox, what will we do?  It would be
> nice
> > if we could somehow restore the sandbox automatically.  But renaming
> > --no-sandbox doesn't seem like a great choice, and it isn't a scalable
> > solution for other things like this that come up in the future.
>
> We will just remove the --no-sandbox option from that wiki page, and
> people testing WebGL will eventually stop specifying it.
>

_New_ users will stop specifying it, but I doubt people will be regularly
checking the wiki page.


>  > Perhaps --enable-webgl should instead implicitly disable the sandbox
> today
> > so that "tomorrow," when WebGL just works, folks won't have to change any
> > command line options to restore sandbox functionality.  I can see a
> counter
> > argument that people should have to explicitly opt-in to disabling the
> > sandbox, but I'm not sure that out-weighs the cost of having a good
> number
> > of dev channel users running *permanently* without the sandbox.
> > Was this idea considered?  Any other ideas?
>
> I considered this but rejected it because it might lull people into a
> false sense of security -- thinking that they had "just" enabled WebGL
> but were actually browsing without the sandbox.
>
> The best solution is to get the GPU process in place on all platforms,
> at which point WebGL can be run inside the sandbox; this is a high
> priority for me and others.
>

We definitely know this is true, and I think it's even safe to assume this
will be true for other features in the future that only work with the
sandbox off initially.  The problem is the time before this is true.


As for the info bar/modal dialog:  I've been thinking for a bit, and I'm not
sure this is enough.  We have plenty of data that shows users often leave
browsers open for a very long time.  The main risk is that someone sets the
flag, starts their browser, trys out the new cool feature, and then leaves
the browser window open...for a long time.  The next time they start it
they'll see the warning again, but the period of time in between (that
they're more vulnerable) could be non-trivial.

The solution to this is either the annoying/scary UI can't be
disabled/clicked-through/etc (like a red and white striped theme that can't
be overridden) or to pop up a modal dialog or info bar periodically (it
could even be once an hour or even day) in addition to popping it up
initially.


In http://code.google.com/p/chromium/issues/detail?id=24411, Finnur said


Also, when thinking about options 1 and 2 above
(changing the appearance of Chrome) I can't help but think of someone
pitching WebGL
(which currently doesn't work in the sandbox) to their development team and the
audience asking 'why is your browser all red?'. Answer: 'Oh, I have to
turn off all the
security in Chrome to get the demo to work'... :)

I respectfully disagree.  I think it's an opportunity to make it clear that
the browser is normally running at a higher level of security than any other
and that we're _temporarily_ making Chromium on par with any other browser.
 At the end of the day, Chromium will have these features within a sandboxed
environment.  Other browsers won't.  This point could be very powerful if
presented well.

J

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

Re: [chromium-dev] [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

True.

But even if we disable the flags in stable builds, I'd still like to see
some sort of warning UI.

On Thu, Dec 10, 2009 at 11:02 PM, John Abd-El-Malek wrote:

>
>
> On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow wrote:
>
>> On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting wrote:
>>
>>> On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek wrote:
>>>
>>>> We disable --single-process and --in-process-plugins on release Google
>>>> Chrome builds to avoid the support headache that it causes.  I think we
>>>> should do the same for --no-sandbox.
>>>
>>>
>>> There are legit reasons we have asked users to try temporarily disabling
>>> the sandbox, more frequently than for those other flags.  I'd prefer to just
>>> make the UI turn ugly a la Jeremy's bug.
>>>
>>
>> It might even make sense to re-enable --single-process and use the same UI
>> technique to discourage it.
>>
>
> --single-process is buggy and not well tested, and can cause deadlocks in
> some scenarios.
>
> I think only developers should run without the sandbox, as those are the
> ones who'd be able to understand the risks in doing so, and are the only
> ones who need to test out features like webgl that aren't ready yet.  So I
> still think we should disable --no-sandbox in shipping Google Chrome builds,
> and if someone needs it, they can use Chromium builds.
>

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

Re: [chromium-dev] [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting  wrote:

> On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek wrote:
>
>> We disable --single-process and --in-process-plugins on release Google
>> Chrome builds to avoid the support headache that it causes.  I think we
>> should do the same for --no-sandbox.
>
>
> There are legit reasons we have asked users to try temporarily disabling
> the sandbox, more frequently than for those other flags.  I'd prefer to just
> make the UI turn ugly a la Jeremy's bug.
>

It might even make sense to re-enable --single-process and use the same UI
technique to discourage it.

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

Re: [chromium-dev] [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

On Thu, Dec 10, 2009 at 9:29 PM, Jeremy Orlow  wrote:

> On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher  wrote:
>
>> After reading the WebGL blog post today, and following the link to the
>> wiki, it struck me as fairly *bad* that we are telling people to disable the
>> sandbox.  A good number of folks are going to disable the sandbox and forget
>> that they had ever done so.
>>
>> Once we can support WebGL in the sandbox, what will we do?  It would be
>> nice if we could somehow restore the sandbox automatically.  But renaming
>> --no-sandbox doesn't seem like a great choice, and it isn't a scalable
>> solution for other things like this that come up in the future.
>>
>> Perhaps --enable-webgl should instead implicitly disable the sandbox today
>> so that "tomorrow," when WebGL just works, folks won't have to change any
>> command line options to restore sandbox functionality.  I can see a counter
>> argument that people should have to explicitly opt-in to disabling the
>> sandbox, but I'm not sure that out-weighs the cost of having a good number
>> of dev channel users running *permanently* without the sandbox.
>>
>> Was this idea considered?  Any other ideas?
>>
>
> From a past thread on the subject:
>
> On Thu, Oct 8, 2009 at 9:58 AM, Jeremy Orlow  wrote:
>
>> For the record, I'm very against publicly telling people to "turn off the
>> sandbox if you want to check out this really cool feature".
>>
>> Somewhat related: Maybe we need to do something really scary looking when
>> the Sanbox is disabled to impress upon users running that way that they're
>> in a very dangerous state.  It could actually be useful to developers too;
>> I've run without sandbox before and been very confused why things were
>> working when they shouldn't be.
>>
>
> I still think this is the right solution.
>

Oh, and I filed this:
http://code.google.com/p/chromium/issues/detail?id=24411

To be clear, I think this is the right solution because 1) some people might
have already disabled the sandbox and forgotten about it  and 2) in
that interterm period, some people will just leave the flag on and they'll
be insecure.

I do agree that your suggestion is better than the status quo tho.  And it's
something we could do immediately.  Of course, by the time the next dev
channel build is out there (and thus we can change the instructions) it
seems as though most of the damage will have already been done.

J

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

Re: [chromium-dev] [WebGL] Recommending --no-sandbox

[Jeremy Orlow]

On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher  wrote:

> After reading the WebGL blog post today, and following the link to the
> wiki, it struck me as fairly *bad* that we are telling people to disable the
> sandbox.  A good number of folks are going to disable the sandbox and forget
> that they had ever done so.
>
> Once we can support WebGL in the sandbox, what will we do?  It would be
> nice if we could somehow restore the sandbox automatically.  But renaming
> --no-sandbox doesn't seem like a great choice, and it isn't a scalable
> solution for other things like this that come up in the future.
>
> Perhaps --enable-webgl should instead implicitly disable the sandbox today
> so that "tomorrow," when WebGL just works, folks won't have to change any
> command line options to restore sandbox functionality.  I can see a counter
> argument that people should have to explicitly opt-in to disabling the
> sandbox, but I'm not sure that out-weighs the cost of having a good number
> of dev channel users running *permanently* without the sandbox.
>
> Was this idea considered?  Any other ideas?
>

>From a past thread on the subject:

On Thu, Oct 8, 2009 at 9:58 AM, Jeremy Orlow  wrote:

> For the record, I'm very against publicly telling people to "turn off the
> sandbox if you want to check out this really cool feature".
>
> Somewhat related: Maybe we need to do something really scary looking when
> the Sanbox is disabled to impress upon users running that way that they're
> in a very dangerous state.  It could actually be useful to developers too;
> I've run without sandbox before and been very confused why things were
> working when they shouldn't be.
>

I still think this is the right solution.

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

Re: [chromium-dev] Extensions and the Mac

[Jeremy Orlow]

Much of what can't be done on the web platform also can't be done inside the
NaCl sandbox.

On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek
wrote:

> NaCl is the answer to all these problems...
>
> On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow  wrote:
>
>> Or reject extensions that could be written without a NPAPI component.
>>  *ducks*
>>
>> On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting wrote:
>>
>>> On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman  wrote:
>>>
>>>> Q: Can't we have the extensions gallery warn that it won't work?
>>>> A: Sorry, we can't do that in an automated fashion. The extensions
>>>> author should mention it. Too bad they don't.
>>>>
>>>
>>> But we explicitly review patches with binary components.  I can't see how
>>> it could be impossible for us to also mark them as "Win-only".
>>>
>>> PK
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>>  --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
>

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

Re: [chromium-dev] Extensions and the Mac

[Jeremy Orlow]

Or reject extensions that could be written without a NPAPI component.
 *ducks*

On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting  wrote:

> On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman  wrote:
>
>> Q: Can't we have the extensions gallery warn that it won't work?
>> A: Sorry, we can't do that in an automated fashion. The extensions author
>> should mention it. Too bad they don't.
>>
>
> But we explicitly review patches with binary components.  I can't see how
> it could be impossible for us to also mark them as "Win-only".
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Reflecting SSL state in a world with SharedWorkers and cross-window sharing/x-domain messaging

[Jeremy Orlow]

Personally, I feel the opposite, and I'm not sure the "perfect is the enemy
of good" analogy doesn't really fit.  If we erode the meaning of the secure
(as opposed to mixed) content icon, it seems like we're just going to need
to create UI in the future that says "this is really super secure".  I don't
know this for a fact, but I'd also assume that the mixed icon drives
websites to secure their website further.  I'm concerned that the type of
website that wouldn't be up for running everything over https would also be
the type of site that'd have very insecure protocols for their postMessage
handlers.  (Stuff like eval()ing what's sent to them and such.)

But, I say this knowing that you have MUCH more security background than I.
 :-)

J

On Wed, Dec 9, 2009 at 3:53 PM, Adam Barth  wrote:

> In principle, the correct thing to do is keep track of the mixed
> content state of the shared worker and infect whichever windows
> interact with the worker.  However, I suspect this is one of those
> cases where the perfect is the enemy of the good.  For the time being,
> I'm fine with having the SharedWorker not trigger the mixed content
> indicator.  These sorts of attacks are much less severe than an HTTPS
> page executing an HTTP script.  In the latter case, an active network
> attacker can completely control the HTTPS page.  In the case of a
> SharedWorker, the attacker doesn't get nearly as much leverage.
>
> Adam
>
>
> On Wed, Dec 9, 2009 at 1:47 PM, Drew Wilson  wrote:
> > I'm trying to get my head around how our HTTPS status display (lock icon)
> > should work now that we support cross-window/cross-domain communication
> and
> > SharedWorkers.
> > Currently, if an HTTPS page loads a worker and that worker subsequently
> does
> > a non-HTTPS network operation, the parent window's UI updates to reflect
> the
> > new non-secure state, just as if the page itself had performed a
> non-secure
> > network op. With SharedWorkers, you may have a number of parent windows -
> it
> > seems likely that all of those windows should update their state.
> > However, SharedWorkers can accumulate new parents over time. Should a
> > SharedWorker that has made an insecure connection in the past be
> permanently
> > tainted (meaning that if a page connects to a tainted worker, it should
> > immediately lose its own secure status, regardless of whether that worker
> > ever makes another insecure connection)? Do we have any mechanisms
> currently
> > in place that would facilitate implementing this behavior?
> > Similarly, we can now exchange messages between windows (even across
> > domains) using window.postMessage() - if my window posts/receives a
> message
> > with an insecure window, does that affect my window's HTTPS status? Does
> > this somehow cascade to other windows I may have exchanged messages with
> in
> > the past? This situation seems directly analogous to SharedWorkers, since
> > essentially a SharedWorker is just another execution context that
> multiple
> > windows can communicate with via postMessage().
> > Finally, now that multiple pages share things like local storage, it
> seems
> > like loading an insecure resource in one page could impact every page in
> the
> > same origin (if my secure page is storing stuff in localstorage, but some
> > other page in the same origin is compromised from loading an insecure
> > resource, then it seems like my secure storage is compromised).
> > Anyhow, people have been thinking about these issues far longer than I
> have
> > - have we come to any conclusions about how our lock icon should work in
> > these various situations?
> > -atw
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Re: Chromium Tech Talks

[Jeremy Orlow]

Personally, I really like the tech talk format as an introduction to a
topic, but you're right that some would prefer something in written form and
that a Wiki has many benefits that a video does not have.  If you're willing
to transcribe the information, I'm sure it would help others.

On Wed, Dec 9, 2009 at 6:37 AM, Jacques wrote:

> On Dec 8, 10:49 pm, Paweł Hajdan Jr.  wrote:
>
> > Some ideas for
> > the next round of talks:
>
> Would these interesting points not be better suited to be covered in a
> wiki?
> What Jeremy presented there as videos seems more like an appetizer.
>
> With a growing wiki the experienced user aswell as potential
> contributors
> could actually use, transform and expand that information. For
> example,
> a few people could grab some parts off from the wiki, put it in a
> wave,
> chew on it long enough and then feed any results back to the wiki.
>
> Or is that on the list of you just but with a different priority?
>
>
> Friendly Greetings,
> Jac
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

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

[Jeremy Orlow]

On Tue, Dec 8, 2009 at 11:25 AM, Jeremy Orlow  wrote:

> Last Friday we recorded 4 tech talks based on the feedback we got on what
> topics would be interestingand here they are!
>
> http://www.youtube.com/watch?v=JFzC_Gx76E8
> Darin Fisher talks about the recently upstreamed Chromium WebKit API.
>
> http://www.youtube.com/watch?v=bO3XEBuIDns
> Pam Greene talks about how WebKit Layout Tests are used within Chromium.
>
> http://www.youtube.com/watch?v=A5-aXfSt-RA
> Brett Wilson talks about the painting process in Chromium. Brett starts
> from the render tree in WebKit, across the IPC boundaries, and all the way
> to your screen. He also details many of the differences in painting between
> platforms.
>

Oops.  I accidentally cropped the top and bottom of Eric's talk.  I
re-uploaded it here: http://www.youtube.com/watch?v=RVnARGhhs9w


> A deep dive into the guts of WebKit. Eric Seidel explains the process from
> loading the resources, building the DOM tree, and the various trees involved
> in rendering.
>
>
> I can't tell you how impressed I was with all of the talks.  I learned a
> couple things from even the talks that covered material I thought I knew
> well.
>
> Enjoy!
> 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: Chromium Tech Talks

[Jeremy Orlow]

On Tue, Dec 8, 2009 at 11:25 AM, Jeremy Orlow  wrote:

> Last Friday we recorded 4 tech talks based on the feedback we got on what
> topics would be interestingand here they are!
>
> http://www.youtube.com/watch?v=JFzC_Gx76E8
> Darin Fisher talks about the recently upstreamed Chromium WebKit API.
>
> http://www.youtube.com/watch?v=bO3XEBuIDns
> Pam Greene talks about how WebKit Layout Tests are used within Chromium.
>
> http://www.youtube.com/watch?v=A5-aXfSt-RA
> Brett Wilson talks about the painting process in Chromium. Brett starts
> from the render tree in WebKit, across the IPC boundaries, and all the way
> to your screen. He also details many of the differences in painting between
> platforms.
>
> http://www.youtube.com/watch?v=IpcOXzIsSlo
> A deep dive into the guts of WebKit. Eric Seidel explains the process from
> loading the resources, building the DOM tree, and the various trees involved
> in rendering.
>
>
> I can't tell you how impressed I was with all of the talks.  I learned a
> couple things from even the talks that covered material I thought I knew
> well.
>
> Enjoy!
> J
>

P.S. All the talks (past and present) can be found here:
http://sites.google.com/a/chromium.org/dev/developers/tech-talk-videos

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

[chromium-dev] Chromium Tech Talks

[Jeremy Orlow]

Last Friday we recorded 4 tech talks based on the feedback we got on what
topics would be interestingand here they are!

http://www.youtube.com/watch?v=JFzC_Gx76E8
Darin Fisher talks about the recently upstreamed Chromium WebKit API.

http://www.youtube.com/watch?v=bO3XEBuIDns
Pam Greene talks about how WebKit Layout Tests are used within Chromium.

http://www.youtube.com/watch?v=A5-aXfSt-RA
Brett Wilson talks about the painting process in Chromium. Brett starts from
the render tree in WebKit, across the IPC boundaries, and all the way to
your screen. He also details many of the differences in painting between
platforms.

http://www.youtube.com/watch?v=IpcOXzIsSlo
A deep dive into the guts of WebKit. Eric Seidel explains the process from
loading the resources, building the DOM tree, and the various trees involved
in rendering.


I can't tell you how impressed I was with all of the talks.  I learned a
couple things from even the talks that covered material I thought I knew
well.

Enjoy!
J

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

Re: [chromium-dev] Need a linux-views build buddy.

[Jeremy Orlow]

Isn't "gcl try  -b linux_view" what you want?

On Thu, Dec 3, 2009 at 1:46 PM, Mike Pinkerton wrote:

> I've got a cl that builds fine on win/mac/linux but I'm afraid I could
> impact views_linux. And, since there's no trybot, I have no way of
> knowing until I actually check in and break it.
>
> That's where you come in! Would someone mind trying
>
>  http://codereview.chromium.org/465005/show
>
> for me with linux views and see if it's all ok? The only tricky part
> is that there's an svn move on 2 files in there, but the trybots seem
> able to figure it out. Would be much appreciated, thanks!
>
> --
> 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 Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Compiler version used for official Windows builds?

[Jeremy Orlow]

On Wed, Nov 25, 2009 at 7:22 AM, Ted Mielczarek wrote:

> Hi,
>
> I couldn't find this info anywhere on the dev site (maybe I just
> wasn't looking hard enough), but I'm curious as to what version of
> Visual C++ you're using for the official Chrome builds. We're still
> using VC2005 for our Firefox builds, and I'm seeing some weird
> behavior with regards to Breakpad symbols (
> https://bugzilla.mozilla.org/show_bug.cgi?id=520651
> ) and I was curious if you were using the same compiler, and if so if
> you'd seen similar problems.
>
> I've been trying to do a build with VC2008, but a PGO build
> consistently runs out of memory on my machine.


I don't know the answer to the rest of your question, but I think we're
using a machine with >=24gb of ram to do the PGO build.


> VC2010b2 works fine,
> and doesn't seem to exhibit the same problems, but of course it's not
> out of beta yet.
>
> Thanks for any info,
> -Ted
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Beginning with development

[Jeremy Orlow]

Yeah, I think this would be the general idea.  I'm not sure if these files
are currently archived though.  If not, we'd have to see whether doing so
would noticeably slow down builds.  Another problem is that gclient by
default syncs to ToT but ToT is often still being built by the bots.  So
we'd probably need some special option to say you want to sync to the last
version with object files.  Lastly, I wonder if object files can be simply
copied and used that were generated on another machine.  It's possible there
will be some details to work out with this respect.

There's not much sense in spending time discussing these issues and looking
at solutions unless there's someone who wants to champion this, though.

On Fri, Nov 20, 2009 at 2:25 PM, Roberto Perez  wrote:

> Continuing with this issue,
>
> I'm not sure if this is possible, but the builbots can copy the library
> builds to a revision based directory structure before the final executable
> is built. For example, the buildbot which compile webkit module, and copy
> the webkit library to that directory.
>
> So, when you use gclient to sync the repository, you will be able to
> download the already built libraries (by the builbots) corresponding to the
> revision you're syncing.
>
> With this, a full initial checkout will produce a structure where you only
> need to rebuild the modules you've changed their sourcecode to get the final
> executable.
>
>
> On Tue, Nov 10, 2009 at 11:34 PM, Jeremy Orlow wrote:
>
>> On Tue, Nov 10, 2009 at 2:31 PM, Roberto Perez wrote:
>>
>>> As Phistuck said, modifying gclient config file and then skipping the
>>> changes of the modules that you're not working on seems a good solution to
>>> prevent continuous rebuildings of other modules.
>>>
>>> But this doesn't skip the first large build.
>>>
>>> I know that download already built modules isn't the best option but, for
>>> example, you could download the libs that buildbot builds (before linking in
>>> a single executable) and with these modules already built, satisfy the
>>> requeriments to build a single module on your own.
>>>
>>> I'm not talking about splitting the modules into different projects, but
>>> speed up the first stages of working in some module.
>>>
>>
>> It seems like that might be useful to some people.  Maybe you could
>> prototype such a tool?
>>
>>
>>> On Tue, Nov 10, 2009 at 9:30 PM, Marc-Antoine Ruel wrote:
>>>
>>>> And you can use distcc.
>>>>
>>>>
>>>> On Tue, Nov 10, 2009 at 1:21 PM, Paweł Hajdan jr 
>>>> wrote:
>>>> > Note however that you can build specific projects. When working on
>>>> base or
>>>> > net for example, you can build just base_unittests and net_unittests.
>>>> When
>>>> > working on webkity things, you can sometimes compile just the
>>>> test_shell,
>>>> > and not chrome.
>>>> >
>>>> > --
>>>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>>>> > View archives, change email options, or unsubscribe:
>>>> > http://groups.google.com/group/chromium-dev
>>>>
>>>
>>>  --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>>
>

-- 
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: OWP feature owners: Please update the OWP roadmap.

[Jeremy Orlow]

Thanks Fumitoshi!

To _everyone_ else, please do this.  (ccing a bunch of people that might
have updates)

Also, I'm wondering if we shouldn't put our names on the list to make it
easier to know who to contact for information about a feature.  I personally
find it hard to keep up (one of the reasons this list is so incomplete).

On Thu, Nov 12, 2009 at 12:56 PM, Jeremy Orlow  wrote:

> Things here have gotten a little stale:
> http://dev.chromium.org/developers/web-platform-status  Can everyone
> working on OWP features please take a look and make sure what's written
> there syncs up with reality?
>
> To edit: Scroll to the bottom, click sign in, sign in, then click "edit
> page" at the top.
>
> Thanks!
> J
>

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Jeremy Orlow]

Bugged: http://code.google.com/p/chromium/issues/detail?id=27688

On Fri, Nov 13, 2009 at 2:30 PM, Marcos Aruj  wrote:

> It would be nice also for the user to know how much space an extension is
> using. Like it is for memory usage right now.
>
> On Fri, Nov 13, 2009 at 3:28 PM, Jeremy Orlow  wrote:
>
>> On Fri, Nov 13, 2009 at 1:21 PM, Aaron Boodman  wrote:
>>
>>> On Fri, Nov 13, 2009 at 1:07 PM, Jeremy Orlow 
>>> wrote:
>>> > Just for the record, you're also the one who originally said it was
>>> fine to
>>> > limit them to 5mb (for LocalStorage anyhow).  :-)
>>>
>>> It is a consistent position to say "it is fine to limit it to 5mb for
>>> now" and also say "it would be nice to allow additional space
>>> someday". :)
>>>
>>> > What kind of extra space did you have in mind?  Unlimited?
>>> > It's pretty late in the game to be making a decision like this for
>>> mstone-4,
>>> > but it might be possible if this was considered a major issue.
>>>
>>> Sorry, I didn't mean it for mstone 4, that is impossible. I'm just
>>> saying in general, that I think it would be cool for extensions to be
>>> able to request additional space. I await seeing what you guys come up
>>> with for quota management for the web platform.
>>>
>>
>> I think the plan for the web platform (for now anyhow) is that if you want
>> more quota you need to install an extension.
>>
>> Are we OK with giving extensions unlimited storage space?  It seems like
>> doing so would be reasonable as long as we gave the user the option to clean
>> up the disk space when the extension is uninstalled.
>>
>> Either way, let's target something better (at least for extensions) for
>> mstone 5.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Chromium-extensions" group.
>> To post to this group, send email to chromium-extensi...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> chromium-extensions+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/chromium-extensions?hl=.
>>
>
>
>
> --
> Marcos Aruj Alvarez
> Ingeniero de Software
> ---
> marcos.a...@gmail.com
> -
>

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

Re: [chromium-dev] More sheriffs?

[Jeremy Orlow]

On Fri, Nov 13, 2009 at 3:38 PM, Peter Kasting  wrote:

> On Fri, Nov 13, 2009 at 2:56 PM, Dirk Pranke  wrote:
>
>> I think two sheriffs in US/Pacific during US/Pacific work hours is
>> plenty.
>>
>
> I was told at lunch that we already try to some degree to schedule PST with
> non-PST people (although obvioulsy there are far more of the former), which
> gives me the impression that there is a large percentage of time where we
> have one, rather than two, sheriffs.  That is perhaps the most important
> thing I'm trying to rectify in this proposal.
>
> On Fri, Nov 13, 2009 at 2:58 PM, Nicolas Sylvain 
>  wrote:
>
>> As for http://dev.chromium.org/developers/tree-sheriffs, every sheriff
>> receives it in the reminder email the day before they start their sheriff
>> duty.
>>
>
> I see calendar reminder mails and think of them as conveying a reminder of
> an event, so I'd never noticed that these mails also mention a web page I'm
> supposed to be reading.  I know that is my own fault, but maybe there are
> others in the same boat.  In any case, I still think Ben's suggestions would
> be useful.
>
> Overall I am surprised at how many people are skeptical of this proposal
> given how unilaterally positive the smaller lunchtime discussion was.  I
> guess I perceive us as not having a very effective sheriff system right
> now--it's certainly been difficult for me--and am looking for ways to remedy
> that.  It seems like those who aren't in favor of this generally wouldn't
> agree with that assessment, and thus perceive this as adding overhead and
> reducing effectiveness rather than combating a notable lack.  If that is
> accurate, I'm not sure how to square the two worldviews.  I guess I will
> leave this idea in the hands of the green tree task force to decide whether
> it would be helpful.
>

It'd be interesting if others from lunch chimed in with why they think it's
a good idea.

Also, I think there was clear consensus in adding another sheriff so we
always have 2 in the Americas (or maybe even PST).  Do we know what the next
steps are to implement this?

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

Re: sheriff's keep the tree *open* WAS: [chromium-dev] More sheriffs?

[Jeremy Orlow]

+1 (for what it's worth)

On Fri, Nov 13, 2009 at 2:28 PM, Ojan Vafai  wrote:

> On Fri, Nov 13, 2009 at 1:25 PM, Peter Kasting wrote:
>
>> On Fri, Nov 13, 2009 at 1:15 PM, Finnur Thorarinsson 
>> wrote:
>>
>>> If the sheriff load is too much for two people to devote 100% of their
>>> time to, then there is something wrong with the process.
>>>
>>
>> It's clearly too much, given that I hardly see any other sheriffs even
>> attempt to maintain the rule of "every bot green all the time", which is
>> what you're supposed to do as sheriff.  And when I maintain it, I need to
>> keep the tree closed for long periods while I deal with the myriad of issues
>> that come up.
>>
>
> I don't think this is what sheriffs are supposed to do, although there is
> clearly not consensus here. The goal of the sheriff is to keep the tree open
> as long as possible without carpeting over regressions. The sheriff should
> suffer through minor flakiness without closing the tree (e.g. a couple flaky
> webkit tests should not close the tree).
>
> I *do* think it is a team goal to have every bot green all the time, but
> that goal is achieved by reducing flakiness, not by keeping the tree closed
> until all the flakiness has been properly documented (e.g. listed in
> test_expectations.txt). It's also a team goal to keep the tree open for >7
> hours in every eight hour period. The latter is primarily the responsibility
> of the sheriffs.
>
>
>> Solving the problem by having the tree open if things "aren't too bad" is
>> not good enough.  Right now I just checked and the purify and valgrind bots
>> were red.  As usual.  No sign of anyone looking into them.
>>
>
> This is not a solution, but closing the tree doesn't really solve it
> either. We need to put more burden on the sheriffs to watch and address
> these bots, which, perhaps you're right that we should have more sheriffs.
>
> Ojan
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

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

Re: [chromium-dev] Re: More sheriffs?

[Jeremy Orlow]

Maybe we should say at least one PST and at least one non-Americas?

Note that even if people outside of the Americas are getting
sheriff duty more often, the duty is lighter weight...so I think it balances
out fairly well.

As we get more non-Americas committers, we can think about adding
another...but I think things are fairly sane outside of normal PST business
hours for now.

On Fri, Nov 13, 2009 at 1:46 PM, Peter Kasting  wrote:

> It sounds like so far there is more support for the idea of three sheriffs
> than four.  What if I modify the proposal to be:
>
> * Change from two sheriffs to three
> * Try to ensure that one of those three is non-PST if this is possible
> without overloading teams outside MTV (this will probably get more and more
> feasible as we continue to build staff in Tokyo, London, etc.)
> * Try to ensure that at least one of those three has been a sheriff before
> * Link to the sheriff wiki page from the buildbot
> * Make that wiki page exhaustive, and order it so that it's less a
> reference for particular tasks and more an instruction list for everything
> you should do as sheriff
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Jeremy Orlow]

On Fri, Nov 13, 2009 at 1:21 PM, Aaron Boodman  wrote:

> On Fri, Nov 13, 2009 at 1:07 PM, Jeremy Orlow  wrote:
> > Just for the record, you're also the one who originally said it was fine
> to
> > limit them to 5mb (for LocalStorage anyhow).  :-)
>
> It is a consistent position to say "it is fine to limit it to 5mb for
> now" and also say "it would be nice to allow additional space
> someday". :)
>
> > What kind of extra space did you have in mind?  Unlimited?
> > It's pretty late in the game to be making a decision like this for
> mstone-4,
> > but it might be possible if this was considered a major issue.
>
> Sorry, I didn't mean it for mstone 4, that is impossible. I'm just
> saying in general, that I think it would be cool for extensions to be
> able to request additional space. I await seeing what you guys come up
> with for quota management for the web platform.
>

I think the plan for the web platform (for now anyhow) is that if you want
more quota you need to install an extension.

Are we OK with giving extensions unlimited storage space?  It seems like
doing so would be reasonable as long as we gave the user the option to clean
up the disk space when the extension is uninstalled.

Either way, let's target something better (at least for extensions) for
mstone 5.

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Jeremy Orlow]

Just for the record, you're also the one who originally said it was fine to
limit them to 5mb (for LocalStorage anyhow).  :-)

What kind of extra space did you have in mind?  Unlimited?

It's pretty late in the game to be making a decision like this for mstone-4,
but it might be possible if this was considered a major issue.

J

On Fri, Nov 13, 2009 at 1:03 PM, Aaron Boodman  wrote:

> My name is Aaron Boodman and I support the motion to give extensions
> extra space.
>
> On Fri, Nov 13, 2009 at 12:01 PM, Antony Sargent 
> wrote:
> > [+chromium-dev and dumi]
> > I'm not sure what our overall plan is with respect to quotas for html5
> > databases, and whether we've discussed giving extensions larger quotas
> than
> > regular web content. Dumi or anyone else care to comment?
> >
> > On Thu, Nov 12, 2009 at 10:39 PM, Yuichi Tateno 
> > wrote:
> >>
> >> Hi,
> >>
> >> I am experiencing some issues specifying the maximum size with
> >> estimatedSize in openDatabase.
> >> Regardless of whatever value I specify it as, approximately 5MB seems
> >> to be the maximum size.
> >>
> >> http://dev.w3.org/html5/webdatabase/#databases
> >>
> >> Because the extension that I am developing is used to synchronize data
> >> from a social bookmarking site, the 5MB size is not enough and I am
> >> having some trouble.
> >>
> >> In the future could you please see that estimatedSize can be specified
> >> properly, or do you have a plan to increase the size limit to higher
> >> than 5MB?
> >>
> >> 
> >> Yuichi Tateno
> >>
> >> --
> >>
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Chromium-extensions" group.
> >> To post to this group, send email to
> chromium-extensi...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> chromium-extensions+unsubscr...@googlegroups.com
> .
> >> For more options, visit this group at
> >> http://groups.google.com/group/chromium-extensions?hl=.
> >>
> >>
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To post to this group, send email to chromium-extensi...@googlegroups.com.
> To unsubscribe from this group, send email to
> chromium-extensions+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/chromium-extensions?hl=.
>
>
>

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

Re: [chromium-dev] More sheriffs?

[Jeremy Orlow]

For a while now, I've advocated having 2 pacific timezone sheriffs always on
duty and having one or two in other time zones.  I still advocate such an
idea.

So, to be clear, I think this is a good idea as long as the distribution of
sheriffs (time zone wise) is deliberate.

(I think this addresses Stuart's concern as well.)

J

On Fri, Nov 13, 2009 at 12:31 PM, Peter Kasting  wrote:

> At lunch today, a few of us discussed the idea of moving from two sheriffs
> to four.
>
> There are several reasons we contemplated such a change:
> * The team is large enough that on the current schedule, you go months
> between sheriffing, which is so long that you forget things like what tools
> help you do what.
> * Sheriffing is a heavy burden, and getting moreso with more team members.
> * Either the two sheriffs are in different time zones, in which case you
> have effectively one sheriff on duty who has to do everything (bad due to
> point above), or they're not, in which case a chunk of the day is not
> covered at all.
> * New sheriffs could really use a "mentor sheriff" with them, which is
> pretty difficult to schedule.
>
> I think these are good reasons, so I propose we make this change.
>  Comments?
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Any interest in command line tools for network stack?

[Jeremy Orlow]

What's the intended purpose of such tools?  Do they offer any functionality
beyond the standard tools?  Do you envision them being helpful to people
debugging the Chromium network stack?

(Me replying does in no way imply that I have the authority to say yes or
no, btw.  :-)

On Fri, Nov 13, 2009 at 11:13 AM, Chris Bentzel  wrote:

> Howdy,
>
> I've been trying to dive into the Chromium codebase and have been
> focusing on the network stack after getting the gist of how Chromium
> on the whole is organized.
>
> I've written a few hacky little command line tools to exercise some of
> the networking components (nslookup-like for HostResolver, wget-like
> for HttpNetworkTransaction). Should I spend time trying to flesh these
> out and add to net/tools, or is this something which doesn't belong in
> the chromium codebase?
>
> Thanks,
> Chris
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] WebKit Windows try server?

[Jeremy Orlow]

Hopefully we can.  As much as I love Chromium's infrastructure, the flag is
really what fits the best into the infrastructure WebKit already has.

On Thu, Nov 12, 2009 at 1:58 PM, Adam Barth  wrote:

> If we can convince Mark Rowe to add a flag to WebKit's Bugzilla, I'm
> sure we can put them to work within a week.
>
> Adam
>
>
> On Thu, Nov 12, 2009 at 1:54 PM, Marc-Antoine Ruel 
> wrote:
> > To be clear, I have ~10 mac minis dying in a closet waiting for jobs.
> >
> > On Thu, Nov 12, 2009 at 4:52 PM, Jeremy Orlow  wrote:
> >> On Thu, Nov 12, 2009 at 1:50 PM, Adam Barth 
> wrote:
> >>>
> >>> On Thu, Nov 12, 2009 at 1:46 PM, Jeremy Orlow 
> wrote:
> >>> > Btw, there's a webkit-dev thread out there right now about adding try
> >>> > servers.  I don't think anyone's figured out where the hardware will
> >>> > come
> >>> > from though.
> >>>
> >>> Currently my plan is to donate machines from my apartment.  A lack of
> >>> hardware is a ridiculous reason to burn engineering resources.
> >>
> >> I didn't mean to suggest that it's a limiting factor.  Hopefully Google
> >> would be able to donate some resources, but either way I think it's fine
> if
> >> it's a grass-roots type thing.  :-)
> >>
> >> --
> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> View archives, change email options, or unsubscribe:
> >> http://groups.google.com/group/chromium-dev
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> >http://groups.google.com/group/chromium-dev
> >
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] WebKit Windows try server?

[Jeremy Orlow]

On Thu, Nov 12, 2009 at 1:50 PM, Adam Barth  wrote:

> On Thu, Nov 12, 2009 at 1:46 PM, Jeremy Orlow  wrote:
> > Btw, there's a webkit-dev thread out there right now about adding try
> > servers.  I don't think anyone's figured out where the hardware will come
> > from though.
>
> Currently my plan is to donate machines from my apartment.  A lack of
> hardware is a ridiculous reason to burn engineering resources.
>

I didn't mean to suggest that it's a limiting factor.  Hopefully Google
would be able to donate some resources, but either way I think it's fine if
it's a grass-roots type thing.  :-)

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

Re: [chromium-dev] WebKit Windows try server?

[Jeremy Orlow]

On Thu, Nov 12, 2009 at 1:46 PM, Peter Kasting  wrote:

> On Thu, Nov 12, 2009 at 1:43 PM, Nicolas Sylvain wrote:
>
>> On Thu, Nov 12, 2009 at 1:30 PM, Peter Kasting wrote:
>>
>>> I'm wondering if this is any more doable today than it was last time I
>>> asked.  Ojan reminded me that he has a number of fixes for WebKit Windows
>>> bugs that I'd love to see go in that he's waiting on a try server for (due
>>> to layout test impact).  Is there some way I can help make this happen?
>>>
>> You mean, you want more machines on the current Webkit Windows try server?
>>
>
> I didn't realize we had one.  I guess that's what "layout-win" is?  Ojan,
> is this what you need?
>

We're talking about 2 things.  layout_win (like layout_mac and layout_linux)
run tests against Chromium's TestShell.  What we've been talking about off
and on is one that runs the layout tests against safari/DRT.  And, ideally,
offer that up to the rest of the WebKit community.

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

Re: [chromium-dev] WebKit Windows try server?

[Jeremy Orlow]

On Thu, Nov 12, 2009 at 1:30 PM, Peter Kasting  wrote:

> A while ago I asked about the feasibility of setting up a WebKit Windows
> try server.  I seem to recall maruel mentioning that he didn't know it was
> an interesting case and he'd look into it; and I know in general that we've
> been resource-constrained in multiple ways regarding try servers.


IIRC, Linus is willing to pay for more servers but there's a lead time on
actually getting them.  In addition, there's no one championing it.  If you
have free cycles and wanted to champion it, I think that'd be very useful.

Btw, there's a webkit-dev thread out there right now about adding try
servers.  I don't think anyone's figured out where the hardware will come
from though.

I'm wondering if this is any more doable today than it was last time I
> asked.  Ojan reminded me that he has a number of fixes for WebKit Windows
> bugs that I'd love to see go in that he's waiting on a try server for (due
> to layout test impact).  Is there some way I can help make this happen?
>

It's really not that hard to patch something into a WebKit client on your
own.  I do this all the time.

Holding up patches for a try server that might come next week or might come
next year doesn't seem very logical.

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

[chromium-dev] OWP feature owners: Please update the OWP roadmap.

[Jeremy Orlow]

Things here have gotten a little stale:
http://dev.chromium.org/developers/web-platform-status  Can everyone working
on OWP features please take a look and make sure what's written there syncs
up with reality?

To edit: Scroll to the bottom, click sign in, sign in, then click "edit
page" at the top.

Thanks!
J

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

Re: [chromium-dev] Re: Tech talk topics

[Jeremy Orlow]

I'll see what I can do...  :-)

On Wed, Nov 11, 2009 at 12:41 PM, Freddy Rose  wrote:

> +1 on WebKit painting. The rendering phase is very under-documented.
>
> It would be pretty sweet if you could get Simon Fraser or Dave Hyatt
> would do a tech talk on the WebKit stuff.
>
> On Nov 11, 3:36 pm, Buakaw San  wrote:
> > Definitely interested in the painting/rendering process. The previous
> > talk did not go into the WebKit/Skia painting details. I believe it
> > simply had mentioned that the browser maintains a backingstore that it
> > updates through SHM. It was more to show the browser/renderer painting
> > interaction than to explain the WebKit painting phase. I expect this
> > being at the heart of the rendering engine, many would be interested
> > in this part. WebGL would be a very interesting topic as well.
> >
> > +1 for WebKit painting.
> >
> > On Nov 11, 2:24 pm, Peter Kasting  wrote:
> >
> >
> >
> > > On Wed, Nov 11, 2009 at 11:20 AM, Jeremy Orlow 
> wrote:
> > > > I think there's some painting stuff touched on in the first round of
> talks,
> > > > but nothing terribly in depth.  Are there others that would be
> interested in
> > > > this kind of talk?  I'm a bit concerned that it wouldn't be very
> mainstream.
> > > >  If so, who might be good to give it?
> >
> > > Brett wrote that stuff.
> >
> > > Some of the guys working on WebGL and other 3D things might be able to
> give
> > > a talk about where the rendering pipeline is heading in the future.
> >
> > > PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Re: Tech talk topics

[Jeremy Orlow]

I think there's some painting stuff touched on in the first round of talks,
but nothing terribly in depth.  Are there others that would be interested in
this kind of talk?  I'm a bit concerned that it wouldn't be very mainstream.
 If so, who might be good to give it?

On Wed, Nov 11, 2009 at 11:17 AM, Pierre-Antoine LaFayette <
pierre.lafaye...@gmail.com> wrote:

> +1 for WebKit talks.
>
> I think the painting phase and it's Chromium port would be a very
> interesting topic. Things like the GraphicsContext interface and the
> GraphicsContextSkia implementation. What is required for a GraphicsContext
> port? What is the bottleneck in the paint process (e.g. the Skia blit ops)?
>
> 2009/11/5 Jeremy Orlow 
>
> Thanks for the suggestions so far!  Here's what I've seen so far:
>> WebKit API - Darin?
>> Eric's WebKit talk
>> LayoutTests - Pam?
>> Bindings - Andrew?
>>
>>  Keep the ideas coming.  If we get more than we want to tackle we can
>> always vote on which would be most helpful to the community, but all the
>> ones I've heard so far sound very valuable.
>>
>> J
>>
>>
>> On Thu, Nov 5, 2009 at 3:29 PM, Andrew Scherkus wrote:
>>
>>> Something that would have been immensely helpful to me when I started was
>>> a talk explaining the interaction between the javascript bindings,
>>> HTMLFooElement classes and RenderFoo classes.
>>>
>>> I'd volunteer, but I still don't know enough about this stuff myself --
>>> other than when Foo == Media :)
>>>
>>> Andrew
>>>
>>> On Thu, Nov 5, 2009 at 3:24 PM, Mohamed Mansour wrote:
>>>
>>>> +1 on the WebKit tech talks. And maybe on on the WebKitAPI
>>>> infrastructure that darin organized.
>>>>
>>>>  - Mohamed Mansour
>>>>
>>>>
>>>> On Thu, Nov 5, 2009 at 5:17 PM, Scott Violet  wrote:
>>>>
>>>>>
>>>>> It's not Chromium, but how about some WebKit tech talks? Such talks
>>>>> would be incredibly valuable to those helping out now and then with
>>>>> WebKit.
>>>>>
>>>>>  -Scott
>>>>>
>>>>> On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow 
>>>>> wrote:
>>>>> > About 6 months ago, we had a series of tech talks on various bits of
>>>>> > Chromium's architecture.  (They're listed
>>>>> > here: http://dev.chromium.org/developers/tech-talk-videos)  The
>>>>> youtube
>>>>> > ratings are pretty high, they've all had over a thousand views, and
>>>>> I've
>>>>> > seen them mentioned in a couple chromium-dev threadsso it seems
>>>>> like
>>>>> > they've been helpful.
>>>>> > So here's my question: are there any Chromium-internals related
>>>>> topics you
>>>>> > guys/gals would really like to hear more on?  If so, I'll see if we
>>>>> can't
>>>>> > find speakers, schedule some tech talks, get them recorded, and
>>>>> posted.  And
>>>>> > this time, we'll make sure the audio and video quality is much
>>>>> higher.  :-)
>>>>> > J
>>>>> >
>>>>> > >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --~--~-~--~~~---~--~~
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>> -~--~~~~--~~--~--~---
>>
>>
>
>
> --
> Pierre.
>

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

Re: [chromium-dev] Beginning with development

[Jeremy Orlow]

On Tue, Nov 10, 2009 at 2:31 PM, Roberto Perez  wrote:

> As Phistuck said, modifying gclient config file and then skipping the
> changes of the modules that you're not working on seems a good solution to
> prevent continuous rebuildings of other modules.
>
> But this doesn't skip the first large build.
>
> I know that download already built modules isn't the best option but, for
> example, you could download the libs that buildbot builds (before linking in
> a single executable) and with these modules already built, satisfy the
> requeriments to build a single module on your own.
>
> I'm not talking about splitting the modules into different projects, but
> speed up the first stages of working in some module.
>

It seems like that might be useful to some people.  Maybe you could
prototype such a tool?


> On Tue, Nov 10, 2009 at 9:30 PM, Marc-Antoine Ruel wrote:
>
>> And you can use distcc.
>>
>>
>> On Tue, Nov 10, 2009 at 1:21 PM, Paweł Hajdan jr 
>> wrote:
>> > Note however that you can build specific projects. When working on base
>> or
>> > net for example, you can build just base_unittests and net_unittests.
>> When
>> > working on webkity things, you can sometimes compile just the
>> test_shell,
>> > and not chrome.
>> >
>> > --
>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>> > View archives, change email options, or unsubscribe:
>> > http://groups.google.com/group/chromium-dev
>>
>
>  --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

[chromium-dev] Local Storage directory moved as of rev 31584

[Jeremy Orlow]

*If you don't use extensions that use Local Storage or you only use the
official Google Chrome builds, you can probably ignore this.  (Local Storage
was only enabled by default as of last Friday.)*

As of svn rev 
31584,
local storage files are stored in "Local Storage" not "localStorage" (inside
your profile directory).  The change includes code that moves the directory
from the former name to the latter.  So if you're just using the official
builds (or never running a newer build and then an older build), you needn't
worry.

But, if you're building your own version of Chromium, once you launch a
newer build, it will migrate your data.  Older builds will only look in the
old location for it, so they will no longer have access to the localStorage
data.  And if you change a setting with that older build, the newer build
won't see it since the migration is a one time only thing.

If for some reason this is going to be a major problem for you, you can
always symlink the one directory from the other.

Sorry for any inconveniences this may cause.

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: 437k files checked out for an official build

[Jeremy Orlow]

This is related to the thread (last Friday?) about making a light weight
checkout of Chromium the default.

Btw a quick look indicates that 100k are Google specific files (hermetic
build environment and such).  200k are layout tests.  So that leaves "only"
150k filesprobably many of which are still test related.

On Mon, Nov 9, 2009 at 5:37 PM, Anthony LaForge  wrote:

> Howdy,
>
> Was just clobbering a build directory this morning, and noticed it was
> deleting ~437 thousand files from a single Chrome official windows build
> directory, which took approximately 20-30 minutes to do a delete.  Perhaps
> my view isn't oriented correctly, but this seems like a very high number of
> files.   This isn't a high priority issue for the 4.0 timeframe, indeed may
> not be a high priority issue at all, but I'd like to turn it over to our
> developer community to see if anyone has any thoughts on the matter.  So w/
> that...
>
> Kind Regards,
>
> Anthony Laforge
> Technical Program Manager
> Mountain View, CA
>
> >
>

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

[chromium-dev] Re: Tech talk topics

[Jeremy Orlow]

Thanks for the suggestions so far!  Here's what I've seen so far:
WebKit API - Darin?
Eric's WebKit talk
LayoutTests - Pam?
Bindings - Andrew?

Keep the ideas coming.  If we get more than we want to tackle we can always
vote on which would be most helpful to the community, but all the ones I've
heard so far sound very valuable.

J

On Thu, Nov 5, 2009 at 3:29 PM, Andrew Scherkus wrote:

> Something that would have been immensely helpful to me when I started was a
> talk explaining the interaction between the javascript bindings,
> HTMLFooElement classes and RenderFoo classes.
>
> I'd volunteer, but I still don't know enough about this stuff myself --
> other than when Foo == Media :)
>
> Andrew
>
> On Thu, Nov 5, 2009 at 3:24 PM, Mohamed Mansour  wrote:
>
>> +1 on the WebKit tech talks. And maybe on on the WebKitAPI infrastructure
>> that darin organized.
>>
>>  - Mohamed Mansour
>>
>>
>> On Thu, Nov 5, 2009 at 5:17 PM, Scott Violet  wrote:
>>
>>>
>>> It's not Chromium, but how about some WebKit tech talks? Such talks
>>> would be incredibly valuable to those helping out now and then with
>>> WebKit.
>>>
>>>  -Scott
>>>
>>> On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow 
>>> wrote:
>>> > About 6 months ago, we had a series of tech talks on various bits of
>>> > Chromium's architecture.  (They're listed
>>> > here: http://dev.chromium.org/developers/tech-talk-videos)  The
>>> youtube
>>> > ratings are pretty high, they've all had over a thousand views, and
>>> I've
>>> > seen them mentioned in a couple chromium-dev threadsso it seems
>>> like
>>> > they've been helpful.
>>> > So here's my question: are there any Chromium-internals related topics
>>> you
>>> > guys/gals would really like to hear more on?  If so, I'll see if we
>>> can't
>>> > find speakers, schedule some tech talks, get them recorded, and posted.
>>>  And
>>> > this time, we'll make sure the audio and video quality is much higher.
>>>  :-)
>>> > 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: The future for test shell (WAS: test_shell performance is bad compared to Chromium)

[Jeremy Orlow]

On Thu, Nov 5, 2009 at 3:01 PM, Jeremy Orlow  wrote:

> On Thu, Nov 5, 2009 at 2:46 PM, Dirk Pranke  wrote:
>
>>
>> On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt
>>  wrote:
>> >
>> > On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke 
>> wrote:
>> >>
>> >> test_shell being a test shell used mostly for non-interactive testing,
>> >> we haven't given a lot of concern to its perfomance AFAIK. I'm not
>> >> even sure how long of a lifespan it'll have since we aim to
>> >> merge/replace it with WebKit's DumpRenderTree at some point soon.
>> >
>> > So is the plan now for test_shell to go away completely?  #3 under *Next
>> > steps:* in this email seemed to suggest that it would be up-streamed:
>> >
>> >
>> http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309
>> >
>> > Wouldn't merging/replacing test_shell with DRT eliminate the ability to
>> test
>> > the Chromium WebKit API in a simplified environment?
>> >
>>
>> Good question, and I didn't actually know the answer, so that provoked
>> an interesting but short discussion between Ojan and Dimitri and
>> myself. At the moment we're leaning to keeping test_shell and
>> DumpRenderTree both. The latter would be the driver for the layout
>> test harness (as it is upstream), and test_shell would get all of the
>> layout test code ripped out of it and become more like an actual shell
>> that can be used to embed webkit for interactive work (and upstreamed,
>> as you say). The exact functionality and distinctions between the two
>> (and the justification of the existence of both) probably still needs
>> some edges smoothed.
>>
>
> Features like AppCache and WebDatabase depend on code that will probably
> never be unstreamed to WebKit's repo.
>

Because it depends on base, net, etc.


> So either we need to always run at least some tests under test shell
>

Or we need to do some GYP hackery so that we can compile in their
implementation or our implementation...and be sure that we run our
implementation on at least some of our bots.


> or we'll need to be content with not running these layout tests.
>
> Note that we have a somewhat hacky way of running layout tests in the UI
> test framework that might suffice for this stuff.  Right now, I run
> LocalStorage tests in both test_shell and the ui_test framework.
>

--~--~-~--~~~---~--~~
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: Tech talk topics

[Jeremy Orlow]

That's an excellent idea!  Do you think you'd be able to give it?  If not,
do you have any suggestions on who would be good?  Maybe Pam?

On Thu, Nov 5, 2009 at 3:08 PM, Jeremy Moskovich wrote:

> IMHO it would be immensely valuable to give a talk explaining what Layout
> tests are and how they work in a *simple* enough manner to allow web
> developers to create tests for bugs that affect them.  I haven't found any
> easily discoverable introductory material on this topic.
>
> Best regards,
> Jeremy
>
> On Fri, Nov 6, 2009 at 12:30 AM, Scott Violet  wrote:
>
>>
>> A general big picture talk would be a great starter. How the DOM is
>> modeled, how the render tree works, the interesting objects ...
>>
>>  -Scott
>>
>> On Thu, Nov 5, 2009 at 2:22 PM, Jeremy Orlow  wrote:
>> > Sure...we definitely have some in-house expertise on this.  I could even
>> see
>> > if any of the Apple guys would be interested in this...but I wouldn't
>> hold
>> > my breath.  :-)
>> > What types of WebKit topics?
>> >
>> > On Thu, Nov 5, 2009 at 2:17 PM, Scott Violet  wrote:
>> >>
>> >> It's not Chromium, but how about some WebKit tech talks? Such talks
>> >> would be incredibly valuable to those helping out now and then with
>> >> WebKit.
>> >>
>> >>  -Scott
>> >>
>> >> On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow 
>> wrote:
>> >> > About 6 months ago, we had a series of tech talks on various bits of
>> >> > Chromium's architecture.  (They're listed
>> >> > here: http://dev.chromium.org/developers/tech-talk-videos)  The
>> youtube
>> >> > ratings are pretty high, they've all had over a thousand views, and
>> I've
>> >> > seen them mentioned in a couple chromium-dev threadsso it seems
>> like
>> >> > they've been helpful.
>> >> > So here's my question: are there any Chromium-internals related
>> topics
>> >> > you
>> >> > guys/gals would really like to hear more on?  If so, I'll see if we
>> >> > can't
>> >> > find speakers, schedule some tech talks, get them recorded, and
>> posted.
>> >> >  And
>> >> > this time, we'll make sure the audio and video quality is much
>> higher.
>> >> >  :-)
>> >> > 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] The future for test shell (WAS: test_shell performance is bad compared to Chromium)

[Jeremy Orlow]

On Thu, Nov 5, 2009 at 2:46 PM, Dirk Pranke  wrote:

>
> On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt
>  wrote:
> >
> > On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke 
> wrote:
> >>
> >> test_shell being a test shell used mostly for non-interactive testing,
> >> we haven't given a lot of concern to its perfomance AFAIK. I'm not
> >> even sure how long of a lifespan it'll have since we aim to
> >> merge/replace it with WebKit's DumpRenderTree at some point soon.
> >
> > So is the plan now for test_shell to go away completely?  #3 under *Next
> > steps:* in this email seemed to suggest that it would be up-streamed:
> >
> >
> http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309
> >
> > Wouldn't merging/replacing test_shell with DRT eliminate the ability to
> test
> > the Chromium WebKit API in a simplified environment?
> >
>
> Good question, and I didn't actually know the answer, so that provoked
> an interesting but short discussion between Ojan and Dimitri and
> myself. At the moment we're leaning to keeping test_shell and
> DumpRenderTree both. The latter would be the driver for the layout
> test harness (as it is upstream), and test_shell would get all of the
> layout test code ripped out of it and become more like an actual shell
> that can be used to embed webkit for interactive work (and upstreamed,
> as you say). The exact functionality and distinctions between the two
> (and the justification of the existence of both) probably still needs
> some edges smoothed.
>

Features like AppCache and WebDatabase depend on code that will probably
never be unstreamed to WebKit's repo. So either we need to always run at
least some tests under test shell or we'll need to be content with not
running these layout tests.

Note that we have a somewhat hacky way of running layout tests in the UI
test framework that might suffice for this stuff.  Right now, I run
LocalStorage tests in both test_shell and the ui_test framework.

--~--~-~--~~~---~--~~
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 using threads in the browser process

[Jeremy Orlow]

On Thu, Nov 5, 2009 at 2:01 PM, John Abd-El-Malek  wrote:

>
>
> On Thu, Nov 5, 2009 at 1:42 PM, Jeremy Orlow  wrote:
>
>> On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek wrote:
>>
>>>
>>>
>>> On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow wrote:
>>>
>>>> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>>>>
>>>>> Over the last week, I've been making some changes to how threads are
>>>>> used in the browser process, with the goal of simplifying cross-thread
>>>>> access and improving stability.
>>>>>
>>>>> *The problem*
>>>>> We were using a number of patterns that were problematic:
>>>>>
>>>>> 1) using ChromeThread::GetMessageLoop
>>>>>   -this isn't safe, since it could return a valid pointer, but since
>>>>> the caller isn't holding on to a lock anymore, the target MessageLoop 
>>>>> could
>>>>> be destructed while it's being used
>>>>>
>>>>> 2) caching of MessageLoop pointers in order to use them later for
>>>>> PostTask and friends
>>>>>   -this was more efficient previously (more on that later) since using
>>>>> ChromeThread::GetMessageLoop involved a lock
>>>>>   -but it spread logic about the order of thread destruction all over
>>>>> the code.  Code that moved from the IO thread to the file thread and back,
>>>>> in order to avoid doing disk access on the IO thread, ended up having to 
>>>>> do
>>>>> an extra hop through the UI thread on the way back to the IO thread since
>>>>> the file thread outlives the Io thread.  Of course, most code learnt this
>>>>> the hard way, after doing the straight forward IO->file->IO thread hop and
>>>>> updating the code after seeing reliability or user crashes
>>>>>   -it made the browser shutdown fragile and hence difficult to update
>>>>>
>>>>> 3) file thread hops using RefCountedThreadSafe objects which have
>>>>> non-trivial destructors
>>>>>   -to reduce jank, frequently an object on the UI or IO thread would
>>>>> execute some code on the file thread, then post the result back to the
>>>>> original thread.  We make this easy using RefCountedThreadSafe and
>>>>> NewRunnableMethod so this pattern happened often, but it's not always
>>>>> safe: NewRunnableMethod holds an extra reference on the object to ensure
>>>>> that it doesn't invoke a method on a deleted object.  But it's quite
>>>>> possible that before the file thread's stack unwinds and it releases the
>>>>> extra reference, that the response task on the original thread executed 
>>>>> and
>>>>> released its own additional reference.  The file thread is then left with
>>>>> the remaining reference and the object gets destructed there.  While for
>>>>> most objects this is ok, many have non-trivial destructors, with the worst
>>>>> being ones that register with the per-thread NotificationService.  
>>>>> Dangling
>>>>> pointers would be left behind and tracking these crashes from ChromeBot or
>>>>> the crash dumps has wasted several days at least for me.
>>>>>
>>>>> 4) having browser code take different code paths if a thread didn't
>>>>> exist
>>>>>   -this could be either deceptively harmless  (i.e. execute
>>>>> synchronously when it was normally asynchronous), when in fact it makes
>>>>> shutdown slower because disk access is moved to the UI thread
>>>>>   -it could lead to data loss, if tasks are silently not posted because
>>>>> the code assumes this only happens in unit tests, when it could occur on
>>>>> browser shutdown as well
>>>>>
>>>>>
>>>>> *The solution*
>>>>> 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
>>>>> DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are 
>>>>> grabbed
>>>>> if the target thread is known to outlive the current thread.  The four
>>>>> static methods have the same signature as the ones from MessageLoop, with
>>>>> the addition of the first parameter to indicate the target thread.
>>>>>
>>>>> ChromeThread::PostTask(ChromeThrea

[chromium-dev] Re: Tech talk topics

[Jeremy Orlow]

Sure...we definitely have some in-house expertise on this.  I could even see
if any of the Apple guys would be interested in this...but I wouldn't hold
my breath.  :-)

What types of WebKit topics?

On Thu, Nov 5, 2009 at 2:17 PM, Scott Violet  wrote:

> It's not Chromium, but how about some WebKit tech talks? Such talks
> would be incredibly valuable to those helping out now and then with
> WebKit.
>
>  -Scott
>
> On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow  wrote:
> > About 6 months ago, we had a series of tech talks on various bits of
> > Chromium's architecture.  (They're listed
> > here: http://dev.chromium.org/developers/tech-talk-videos)  The youtube
> > ratings are pretty high, they've all had over a thousand views, and I've
> > seen them mentioned in a couple chromium-dev threadsso it seems like
> > they've been helpful.
> > So here's my question: are there any Chromium-internals related topics
> you
> > guys/gals would really like to hear more on?  If so, I'll see if we can't
> > find speakers, schedule some tech talks, get them recorded, and posted.
>  And
> > this time, we'll make sure the audio and video quality is much higher.
>  :-)
> > 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: Changes to using threads in the browser process

[Jeremy Orlow]

On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek  wrote:

>
>
> On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow  wrote:
>
>> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>>
>>> Over the last week, I've been making some changes to how threads are used
>>> in the browser process, with the goal of simplifying cross-thread access and
>>> improving stability.
>>>
>>> *The problem*
>>> We were using a number of patterns that were problematic:
>>>
>>> 1) using ChromeThread::GetMessageLoop
>>>   -this isn't safe, since it could return a valid pointer, but since the
>>> caller isn't holding on to a lock anymore, the target MessageLoop could be
>>> destructed while it's being used
>>>
>>> 2) caching of MessageLoop pointers in order to use them later for
>>> PostTask and friends
>>>   -this was more efficient previously (more on that later) since using
>>> ChromeThread::GetMessageLoop involved a lock
>>>   -but it spread logic about the order of thread destruction all over the
>>> code.  Code that moved from the IO thread to the file thread and back, in
>>> order to avoid doing disk access on the IO thread, ended up having to do an
>>> extra hop through the UI thread on the way back to the IO thread since the
>>> file thread outlives the Io thread.  Of course, most code learnt this the
>>> hard way, after doing the straight forward IO->file->IO thread hop and
>>> updating the code after seeing reliability or user crashes
>>>   -it made the browser shutdown fragile and hence difficult to update
>>>
>>> 3) file thread hops using RefCountedThreadSafe objects which have
>>> non-trivial destructors
>>>   -to reduce jank, frequently an object on the UI or IO thread would
>>> execute some code on the file thread, then post the result back to the
>>> original thread.  We make this easy using RefCountedThreadSafe and
>>> NewRunnableMethod so this pattern happened often, but it's not always
>>> safe: NewRunnableMethod holds an extra reference on the object to ensure
>>> that it doesn't invoke a method on a deleted object.  But it's quite
>>> possible that before the file thread's stack unwinds and it releases the
>>> extra reference, that the response task on the original thread executed and
>>> released its own additional reference.  The file thread is then left with
>>> the remaining reference and the object gets destructed there.  While for
>>> most objects this is ok, many have non-trivial destructors, with the worst
>>> being ones that register with the per-thread NotificationService.  Dangling
>>> pointers would be left behind and tracking these crashes from ChromeBot or
>>> the crash dumps has wasted several days at least for me.
>>>
>>> 4) having browser code take different code paths if a thread didn't exist
>>>   -this could be either deceptively harmless  (i.e. execute synchronously
>>> when it was normally asynchronous), when in fact it makes shutdown slower
>>> because disk access is moved to the UI thread
>>>   -it could lead to data loss, if tasks are silently not posted because
>>> the code assumes this only happens in unit tests, when it could occur on
>>> browser shutdown as well
>>>
>>>
>>> *The solution*
>>> 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
>>> DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed
>>> if the target thread is known to outlive the current thread.  The four
>>> static methods have the same signature as the ones from MessageLoop, with
>>> the addition of the first parameter to indicate the target thread.
>>>
>>> ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task);
>>>
>>> 3: If your object must be destructed on a specific thread, use a trait
>>> from ChromeThread:
>>>
>>> class Foo : public base::RefCountedThreadSafe>> ChromeThread::DeleteOnIOThread>
>>>
>>
>> This is really cool and a great idea, but I'm a little concerned about
>> what happens when the thread has already been torn down.  It seems that it
>> calls DeleteSoon which calls PostNonNestableTask which calls PostTaskHelper.
>>  PostTaskHelper deletes the task if the thread is shut down.
>>
>> This works fine if something is only supposed to touch 2 threads.  But
>> what if 2 threads simultaneously delete something which is supposed to be
>> de

[chromium-dev] Tech talk topics

[Jeremy Orlow]

About 6 months ago, we had a series of tech talks on various bits of
Chromium's architecture.  (They're listed here:
http://dev.chromium.org/developers/tech-talk-videos)  The youtube ratings
are pretty high, they've all had over a thousand views, and I've seen them
mentioned in a couple chromium-dev threadsso it seems like they've been
helpful.

So here's my question: are there any Chromium-internals related topics you
guys/gals would really like to hear more on?  If so, I'll see if we can't
find speakers, schedule some tech talks, get them recorded, and posted.  And
this time, we'll make sure the audio and video quality is much higher.  :-)

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: Changes to using threads in the browser process

[Jeremy Orlow]

On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek  wrote:

> Over the last week, I've been making some changes to how threads are used
> in the browser process, with the goal of simplifying cross-thread access and
> improving stability.
>
> *The problem*
> We were using a number of patterns that were problematic:
>
> 1) using ChromeThread::GetMessageLoop
>   -this isn't safe, since it could return a valid pointer, but since the
> caller isn't holding on to a lock anymore, the target MessageLoop could be
> destructed while it's being used
>
> 2) caching of MessageLoop pointers in order to use them later for PostTask
> and friends
>   -this was more efficient previously (more on that later) since using
> ChromeThread::GetMessageLoop involved a lock
>   -but it spread logic about the order of thread destruction all over the
> code.  Code that moved from the IO thread to the file thread and back, in
> order to avoid doing disk access on the IO thread, ended up having to do an
> extra hop through the UI thread on the way back to the IO thread since the
> file thread outlives the Io thread.  Of course, most code learnt this the
> hard way, after doing the straight forward IO->file->IO thread hop and
> updating the code after seeing reliability or user crashes
>   -it made the browser shutdown fragile and hence difficult to update
>
> 3) file thread hops using RefCountedThreadSafe objects which have
> non-trivial destructors
>   -to reduce jank, frequently an object on the UI or IO thread would
> execute some code on the file thread, then post the result back to the
> original thread.  We make this easy using RefCountedThreadSafe and
> NewRunnableMethod so this pattern happened often, but it's not always
> safe: NewRunnableMethod holds an extra reference on the object to ensure
> that it doesn't invoke a method on a deleted object.  But it's quite
> possible that before the file thread's stack unwinds and it releases the
> extra reference, that the response task on the original thread executed and
> released its own additional reference.  The file thread is then left with
> the remaining reference and the object gets destructed there.  While for
> most objects this is ok, many have non-trivial destructors, with the worst
> being ones that register with the per-thread NotificationService.  Dangling
> pointers would be left behind and tracking these crashes from ChromeBot or
> the crash dumps has wasted several days at least for me.
>
> 4) having browser code take different code paths if a thread didn't exist
>   -this could be either deceptively harmless  (i.e. execute synchronously
> when it was normally asynchronous), when in fact it makes shutdown slower
> because disk access is moved to the UI thread
>   -it could lead to data loss, if tasks are silently not posted because the
> code assumes this only happens in unit tests, when it could occur on browser
> shutdown as well
>
>
> *The solution*
> 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
> DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed
> if the target thread is known to outlive the current thread.  The four
> static methods have the same signature as the ones from MessageLoop, with
> the addition of the first parameter to indicate the target thread.
>
> ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task);
>
> 3: If your object must be destructed on a specific thread, use a trait from
> ChromeThread:
>
> class Foo : public base::RefCountedThreadSafe ChromeThread::DeleteOnIOThread>
>

This is really cool and a great idea, but I'm a little concerned about what
happens when the thread has already been torn down.  It seems that it calls
DeleteSoon which calls PostNonNestableTask which calls PostTaskHelper.
 PostTaskHelper deletes the task if the thread is shut down.

This works fine if something is only supposed to touch 2 threads.  But what
if 2 threads simultaneously delete something which is supposed to be deleted
on a third thread that's already been shut down?  And what if they both call
a method on another class that's not thread safe?  I ask because
this scenario is going to prevent me from using this for DOM Storage.

A possible solution would be to guarantee that, if the thread is dead,
destruction happens on the UI thread.  At least in this case, I think it
would work.

Thoughts?


> 4: I've removed all the special casing and always made the objects in the
> browser code behave in one way.  If you're writing a unit test and need to
> use an object that goes to a file thread (where before it would proceed
> synchronously), you just need:
>
> ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current());
> foo->StartAsyncTaskOnFileThread();
> MessageLoop::current()->RunAllPending();
>
> There are plenty of examples now in the tests.
>
>
> *Gotchas*
> -PostTask will silently delete a task if the thread doesn't exist.  This is
> done to avoid having all the code that uses it have special case

[chromium-dev] Re: Large commit - update your .gclient files to avoid

[Jeremy Orlow]

I started a new thread about a lite version of the checkout.  Might be good
to move discussion there.

On Thu, Nov 5, 2009 at 12:44 PM, Scott Hess  wrote:

> On Thu, Nov 5, 2009 at 1:33 PM, Antoine Labour  wrote:
> > On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) 
> wrote:
> >> it'd be nice to have a gclient config lean or something like that.
> >
> > It'd be nice for it to be the default in fact.
>
> As long as we're on wishlists, it would be nice to have some
> dependencies be default-DENY rather than default-ALLOW.  So rather
> than having to suppress things you often don't want, you have to
> enable things you sometimes do want.
>
> -scott [who has no patch lined up to implement 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] Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)

[Jeremy Orlow]

On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour  wrote:

>
>
> On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) 
> wrote:
>
>>
>> it'd be nice to have a gclient config lean or something like that.
>>
>
> It'd be nice for it to be the default in fact.
>

I know we've avoided this in the past because we wanted everyone to run
tests before committing.  But realistically, I think we all use the try bots
to run tests and only run them locally for triaging a failure.  Thus it
probably does make sense to not include hundreds if not thousands of megs of
test files and such for the default checkout.  Do others agree?

If so, then we may need to move some of the bulky test data into DEPS so
that they can be turned off in gclient.  An example is
webkit/data/layout_tests which has platform specific test expectations.

I think this would make a lot of people on slow internet connections happy.
 :-)

--~--~-~--~~~---~--~~
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: Large commit - update your .gclient files to avoid

[Jeremy Orlow]

In general, it might be interesting to document how to get a more lean
checkout of Chromium.

On Thu, Nov 5, 2009 at 11:34 AM, Adam Barth  wrote:

>
> Can we note this on dev.chromium.org somewhere?
>
> Adam
>
>
> On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart 
> wrote:
> > This afternoon I will update DEPS to pull in 170MB of profile data for
> > memory_test. Unless you run memory_test, you probably want to add the
> > following line to the custom_deps section of your .gclient file.
> > "src/data/memory_test/membuster": None,
> > --
> > Steve
> > >
> >
>
> >
>

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

[Jeremy Orlow]

Is it possible to name these differently?  Especially when editing in xcode
it can be kind of annoying having multiple project files named the same
thing.

On Tue, Nov 3, 2009 at 2:40 PM, Yaar Schnitman  wrote:

> A few changes have been made around the webkit.gyp in our ongoing effort to
> upstream the Webkit api:
>
> 1. The WebKit API target has been split out of src/webkit/webkit.gyp and
> into src/webkit/api/WebKit.gyp (new), in preparation for its eventual move
> upstream to src/third_party/WebKit/WebKit/chromium. If you are
> adding/removing files to the api, you'll find the sources section in the new
> gyp file.
>
> 2. The webcore code generation python scripts are moving upstream from
> src/webkit/build to src/third_party/WebKit/WebCore/WebCore.gyp/scripts. The
> files still exist downstream, but I plan to delete them once the webkit
> revision rolls in (so please don't touch them).
>
> That will be all.
> Dismissed.
>
> Yaar
>
>
> >
>

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

[chromium-dev] Re: Why is Linux Chrome so fast?

[Jeremy Orlow]

Ha.
http://tech.slashdot.org/story/09/11/03/1334203/X11-Chrome-Reportedly-Outperforms-Windows-and-Mac-Versions

On Fri, Oct 30, 2009 at 9:44 AM, Linus Upson  wrote:

> scrolling jank in gmail
> http://crbug.com/25741
>
> Linus
>
>
> On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth  wrote:
>
>>
>> On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin  wrote:
>> > General comments: Linux tends to be "lighter" which means it does
>> > better on older hardware, so depending on what sorts of laptops you're
>> > talking about that could be a major factor.  Windowses later than 2000
>> > or so need surprising amounts of hardware to run well.  (I don't
>> > mention Mac below because there hasn't been much performance work
>> > there yet.)
>>
>> I pulled out the laptops side-by-side to be more scientific about
>> this.  Here are the stats:
>>
>> XP: 2GB RAM, Core2 Duo, 2.00 GHz
>> Ubuntu 9.10: 2GB RAM, Core 2 Duo, 2.40 GHz
>>
>> So, the Linux machine as 20% more CPU to work with.
>>
>> >> 1) Scroll performance is extremely good.  Even on Gmail, I can only
>> >> get the mouse to lead the scroll bar by a dozen pixels.  On Slashdot,
>> >> it doesn't even look like I can do that.
>> >
>> > On "plain" pages (one scrollbar on the right, no Flash) scrolling is
>> > literally shifting the pixels down.  On Linux we do this by sending a
>> > command to the X server, which is a single process that even has the
>> > graphics drivers built in so it talks directly to your graphics card
>> > and can in theory do a hardware-accelerated copy.  I would expect this
>> > to be pretty fast.
>>
>> Looking at this more carefully, scroll performance on Slashdot is
>> great in both Windows and Linux.  On Gmail (no chat mole), there's a
>> noticeable difference.  Here's a visualization of the numb on the
>> scroll bar:
>>
>> ||
>> ||
>> ||
>> ||
>> ||
>> ||
>> --  <-- Click here and pull down
>> --
>> --  <-- Linux: mouse latency gets to here
>> ||
>> ||  <-- Windows: mouse latency gets to here
>> ||
>> ||
>> ||
>> ||
>>
>> Admittedly, it's hard to see precisely, but it affects the "feel."
>> Scroll on Windows feels slightly heavier.
>>
>> >> 2) Tab creation is very fast.  Maybe the zygote is helping here?  Can
>> >> we pre-render the NTP on other platforms?
>> >
>> > The zygote is paused right at process start, before we've even started
>> > a renderer.  On the other hand Windows process creation is more
>> > expensive.
>> >
>> > There is a "new tab" graph that attempts to measure this.  The various
>> > lines on the graph are tracking how quickly we get to each stage in
>> > constructing the page.  We hit the first line 20ms faster on Linux
>> > than Windows likely due to the zygote and "slow" Windows process
>> > creation, but process startup seems to be a relatively small part of
>> > the total time.  Linux hits other lines later and Linux and Windows
>> > hit the finish line at around the same time.
>>
>> So, I retried this with a fresh profile on both.  The differences are
>> not as dramatic as I remember.  I can't actually see a difference when
>> I run them side-by-side.
>>
>> >> 3) Startup time is faster than calculator.
>> >
>> > I'm not sure if you're kidding.  Do you mean Windows calculator?
>>
>> I meant Linux calculator.
>>
>> > In the limit, I'd expect us to pay a lot more on Linux due to using
>> > more libraries, GTK initialization, round trips to the X server, etc.
>> > but I don't know much about Windows here.
>>
>> I tried turning on the GTK theme.  That killed startup performance.
>>
>> Side-by-side startup easily noticeably faster in Linux.  To be more
>> precise, drawing the first pixel is noticeably faster.  Total startup
>> time is harder to say.
>>
>> Interestingly startup drawing is different between Windows and Linux.
>> We might want to film with a high-speed camera to see exactly what's
>> going on, but here are my impressions:
>>
>> Linux draw order:
>> 1) Fill entire window with blue (This looks bad, can we use a
>> different color? White?).
>> 2) Paint main UI widgets, including NTP.
>> 3) Paint NTP thumbnails.
>> I bet that (2) is actually broken in to two pieces, I just can't see it.
>>
>> Window draw order:
>> 1) Paint NC region (the blue border around the edge).
>> 2) Paint main UI widgets (without omnibox).
>> 3) Blit NTP content area (the sweep from top to bottom is noticeable).
>> 4) Paint omnibox.
>> 5) Paint NTP thumbnails.
>>
>> Keep in mind that this all happens very fast, so I could be imagining
>> things.
>>
>> Ideas for improving perceived windows startup time:
>>
>> 1) Draw a fake omnibox with the rest of the main UI widgets.
>> Currently we draw the omnibox really late and it looks slow and bad.
>> You can see this if you have a dark desktop wallpaper and you focus on
>> where the omnibox will be.  You'll see a dark rectangle inside the
>> main toolbar which is the desktop showing through.  We should never
>> show a dark rectangle there.
>>
>> 2) Fill the main content area with white when drawing the main

[chromium-dev] Re: Which editor do you recommend on Mac OS X?

[Jeremy Orlow]

On Tue, Nov 3, 2009 at 10:12 AM, Paweł Hajdan Jr.
wrote:

> On Tue, Nov 3, 2009 at 19:08, Drew Wilson  wrote:
>
>> I've also been known to use the built-in GNU emacs from a terminal shell
>> (especially when working remotely/SSH-ing). I see no reason why you can't
>> have the same experience that you do with your Linux box, although you'd
>> have to find a way to drag the google3 elisp over.
>>
>
> I have it working. For reference, the file can be downloaded from
> http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el
>
> Maybe I should try the non-aqua Emacs, hm...
>
> How about building? Is using xcodebuild slower than running the build from
> Xcode? My simple testing shows that there is no big difference.
>

On both my MacBook Pro and Mac Pro, I found that there was a
fairly sizable difference doing incremental builds since XCode keeps track
of dependencies between builds.  When doing a full build, there's not much
difference though.

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

[chromium-dev] Re: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!

[Jeremy Orlow]

On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess  wrote:

> Just to be clear for those of us who are wobbly on C++, this is
> because during the constructor or destructor, your object is of the
> class in question, NOT of the class it will finally be, because in the
> constructor the subclass has not been constructed, yet, and in the
> destructor the subclass was already destructed.  So calling to the
> subclass virtual implementation would be bad.
>
> Scott Meyers says: http://www.artima.com/cppsource/nevercall.html
>
> Is there any way we could modify an object to assert that it can't
> happen in development?  Like scoped_vtable_killer declared in the
> constructor and destructor which makes calling a virtual method on
> that object fatal?
>

Or is there any sort of built in compiler warning that we could turn on?  I
did a bit of searching and was really surprised that I couldn't find any
mention of such a thing.

On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow  wrote:
> > I've spent a good deal of this week trying to track down what turned out
> to
> > be a simple but fairly common problem: I forgot virtual dispatch only
> > partially works in destructors.  There have been several email threads
> about
> > this, but it still bites us form time to time, so I thought it was worth
> > another reminder.
> >
> > Details:
> > I subclassed ChromeThread which subclasses base::Thread.  base::Thread
> calls
> > CleanUp on the thread right before termination.  CleanUp is virtual.
>  Both
> > ChromeThread and my class override CleanUp().  base::Thread calls Stop()
> in
> > its destructor to stop the thread (if it hasn't already been stopped).
>  But
> > by the time you hit destruction, the vtable is no longer available and
> thus
> > the destructor of base::Thread (and anything it calls) does NOT have
> access
> > to the vtable of ChromeThread (or my class).  So, if you don't explicitly
> > call Stop(), your subclass's CleanUp method will NOT be called.  Thus the
> > thread was going away without my CleanUp method ever being called.
> > Obviously this affects more than just base::Thread.  And this is also how
> > you can hit errors with pure virtual methods being called.
> > 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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!

[Jeremy Orlow]

On Fri, Oct 30, 2009 at 3:17 PM, Antoine Labour  wrote:

> On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow  wrote:
>
>> I've spent a good deal of this week trying to track down what turned out
>> to be a simple but fairly common problem: I forgot virtual dispatch only
>> partially works in destructors.  There have been several email threads about
>> this, but it still bites us form time to time, so I thought it was worth
>> another reminder.
>>
>>
>> Details:
>> I subclassed ChromeThread which subclasses base::Thread.  base::Thread
>> calls CleanUp on the thread right before termination.  CleanUp is virtual.
>>  Both ChromeThread and my class override CleanUp().  base::Thread calls
>> Stop() in its destructor to stop the thread (if it hasn't already been
>> stopped).  But by the time you hit destruction, the vtable is no longer
>> available and thus the destructor of base::Thread (and anything it calls)
>> does NOT have access to the vtable of ChromeThread (or my class).  So, if
>> you don't explicitly call Stop(), your subclass's CleanUp method will NOT be
>> called.  Thus the thread was going away without my CleanUp method ever being
>> called.
>>
>> Obviously this affects more than just base::Thread.  And this is also how
>> you can hit errors with pure virtual methods being called.
>>
>> J
>>
>
> Suggestion: don't call  CleanUp in the destructor, but check that someone
> did.
>

I assume you mean Stop()?

The problem is when you have a class like ChromeThread inherit from
base::Thread and then call Stop() in its destructor and then have someone
else subclass ChromeThread and expect its CleanUp to be called.


On Fri, Oct 30, 2009 at 3:16 PM, Adam Barth  wrote:

> I'm sorry for introducing this pattern in base::Thread.  It's bitten
> use several times over the course of the project.  If you see a better
> design, please don't hesitate to fix it.
>
> Adam


Already filed a bug: http://crbug.com/26365

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

[chromium-dev] PSA: Virtual dispatch doesn't work (as you might expect) in destructors!

[Jeremy Orlow]

I've spent a good deal of this week trying to track down what turned out to
be a simple but fairly common problem: I forgot virtual dispatch only
partially works in destructors.  There have been several email threads about
this, but it still bites us form time to time, so I thought it was worth
another reminder.


Details:
I subclassed ChromeThread which subclasses base::Thread.  base::Thread calls
CleanUp on the thread right before termination.  CleanUp is virtual.  Both
ChromeThread and my class override CleanUp().  base::Thread calls Stop() in
its destructor to stop the thread (if it hasn't already been stopped).  But
by the time you hit destruction, the vtable is no longer available and thus
the destructor of base::Thread (and anything it calls) does NOT have access
to the vtable of ChromeThread (or my class).  So, if you don't explicitly
call Stop(), your subclass's CleanUp method will NOT be called.  Thus the
thread was going away without my CleanUp method ever being called.

Obviously this affects more than just base::Thread.  And this is also how
you can hit errors with pure virtual methods being called.

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: Fwd: Switching vs2008 to be preferred when present.

[Jeremy Orlow]

>From http://dev.chromium.org/developers/how-tos/build-instructions-windows

Ensure that /MP is enabled.  You can do this by creating a file called inc
lude.gypi which contains the following lines:
   {
 'variables': {
   'msvs_multi_core_compile': 1
 }
   }

Put this file in a folder called .gyp under your home directory.  On
Windows, this will be something like: C:\Documents and
Settings\\.gyp\include.gypi, or if you are on Vista:
C:\Users\\.gyp\include.gypi. Make sure you run"gclient runhooks
--force" after creating this file to rebuild the project files, forcing GYP
to output /MP.



Btw, A month or two back someone posted build times from 2005 and 2008.
 2005 was faster.


On Thu, Oct 29, 2009 at 2:40 PM, Ben Goodger (Google) wrote:

> It does seem slower, however never having to remember to patch the
> appropriate vsprops/gypi with /MP is a big win. When I was ordering the new
> machines I found most people on the team I asked were not doing this, and as
> a result their builds were 2-3x slower.
>
> -Ben
>
> On Thu, Oct 29, 2009 at 2:38 PM, Mike Belshe  wrote:
>
>> I've been using VS2008 on Win7 for the last month or so.
>>
>> I hate it.
>>
>> Problems:
>>
>> 1) Stepping in the debugger is SOOO slow.  I am thinking about going
>> back to VS2005.
>> 2) If you turn on Intellisense, it crashes like crazy very regularly.
>>  I've turned off intellisense, but it is a big loss in productivity to do so
>>
>> I strongly recommend against VS2008; do others have these problems?
>>
>> Mike
>>
>>
>> On Thu, Oct 29, 2009 at 2:27 PM, Ben Goodger (Google) 
>> wrote:
>>
>>> FYI.
>>>
>>> VS2008 builds with /MP by default, and it's well supported, so when
>>> present there's no reason for us to not use it by default. Note that you can
>>> still force VS2005 by setting GYP_MSVS_VERSION=2005 in your environment.
>>>
>>> Thanks Brad!
>>>
>>> -Ben
>>>
>>> -- Forwarded message --
>>> From: 
>>> Date: Thu, Oct 29, 2009 at 2:26 PM
>>> Subject: Re: Switching vs2008 to be preferred when present.
>>> To: bradnel...@google.com
>>> Cc: gyp-develo...@googlegroups.com
>>>
>>>
>>> LGTM
>>>
>>>
>>> http://codereview.chromium.org/341041
>>>
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: [Green Tree] Task Force Status Update 10/26

[Jeremy Orlow]

On Tue, Oct 27, 2009 at 11:37 PM, Paweł Hajdan Jr.
wrote:

> On Wed, Oct 28, 2009 at 00:44, Ian Fette  wrote:
>
>> In an effort to provide more transparency into what the team is working
>> on, I'm sending out the meeting notes from the green tree task force to
>> chromium-dev, below. I will try to send further notes to chromium-dev from
>> our meetings.
>>
>
> Sounds great!
>
>
>>
>>- Flakiness
>>   - Brought down to acceptable levels for unit tests. Need help to
>>   keep it that way and not regress.
>>
>> I think that unit_tests are well and happy, but ui_tests are another
> story. We have UI tests which have more than 100 flaky flips in just two
> weeks. And we have UI tests which fail on almost every try run. IMHO such
> "outstanding" (is that the right word?) cases of flakiness should be fixed
> with a high enough priority.
>

A bunch of these are related to DOM Storage.  I'm pretty sure the cause is
related to what's causing a lot of crashes in the dev channel.  I'm working
actively to figure it outeven though it has been this way for a while
now.


> And we still have lots of problems with resource-related flakiness, like
> this:
>
> [FATAL:resource_bundle.cc(133)] Check failed: false.
>
> [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames->width() 
> % waiting_animation_frames->height() == 0.
>
> This is making all ui tests super-flaky. It's windows-specific, and I was
> asking about the issue several times on chromium-dev. Unfortunately, I don't
> know how to fix or even analyse it (but I can help). Please note that fixing
> this should visibly decrease flakiness of all ui tests, not only the Top25
> flaky ones.
>
>
> >
>

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

[chromium-dev] Re: [linux] how to work around nacl errors in 64-bit build

[Jeremy Orlow]

I'll follow up with the NaCl team to make sure they are.

On Wed, Oct 21, 2009 at 11:57 AM, John Grabowski  wrote:

>
>
> On Wed, Oct 21, 2009 at 11:37 AM, Jeremy Orlow wrote:
>
>> Why did you use the "internal nacl mailing list"?
>
>
> To keep things unambiguous and try for immediate action for a build-ish
> break.  Only members can view list members for the public lists.  I didn't
> want to join those lists just to confirm my mail would get sent to the right
> people.
>
>
>> This is an issue that affects all of Chromium.  The NaCl team members are
>> on chromium-dev, right?  If not, they should have been the day that our
>> fates became intertwined.
>
>
> I have no idea if nacl members are on chromium-dev.  I didn't want to
> assume and have the problem drop on the floor.
>
> 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: [linux] how to work around nacl errors in 64-bit build

[Jeremy Orlow]

Why did you use the "internal nacl mailing list"?  This is an issue that
affects all of Chromium.  The NaCl team members are on chromium-dev, right?
 If not, they should have been the day that our fates became intertwined.
J

On Tue, Oct 20, 2009 at 12:17 PM, John Grabowski  wrote:

> I sent mail to the nacl team and got reassurances(at 1138AM)  that they
> will hit it asap.  I didn't cc chromium-dev because I used the internal nacl
> mailing list.
> jrg
>
>
>  On Tue, Oct 20, 2009 at 12:15 PM, Scott Violet  wrote:
>
>>
>> I want to say this bug has existed for around a week now. Is anyone
>> working on making it so that we don't need to explicitly set
>> GYP_DEFINES for the build to work again?
>>
>>  -Scott
>>
>> On Tue, Oct 20, 2009 at 10:29 AM, Evan Martin  wrote:
>> >
>> > (Since I've been contacted by a bunch people independently about this
>> > problem already, here's one mail to hopefully point others who have
>> > the same problem.)
>> >
>> > Though we auto-detect your system architecture when we build, for
>> > reasons opaque to me this doesn't work with nacl.  I imagine someone
>> > is working on fixing it, but for now builds are broken.
>> >
>> > If you're getting errors like
>> >  /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome
>> > and you're on a 64-bit system then you need to do one of
>> >  1) export GYP_DEFINES='target_arch=x64'
>> >  2) export GYP_DEFINES='disable_nacl=1'
>> >
>> > And then re-run gyp.
>> >
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 API wrapper for Document

[Jeremy Orlow]

Darin knows for sure, but I'm not aware of any intentions on Google's part
to engineer such an elaborate API.  As long as it didn't add a
major maintenance burden (i.e. exposed things similar to one of the other
WebKit APIs) I'd imagine patches would be welcome though.
I believe only Darin can speak to this authoritatively, though.

J

On Tue, Oct 20, 2009 at 4:00 PM, Marshall Greenblatt  wrote:

> On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth  wrote:
>
>> It seems like we need to draw the line somewhere.  Otherwise, we'll
>> end up exposing the whole DOM via the WebKit API.  Where do you think
>> the optimum cut-off is?
>>
>
> I think treating the DOM as an XML-ish object tree would be the most
> reasonable approach.  This means:
>
> 1. The ability to walk the DOM hierarchy by following parent/child
> relationships.
> 2. The ability to get/set DOM attributes.
> 3. The ability to create/delete DOM objects at any level in the hierarchy.
> 4. The ability to set event listeners on DOM objects (perhaps using a
> v8::Function as the listener).
>
> Inputs would need to be sanity-checked by the API based on the underlying
> object context, but I don't think we need to provide separate API
> classes/methods for each possibility.
>
>
>> Adam
>>
>>
>> On Tue, Oct 20, 2009 at 1:55 PM, Marshall Greenblatt
>>  wrote:
>> > Hi All,
>> >
>> > The Chromium WebKit API does not currently provide a wrapper for the
>> > WebCore::Document object associated with a WebCore::Frame.  CEF
>> > (http://code.google.com/p/chromiumembedded), which also uses the WebKit
>> API,
>> > would like access to this object at the C++ level.  Is there interest in
>> the
>> > broader Chromium community for having a Document wrapper as part of the
>> > WebKit API?
>> >
>> > Thanks,
>> > Marshall
>> >
>> > >
>> >
>>
>
>
> >
>

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

[chromium-dev] Re: Crashing layout tests

[Jeremy Orlow]

What do you mean by "that"?  Updating the doc?
Btw, the original reason why I asked was that I wanted to confirm we all
agreed with this policy.  I guess it sounds like everyone does and the only
question is making sure everyone starts following it?

J

On Tue, Oct 20, 2009 at 11:28 AM, Dimitri Glazkov wrote:

> Yaar and I discussed making changes to that effect last week, he's
> working on that.
>
> :DG<
>
> On Tue, Oct 20, 2009 at 10:33 AM, David Levin  wrote:
> > If it isn't written
> > here http://dev.chromium.org/developers/how-tos/webkit-merge-1, then
> (imo)
> > it isn't policy for gardener. :) Given that not everyone is in the same
> > place, if it isn't written in the standard place, how will folks know?
> > Even then, if you add something new, it would be nice to tell folks b/c
> I'm
> > sure not everyone checks that every time they start gardening.
> > dave
> > On Tue, Oct 20, 2009 at 10:25 AM, Jeremy Orlow 
> wrote:
> >>
> >> On Tue, Oct 20, 2009 at 10:19 AM, David Levin  wrote:
> >>>
> >>> That sounds like a reasonable policy.
> >>
> >> Hmm...I thought this was the policy.  I guess not?  :-)
> >>
> >>>
> >>> There is the current idea of figuring out something about the crash
> >>> before filing a bug, which clashes with this idea.
> >>> What text would you add
> >>> to http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell
> how to
> >>> deal with these? Here's one idea (add it in red?):
> >>>
> >>> If you must roll WebKit DEPS and pick up new crashers, you should enter
> >>> an individual bug for each new crasher immediately and make it P0.
> >>>
> >>> Then what about assigning. Does it go to the unlucky webkit gardener
> who
> >>> happened to have the duty that day? (If they have another day of
> gardening,
> >>> then these bug linger.)
> >>
> >> If the gardener has time, sure.  If not, maybe assign it to whomever
> makes
> >> the most sense.  And, when there's no obvious candidate, they can draft
> >> someone.  (In general, I think we should empower gardeners to draft
> people
> >> when there are lots of high prioirity items stacking up and/or we get
> really
> >> behind ToT.)
> >>>
> >>> On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow 
> >>> wrote:
> >>>>
> >>>> Today I noticed a bunch of recently added CRASH test expectations for
> >>>> layout tests.  I know that we sometimes have to roll in a crasher or
> two,
> >>>> but aren't we supposed to be filing p0-p1, dev channel release
> blockers at
> >>>> least until we can prove the crash is not exploitable in the browser
> and
> >>>> ideally not before the crash is fixed??
> >>>> Btw:
> >>>> $ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
> >>>>   56
> >>>> And many of them are fairly new.
> >>>> 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: Crashing layout tests

[Jeremy Orlow]

On Tue, Oct 20, 2009 at 10:19 AM, David Levin  wrote:

> That sounds like a reasonable policy.


Hmm...I thought this was the policy.  I guess not?  :-)


> There is the current idea of figuring out something about the crash before
> filing a bug, which clashes with this idea.
> What text would you add to
> http://dev.chromium.org/developers/how-tos/webkit-merge-1 to tell how to
> deal with these? Here's one idea (add it in red?):
>
> If you must roll WebKit DEPS and pick up new crashers, you should enter an
> individual bug for each new crasher immediately and make it P0.
>
>
> Then what about assigning. Does it go to the unlucky webkit gardener who
> happened to have the duty that day? (If they have another day of gardening,
> then these bug linger.)
>

If the gardener has time, sure.  If not, maybe assign it to whomever makes
the most sense.  And, when there's no obvious candidate, they can draft
someone.  (In general, I think we should empower gardeners to draft people
when there are lots of high prioirity items stacking up and/or we get really
behind ToT.)

On Tue, Oct 20, 2009 at 9:23 AM, Jeremy Orlow  wrote:
>
>> Today I noticed a bunch of recently added CRASH test expectations for
>> layout tests.  I know that we sometimes have to roll in a crasher or two,
>> but aren't we supposed to be filing p0-p1, dev channel release blockers at
>> least until we can prove the crash is not exploitable in the browser and
>> ideally not before the crash is fixed??
>> Btw:
>> $ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
>>   56
>>
>> And many of them are fairly new.
>>
>> 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] Crashing layout tests

[Jeremy Orlow]

Today I noticed a bunch of recently added CRASH test expectations for layout
tests.  I know that we sometimes have to roll in a crasher or two, but
aren't we supposed to be filing p0-p1, dev channel release blockers at least
until we can prove the crash is not exploitable in the browser and ideally
not before the crash is fixed??
Btw:
$ grep CRASH test_expectations.txt | egrep -v '^//' | wc -l
  56

And many of them are fairly new.

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: LTTF helping the GTTF make cycle times *minutes* faster

[Jeremy Orlow]

On Fri, Oct 16, 2009 at 2:34 PM, Ojan Vafai  wrote:

> Thanks for everyone's help. Good overnight progress. 6 media tests skipped.
> 2 tests marked SLOW. 5 assigned.
>
> 12 unassigned general tests.
> 10 unassigned Mac plugin tests.
>
> Any takers?
>
> WIN/LINUX/MAC
> LayoutTests/fast/dom/cssTarget-crash.html
> LayoutTests/fast/events/add-event-without-document.html
> LayoutTests/http/tests/history/back-to-post.php
>
> LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html
> LayoutTests/http/tests/security/cross-frame-access-document-direct.html
> LayoutTests/http/tests/security/xss-DENIED-defineProperty.html
> LayoutTests/http/tests/xmlhttprequest/methods-async.html
> LayoutTests/loader/go-back-to-different-window-size.html
>
> LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html
>


> LayoutTests/storage/domstorage/localstorage/iframe-events.html
> LayoutTests/storage/domstorage/sessionstorage/iframe-events.html
>

I'll try to look at this within the next week.


> LINUX/MAC
> LayoutTests/http/tests/misc/timer-vs-loading.html
>
> MAC
> LayoutTests/http/tests/plugins/get-url.html
> LayoutTests/http/tests/plugins/interrupted-get-url.html
> LayoutTests/http/tests/plugins/npapi-response-headers.html
>  LayoutTests/http/tests/plugins/post-url-file.html
>
> LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html
> LayoutTests/plugins/destroy-stream-twice.html
> LayoutTests/plugins/embed-inside-object.html
> LayoutTests/plugins/geturl-replace-query.html
> LayoutTests/plugins/npruntime.html
>
> LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html
>
>
> ANTONM
> LayoutTests/fast/dom/Window/window-property-shadowing-name.html
>
> YUTAK
> LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html
> LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html
> LayoutTests/http/tests/navigation/onload-navigation-iframe.html
>
> YUZO
> LayoutTests/fast/loader/local-JavaScript-from-local.html
>
>
> On Thu, Oct 15, 2009 at 6:38 PM, Ojan Vafai  wrote:
>
>> There are a lot of tests that consistently (i.e. not flaky) timeout. They
>> eat up significant percentage (~10%!) of the cycle time for the test bots
>> (e.g., >1 minute on Windows release). If LTTF folk focus some effort on
>> fixing these first, it would help all of us move forward faster as the bot
>> cycle times would be improved as would the times to run the tests locally.
>>
>> To make this easier, I compiled the list of all the tests that
>> consistently timeout. I excluded the flaky timeouts since the LTTF is
>> currently focused on non-flaky failures. Any takers?
>>
>>  Ojan
>>
>>
>> ALL PLATFORMS:
>> LayoutTests/fast/dom/Window/window-property-shadowing-name.html
>> LayoutTests/fast/dom/cssTarget-crash.html
>> LayoutTests/fast/events/add-event-without-document.html
>> LayoutTests/http/tests/history/back-to-post.php
>>
>> LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html
>> LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html
>> LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html
>> LayoutTests/http/tests/navigation/onload-navigation-iframe.html
>> LayoutTests/http/tests/security/cross-frame-access-document-direct.html
>> LayoutTests/http/tests/security/xss-DENIED-defineProperty.html
>> LayoutTests/http/tests/xmlhttprequest/methods-async.html
>> LayoutTests/loader/go-back-to-different-window-size.html
>> LayoutTests/media/audio-constructor-src.html
>> LayoutTests/media/audio-play-event.html
>> LayoutTests/media/controls-drag-timebar.html
>> LayoutTests/media/event-attributes.html
>> LayoutTests/media/video-no-audio.html
>> LayoutTests/media/video-source-add-src.html
>>
>> LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html
>> LayoutTests/storage/domstorage/localstorage/iframe-events.html
>> LayoutTests/storage/domstorage/sessionstorage/iframe-events.html
>>
>> WIN RELEASE+DEBUG:
>> LayoutTests/http/tests/cache/subresource-expiration.html
>>
>> WIN DEBUG:
>> LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html
>>
>> LINUX RELEASE+DEBUG:
>> LayoutTests/fast/loader/local-JavaScript-from-local.html
>> LayoutTests/http/tests/misc/timer-vs-loading.html
>>
>> LINUX DEBUG:
>> LayoutTests/fast/css/large-list-of-rules-crash.html
>> LayoutTests/fast/frames/frame-limit.html
>>
>> MAC RELEASE+DEBUG:
>> LayoutTests/fast/loader/local-JavaScript-from-local.html
>> LayoutTests/http/tests/misc/timer-vs-loading.html
>> LayoutTests/http/tests/plugins/get-url.html
>> LayoutTests/http/tests/plugins/interrupted-get-url.html
>> LayoutTests/http/tests/plugins/npapi-response-headers.html
>> LayoutTests/http/tests/plugins/post-url-file.html
>>
>> LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html
>> LayoutTests/plugins/destroy-stream-twice.html
>> LayoutTests/plugins/embed-inside-object.html
>> LayoutTest

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Thu, Oct 15, 2009 at 12:17 PM, Michael Nordman wrote:

>
>
> On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman wrote:
>
>>
>>
>> On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow wrote:
>>
>>> On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher wrote:
>>>>
>>>>> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth wrote:
>>>>>
>>>>>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
>>>>>> wrote:
>>>>>> > As mentioned f2f, this falls apart as soon as Chrome tries to
>>>>>> manufacture a
>>>>>> > security origin. I'm not sure, may already have instances of that in
>>>>>> the
>>>>>> > code base for all I know.
>>>>>>
>>>>>> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
>>>>>> There's a lot of tricky work in the canonicalization that we don't
>>>>>> want to duplicate.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>
>>>>>
>>>>> Agreed, and we shouldn't be in that business.  I think for all our use
>>>>> cases, the
>>>>> factory for security origins can be WebCore.
>>>>>
>>>>> Chrome just needs to be able to serialize / de-serialize a security
>>>>> origin, compare
>>>>> them, and possibly access some component parts (though I'm not certain
>>>>> of this
>>>>> requirement).
>>>>>
>>>>
>>>> I think i have use cases for creating an 'origin' based on a GURL.
>>>>
>>>
>>> We've talked through these repeatedly and I think we've made good cases
>>> against them.  WebCore canonicalizes security origins.  At the moment, we
>>> never create "security origins" in Chrome.
>>>
>>
>> I wasn't implying that webcore's origin code wasn't doing the work, just
>> mentioning the use case of determining an origin based on a url. Something
>> like this could work.
>>
>> // Returns the security origin associated with the given url.
>> (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL &url);
>>
>>
>>> You've given some examples of where we _might_ (read: this is vaporware)
>>> do this in the future.  For all the use cases I've seen so far, I would
>>> actually propose adding a canonicalizeSecurityOrigin() method to
>>> WebSecurityOrigin that would create a WebCore::SecurityOrigin and then
>>> immediately toString() it.
>>>
>>
>>> What other use cases are there?  With each one, please make clear whether
>>> it's something we need today or whether it's something you suspect we'll
>>> need in the future...because I think most if not all of them are in this
>>> second bucket.  And I don't want us to code ourselves into a corner, but I
>>> also don't want us to write a bunch of dead code that may be used in the
>>> future.
>>>
>>
>> The use case is tracking usage per-origin in the appcache code. This isn't
>> a hypothetical thing.
>>
>
> And also restricting access to resources based on origins, also not a
> hypothetical thing.
>

I don't think I ever used the word "hypothetical".

Anyway, I think the WebSecurityOrigin::fromURL(blah)->toString() will work
fine in this use case.  But I might create a static method that's a shortcut
for that just to make it super obvious to users.

--~--~-~--~~~---~--~~
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: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman wrote:

>
>
> On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth  wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
>>> wrote:
>>> > As mentioned f2f, this falls apart as soon as Chrome tries to
>>> manufacture a
>>> > security origin. I'm not sure, may already have instances of that in
>>> the
>>> > code base for all I know.
>>>
>>> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
>>> There's a lot of tricky work in the canonicalization that we don't
>>> want to duplicate.
>>>
>>> Adam
>>>
>>
>>
>> Agreed, and we shouldn't be in that business.  I think for all our use
>> cases, the
>> factory for security origins can be WebCore.
>>
>> Chrome just needs to be able to serialize / de-serialize a security
>> origin, compare
>> them, and possibly access some component parts (though I'm not certain of
>> this
>> requirement).
>>
>
> I think i have use cases for creating an 'origin' based on a GURL.
>

We've talked through these repeatedly and I think we've made good cases
against them.  WebCore canonicalizes security origins.  At the moment, we
never create "security origins" in Chrome.

You've given some examples of where we _might_ (read: this is vaporware) do
this in the future.  For all the use cases I've seen so far, I would
actually propose adding a canonicalizeSecurityOrigin() method to
WebSecurityOrigin that would create a WebCore::SecurityOrigin and then
immediately toString() it.

What other use cases are there?  With each one, please make clear whether
it's something we need today or whether it's something you suspect we'll
need in the future...because I think most if not all of them are in this
second bucket.  And I don't want us to code ourselves into a corner, but I
also don't want us to write a bunch of dead code that may be used in the
future.

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

[chromium-dev] Re: Canary bot, now with formatted layout test results

[Jeremy Orlow]

Christmas came early for anyone working on WebKit!  Thanks Glen.  :-)

On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry  wrote:

>
> This makes me very happy!
>
> 2009/10/15 Glenn Wilson :
> > Hi Webkit gardeners,
> > The Windows canary bot now generates formatted layout test results on
> each
> > build that had unexpected failing layout tests, which means you can
> quickly
> > see layout test failures, diffs, and upstream baselines without running
> the
> > tool manually. The goal of this output is to help gardeners assess what
> may
> > have changed, and how to best handle the failure.
> > For example, here are the failures for build 13359:
> >
> http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html
> > To see the formatted layout test failures for a specific canary build,
> just
> > click on the "layout test results" link in the "archive webkit test
> results"
> > step, then click on the "index-.html" file.
> > There's still more work to do, including getting the formatter working
> > properly on the Mac & Linux canaries, adding flakiness data, adding a
> link
> > directly to the waterfall display, and more.  Many thanks go to Ojan,
> > Nicolas and all others who endured my many code reviews, and Eric Roman
> and
> > Dimitri for the original spec and design.
> > Please let me know what you think, and what changes you'd like to see.
> > Glenn
> >
> >
> > >
> >
>
>
>
> --
> Erik Corry, Software Engineer
> Google Denmark ApS.  CVR nr. 28 86 69 84
> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
> Copenhagen K, Denmark.
>
> >
>

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

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

I guess you're rightabout pretty much everything.
I'll put it in chrome/common then?  (Note I actually wasn't planning on
putting it in base unless the API depended on it, but it seemed like
including that would just make what I was saying more confusing.)

On Thu, Oct 15, 2009 at 12:19 AM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 7:17 PM, Jeremy Orlow  wrote:
>
>> I think the main points of contention regarding SecurityOrigin::toString()
>> are the name "toString" and what type it should return.
>>
>> In terms of the names:  I think we should provide constructors and getters
>> for each "component" of each WebKit API type.  So, for example,
>> WebSecurityOrigin should have a constructor that takes in a single string
>> and a getter called |origin|.
>>
>
> It seems strange for something that is an origin to have a getter named
> origin.  It leads to code like this: origin->origin(), which seems bad to
> me.
>
> toString() is the name used by WebCore, and it seems reasonable to me.  It
> is merely a method that returns a string representation of the
> SecurityOrigin suitable for pickling.  What is your objection to toString?
>
>
>
>>  (We can argue about the name later.)  base::SecurityOrigin
>>
>
> I mentioned before that base is not the right place for SecurityOrigin.
>  See Brett's posts about what should and shouldn't be part of base/.  It is
> a dumping ground today, and we should resist more of that will full force.
>  In this case, only webkit/glue and above needs this type, so it does not
> need to live in base/.
>
>
>
>> can then have a method to produce WebSecurityOrigins (using that
>> constructor that takes in the base componentswhich is just "origin" in
>> this classes case) and it can have a constructor that takes in a
>> WebSecurityOrigin (which will construct itself by using the aforementioned
>> getter(s)).
>>
>
> This seems fine to me provided we actually need WebSecurityOrigin or
> SecurityOrigin to expose the component parts.  However, I haven't seen any
> use cases for that yet.  Maybe I have missed them?
>
>
>
>>
>> In terms of what it should return:  Each "component" should really be a
>> C++ primitive.  This of course leaves the question of how to handle strings.
>>  Personally, I think we should do one of 2 things:  Either WebString should
>> expose its components (an array of unsigned shorts + a size_t)
>>
>
> WebString already has accessors for the array of unsigned shorts and a
> size_t for the length.
>
>
>
>> or we should just put string16 into the WebKit API.  The latter is not as
>> insane as it sounds: it's just a special case of std::string.  The former
>> isn't that insane either since it can be fed directly to a std::string(16)
>> constructor.
>>
>
> The WebKit API is intended to be usable by consumers who do not have a full
> STL implementation (e.g., Android).
>
>
>
>>
>> If we add the proper constructors and factories for WebKit types to
>> NullableString16, GURL, SecurityOrigin, and any other types we might want to
>> connect to WebKit types in the future, then we can actually make the
>> dependency 100% one way.
>>
>
> It is OK for the WebKit API to know about GURL since WebCore depends on
> googleurl (specifically the generic, implementation bits).  However, since
> GURL uses STL, there is just an optional (#ifdef controlled) conversion
> helper on WebURL for it.
>
> The same does not apply for NullableString16 or SecurityOrigin.
>
>
>
>>
>> I guess I feel like we should either say that depending on base types is
>> OK (as long as we think they'll be very stable implementation wise) or we
>> should say they're never allowed.  This middle ground just feels wrong.
>>  Note that the difference between toString and a single getter that returns
>> a string is subtle, but if all WebKit types follow this same convention,
>> then it's much less likely that people will do stupid things with them.
>>
>>
> I generally prefer all or nothing approaches too, but the implicit
> conversions to string16 and std::string are extremely nice.  I don't want to
> give them up.  At the same time, I object to building further dependencies
> on base from svn.webkit.org.
>
> NullableString16 seemed like a reasonable addition since it is just a
> slight variant of string16 that we can probably afford to treat as frozen.
>
> -Darin
>
>
>
>
>> J
>>
>>
>> On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher  wrote:
>>
&g

[chromium-dev] Re: When disabling a test, please assign to whoever wrote it

[Jeremy Orlow]

This is still happening.  VERY annoying.  ANYONE who is disabling tests,
marking them flaky, etc needs to take the 30 seconds required to svn blame
the file and cc people the relevant people.

On Tue, Sep 22, 2009 at 2:33 PM, Aaron Boodman  wrote:

>
> Seriously. In a project as big as Chrome, tests are *critical* and a
> disabled test can hurt a team within just a few days. This has
> happened to me a few times and it is terrifying to find out a test
> that you think was proving you are working had actually been disabled.
>
> Disabling bad tests is super important, and I'm not arguing against
> that. Just make sure that someone knows that it was done who can take
> action on it.
>
> - a
>
> On Tue, Sep 22, 2009 at 12:40 PM, John Abd-El-Malek 
> wrote:
> > It only takes a few moments to figure out this information, and ensures
> that
> > the bug lands on the right person's desk.
> > http://src.chromium.org/viewvc/chrome/trunk/src/ can show who wrote the
> > initial test
> > For commits before we moved to the open source repository, look
> > at http://chrome-corpsvn.mtv/viewvc/trunk/?root=chrome  (internal only)
> >
> > 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: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

I think the main points of contention regarding SecurityOrigin::toString()
are the name "toString" and what type it should return.

In terms of the names:  I think we should provide constructors and getters
for each "component" of each WebKit API type.  So, for example,
WebSecurityOrigin should have a constructor that takes in a single string
and a getter called |origin|.  (We can argue about the name later.)
 base::SecurityOrigin can then have a method to produce WebSecurityOrigins
(using that constructor that takes in the base componentswhich is just
"origin" in this classes case) and it can have a constructor that takes in a
WebSecurityOrigin (which will construct itself by using the aforementioned
getter(s)).

In terms of what it should return:  Each "component" should really be a C++
primitive.  This of course leaves the question of how to handle strings.
 Personally, I think we should do one of 2 things:  Either WebString should
expose its components (an array of unsigned shorts + a size_t) or we should
just put string16 into the WebKit API.  The latter is not as insane as it
sounds: it's just a special case of std::string.  The former isn't that
insane either since it can be fed directly to a std::string(16) constructor.

If we add the proper constructors and factories for WebKit types to
NullableString16, GURL, SecurityOrigin, and any other types we might want to
connect to WebKit types in the future, then we can actually make the
dependency 100% one way.

I guess I feel like we should either say that depending on base types is OK
(as long as we think they'll be very stable implementation wise) or we
should say they're never allowed.  This middle ground just feels wrong.
 Note that the difference between toString and a single getter that returns
a string is subtle, but if all WebKit types follow this same convention,
then it's much less likely that people will do stupid things with them.

J


On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow  wrote:
>
>> You mean string16, right?
>
>
> I see instances of std::string and string16.  I would be happiest if we
> unified on one.  string16 is probably the path of least resistance.
>
>  std::string has the benefit of being more compact, which for something
> like this which is really just a bag of bytes is probably a good thing.
>
>
>
>>
>> I really don't think it buys us much if it's purely optional that people
>> put the security origin (in string representation) into a wrapper that then
>> blocks them from doing anything silly with it.
>>
>
> we could give it a ToString() method.  i think the point of SecurityOrigin
> would be to guide people in the right direction.
>
> -darin
>
>
>
>>
>> More to the point, I don't think it's useful enough that I'm going to
>> bother implementing it.  If someone else wants to, I'd probably use it.
>>
>>
>> On Wed, Oct 14, 2009 at 4:47 PM, Darin Fisher  wrote:
>>
>>> To be clear:  I only weakly advocate Chrome having a SecurityOrigin.  I'm
>>> also OKwith just using std::string.  I think either is better than using
>>> GURL.
>>>
>>> -Darin
>>>
>>>
>>> On Wed, Oct 14, 2009 at 4:45 PM, Darin Fisher wrote:
>>>
>>>> Hmm... it seems useful as a means of making the code more
>>>> self-documenting anda bit safer.  I'd rather not have people passing
>>>> strings for origins since they might be
>>>> tempted to parse the strings.
>>>>
>>>> The momentary translation to strings on the boundary of the WebKit API
>>>> does not
>>>> completely make this fragile.  If the end-points in Chrome use
>>>> SecurityOrigin and
>>>> the end-points in the WebKit API use WebSecurityOrigin, then developers
>>>> will be
>>>> naturally inclined to convert between SecurityOrigin and
>>>> WebSecurityOrigin,
>>>> ignoring the toString() getter on WebSecurityOrigin.
>>>>
>>>> This is a case where existing code should help guide people in the right
>>>> direction.
>>>>
>>>> -Darin
>>>>
>>>>
>>>>
>>>> On Wed, Oct 14, 2009 at 4:39 PM, Jeremy Orlow wrote:
>>>>
>>>>> If this is the case, then I don't think a SecurityOrigin wrapper buys
>>>>> us anything.  Never mind.
>>>>>
>>>>>
>>>>> On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher wrote:
>>>>>
>>>>>>
>>>>>>
>>>&g

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

You mean string16, right?
I really don't think it buys us much if it's purely optional that people put
the security origin (in string representation) into a wrapper that then
blocks them from doing anything silly with it.

More to the point, I don't think it's useful enough that I'm going to bother
implementing it.  If someone else wants to, I'd probably use it.

On Wed, Oct 14, 2009 at 4:47 PM, Darin Fisher  wrote:

> To be clear:  I only weakly advocate Chrome having a SecurityOrigin.  I'm
> also OKwith just using std::string.  I think either is better than using
> GURL.
>
> -Darin
>
>
> On Wed, Oct 14, 2009 at 4:45 PM, Darin Fisher  wrote:
>
>> Hmm... it seems useful as a means of making the code more self-documenting
>> anda bit safer.  I'd rather not have people passing strings for origins
>> since they might be
>> tempted to parse the strings.
>>
>> The momentary translation to strings on the boundary of the WebKit API
>> does not
>> completely make this fragile.  If the end-points in Chrome use
>> SecurityOrigin and
>> the end-points in the WebKit API use WebSecurityOrigin, then developers
>> will be
>> naturally inclined to convert between SecurityOrigin and
>> WebSecurityOrigin,
>> ignoring the toString() getter on WebSecurityOrigin.
>>
>> This is a case where existing code should help guide people in the right
>> direction.
>>
>> -Darin
>>
>>
>>
>> On Wed, Oct 14, 2009 at 4:39 PM, Jeremy Orlow wrote:
>>
>>> If this is the case, then I don't think a SecurityOrigin wrapper buys us
>>> anything.  Never mind.
>>>
>>>
>>> On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher wrote:
>>>
>>>>
>>>>
>>>> On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow wrote:
>>>>
>>>>> On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher wrote:
>>>>>
>>>>>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:
>>>>>>
>>>>>>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow >>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
>>>>>>>>>> micha...@google.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> +1 SecurityOrigin class
>>>>>>>>>>> Sounds like a reasonable plan.
>>>>>>>>>>> I suspect there may already be cases where we're actually
>>>>>>>>>>> comparing a chrome generated security origin, as produced by
>>>>>>>>>>> GURL.GetOrigin(), with a webkit generated security origin, as 
>>>>>>>>>>> produced by
>>>>>>>>>>> WebSecurityOrigin.toString(). So we may want to accelerate the part 
>>>>>>>>>>> of the
>>>>>>>>>>> plan to do more than opaquely pass around and test webkit generated
>>>>>>>>>>> representations.
>>>>>>>>>>>
>>>>>>>>>>> Also, I think dumi has a use case to crack it open in order to
>>>>>>>>>>> form file path elements of the form 'scheme_host_port'
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Actually, Dumi's case is slightly different.  He wants to get
>>>>>>>>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>>>>>>>>>> should
>>>>>>>>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dumi has such a method in a CL that he is working on at the moment.
>>>>>>>>>  Also, note: we don't have a way to use FilePath from the WebKit API, 
>>>>>>>>> and
>>>>>>>>> I'm not sure that we should.  We use WebString for file paths in the 
>>>>>>>>> WebKit
>>>>>>>>> API.
>>

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

If this is the case, then I don't think a SecurityOrigin wrapper buys us
anything.  Never mind.

On Wed, Oct 14, 2009 at 4:37 PM, Darin Fisher  wrote:

>
>
> On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher  wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:
>>>
>>>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>>>
>>>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>>>>>
>>>>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>>>>>
>>>>>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
>>>>>>> micha...@google.com> wrote:
>>>>>>>
>>>>>>>> +1 SecurityOrigin class
>>>>>>>> Sounds like a reasonable plan.
>>>>>>>> I suspect there may already be cases where we're actually comparing
>>>>>>>> a chrome generated security origin, as produced by GURL.GetOrigin(), 
>>>>>>>> with a
>>>>>>>> webkit generated security origin, as produced by
>>>>>>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of 
>>>>>>>> the
>>>>>>>> plan to do more than opaquely pass around and test webkit generated
>>>>>>>> representations.
>>>>>>>>
>>>>>>>> Also, I think dumi has a use case to crack it open in order to form
>>>>>>>> file path elements of the form 'scheme_host_port'
>>>>>>>>
>>>>>>>
>>>>>>> Actually, Dumi's case is slightly different.  He wants to get
>>>>>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>>>>>>> should
>>>>>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>>>>>
>>>>>>
>>>>>> Dumi has such a method in a CL that he is working on at the moment.
>>>>>>  Also, note: we don't have a way to use FilePath from the WebKit API, and
>>>>>> I'm not sure that we should.  We use WebString for file paths in the 
>>>>>> WebKit
>>>>>> API.
>>>>>>
>>>>>
>>>>> So then he's adding such a method to WebSecurityOrigin that returns a
>>>>> string?  If so, sounds good.  What's the CL, btw?
>>>>>
>>>>
>>>> Yes:
>>>> http://codereview.chromium.org/256073/diff/11001/11029
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>  ... and why not use strings?
>>>>>>>> * does the string contain a trailing slash, or not?
>>>>>>>> * in the default port case, does the string contain the default port
>>>>>>>> number or not?
>>>>>>>>
>>>>>>>
>>>>>>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult
>>>>>>> for a base::SecurityOrigin to be constructed any way besides it coming 
>>>>>>> from
>>>>>>> WebKit::WebSecurityOrigin (which only comes from
>>>>>>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>>>>>>> if/when we need to.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Right now, we don't have a good story for what to do with
>>>>>>>>> WebCore::SecurityOrigins in Chromium.  We now have a 
>>>>>>>>> WebSecurityOrigin in
>>>>>>>>> WebKit, but if you want to move the data between processes, you need 
>>>>>>>>> to
>>>>>>>>> convert it to a string and then send that.  In some cases we then 
>>>>>>>>> convert
>>>>>>>>> the string to a GURL, but this seems like the wrong thing to do (more 
>>>>>>>>> on
>>>>>>>>> this in a sec).
>>>>>>>>> To me, the right answer is to create a type in base called
>>>>>>>>> SecurityOrigin that wraps a string and does

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 4:32 PM, Michael Nordman wrote:

>
>
> On Wed, Oct 14, 2009 at 4:03 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc wrote:
>>
>>>
>>>
>>> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher wrote:
>>>
>>>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>>>
>>>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>>>>>
>>>>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>>>>>
>>>>>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman <
>>>>>>> micha...@google.com> wrote:
>>>>>>>
>>>>>>>> +1 SecurityOrigin class
>>>>>>>> Sounds like a reasonable plan.
>>>>>>>> I suspect there may already be cases where we're actually comparing
>>>>>>>> a chrome generated security origin, as produced by GURL.GetOrigin(), 
>>>>>>>> with a
>>>>>>>> webkit generated security origin, as produced by
>>>>>>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of 
>>>>>>>> the
>>>>>>>> plan to do more than opaquely pass around and test webkit generated
>>>>>>>> representations.
>>>>>>>>
>>>>>>>> Also, I think dumi has a use case to crack it open in order to form
>>>>>>>> file path elements of the form 'scheme_host_port'
>>>>>>>>
>>>>>>>
>>>>>>> Actually, Dumi's case is slightly different.  He wants to get
>>>>>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin 
>>>>>>> should
>>>>>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>>>>>
>>>>>>
>>>>>> Dumi has such a method in a CL that he is working on at the moment.
>>>>>>  Also, note: we don't have a way to use FilePath from the WebKit API, and
>>>>>> I'm not sure that we should.  We use WebString for file paths in the 
>>>>>> WebKit
>>>>>> API.
>>>>>>
>>>>>
>>>>> So then he's adding such a method to WebSecurityOrigin that returns a
>>>>> string?  If so, sounds good.  What's the CL, btw?
>>>>>
>>>>
>>>> Yes:
>>>> http://codereview.chromium.org/256073/diff/11001/11029
>>>>
>>>>
>>> we decided to use GURLs instead of string16s to represent SecurityOrigins
>>> on the chromium side, so we don't need a
>>> (Web)SecurityOrigin::toFilePath()-like method anymore; we can just do
>>> GURL(SecurityOrigin::toString()), and then create a file path from
>>> GURL::scheme(), GURL::host() and GURL::port().
>>>
>>
>> The point of this thread is that we should not be converting
>> SecurityOrigins of GURLs.  I believe michaeln was the primary proponent of
>> this and I believe we convinced him that we shouldn't be doing it.  And I
>> believe most if not all the reasons why were in my original email.
>>  (Michael, correct me if I'm wrong.)
>>
>
> I think i have two primary concerns.
>
> 1) What is the format of the data written to disk that we need to support
> going forward since it is on disk. We need a decision that we can stick
> with.
>
> 2) What measures are in place to ensure that we're actually persisting data
> in that prescribed format today.
>
> Having 'strings' float around makes me uneasy on that second point. If
> chrome can't validate these string values are in the prescribed format (its
> not smart enough to reason about them), how can we assert we've got it right
> (inspection doesn't work well... working backwards from a callsite in chrome
> browser code storing an 'origin' string to the source of that string being
> produced is just not practical).
>
> Given the current state of affairs, i still think GURL is a better option.
> Given a GURL, we can reason about it (produce path elements, produce a
> canonical string representation, test if another GURL falls in that origin
> or not (we do that in appcache code sans webkit)). The "null" security
> origin is an odd corner case that gives the GURL representation grief.
>

We don't need to reason about it.  WebCore::SecurityOrigin c

[chromium-dev] Re: layout test dashboard goofup

[Jeremy Orlow]

I haven't actually gotten anything done on LocalStorage this week because
I've been doing so many small side projects like this.but if it's a
priority, sure.
How about a cron job on some machine that ssh's via a cert into whatever
machines the data is stored on, pulls it back, and dumps it into some dir?
 When we start filling up the hard drive, we can look at doing something
smarter, deleting old data, or putting it somewhere like GFS.

What server can I use and where's the data stored?
On Wed, Oct 14, 2009 at 4:17 PM, Evan Martin  wrote:

> Sounds like we've got a volunteer!  :D :D :D
>
> On Wed, Oct 14, 2009 at 4:15 PM, Jeremy Orlow  wrote:
> > I assume we're going to start backing this data up from now on?
> >
> > On Wed, Oct 14, 2009 at 4:13 PM, Peter Kasting 
> wrote:
> >>
> >> On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai  wrote:
> >>>
> >>> I accidentally checked in some test code (one number was wrong!) and
> >>> clobbered all but 10 of the runs of data for each builder. There's no
> way to
> >>> recover it.
> >>
> >> Do you moonlight for the Danger team at Microsoft?
> >> 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: layout test dashboard goofup

[Jeremy Orlow]

I assume we're going to start backing this data up from now on?

On Wed, Oct 14, 2009 at 4:13 PM, Peter Kasting  wrote:

> On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai  wrote:
>
>> I accidentally checked in some test code (one number was wrong!) and
>> clobbered all but 10 of the runs of data for each builder. There's no way to
>> recover it.
>
>
> Do you moonlight for the Danger team at Microsoft?
>
> 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: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman wrote:

>
>
> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:
>>
>>> +1 SecurityOrigin class
>>> Sounds like a reasonable plan.
>>> I suspect there may already be cases where we're actually comparing a
>>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>>> webkit generated security origin, as produced by
>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
>>> plan to do more than opaquely pass around and test webkit generated
>>> representations.
>>>
>>> Also, I think dumi has a use case to crack it open in order to form file
>>> path elements of the form 'scheme_host_port'
>>>
>>
>> Actually, Dumi's case is slightly different.  He wants to get
>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
>> have a databaseIdentifier() method that outputs a FilePath object?
>>
>
> Dumi needs to form file path elements, yes.
>
> Dumi also needs to store a canonical string representation of an 'origin'
> in the tracker database which will equate to the canonical string
> represetation 6 months from now (either that or upgrade the column values
> whenever that representation changes). Q: What is the canonical string
> representation used in the localstorage.db which has the similar requirement
> to track things per origin? Probably WebCore::SecurityOrigin::toString(), is
> that right?
>

LocalStorage uses SecurityOrigin::databaseIdentifier() from within WebCore.

Those two things probably shouldn't be confounded.
>
> At some point in the not too distant future, we'll need to interrogate from
> a ChromeUI  database, localstorage, appcache, and (filesystem) for what
> 'origins' are making how heavy a use of those systems.
>

We can add these methods as necessary.  We may need to add the methods to
the WebSecurityOrigin since base::SecurityOrigin will be dumb.

An important point is that code today is writing string values, and code 6
> months from now has to interpret those values and match against them.
>
>
>> ... and why not use strings?
>>> * does the string contain a trailing slash, or not?
>>> * in the default port case, does the string contain the default port
>>> number or not?
>>>
>>
>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult for
>> a base::SecurityOrigin to be constructed any way besides it coming from
>> WebKit::WebSecurityOrigin (which only comes from
>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>> if/when we need to.
>>
>
> As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a
> security origin. I'm not sure, may already have instances of that in the
> code base for all I know.
>
>
>>
>>
>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:
>>>
>>>> Right now, we don't have a good story for what to do with
>>>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
>>>> WebKit, but if you want to move the data between processes, you need to
>>>> convert it to a string and then send that.  In some cases we then convert
>>>> the string to a GURL, but this seems like the wrong thing to do (more on
>>>> this in a sec).
>>>> To me, the right answer is to create a type in base called
>>>> SecurityOrigin that wraps a string and does equality checks.  The equality
>>>> checks can be done as string comparisons since the
>>>> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in the
>>>> future, we need to do anything more with SecurityOrigins (besides
>>>> transporting them, testing equality, and using them in sets/maps) then we
>>>> can make the class more complex.
>>>>
>>>> Why not use GURL?  For one, the SecurityOrigin has a "null" state which
>>>> is significant and which isn't represented in GURL.  In addition, there's a
>>>> lot of operations you can do with a GURL which don't really make sense in
>>>> the context of a SecurityOrigin.  Passing around a SecurityOrigin object is
>>>> also much more self-documenting.  But, the fact that GURL looks like a
>>>> tempting way to store a SecurityOrigin is actually one of the biggest
>>>> reasons why I think we should make a dedicated type.
>>>>
>>>> If people agree with this, my plan is to create such a type in base and
>>>> modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
>>>>  I'll then convert everything over (or ask people to do the conversion if 
>>>> it
>>>> looks scary).  Finally, I'll remove WebSecurityOrigin::toString().
>>>>
>>>> Does this sound like a good plan?
>>>>
>>>> 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: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc  wrote:

>
>
> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>>>
>>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>>>
>>>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman 
>>>>> wrote:
>>>>>
>>>>>> +1 SecurityOrigin class
>>>>>> Sounds like a reasonable plan.
>>>>>> I suspect there may already be cases where we're actually comparing a
>>>>>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>>>>>> webkit generated security origin, as produced by
>>>>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of 
>>>>>> the
>>>>>> plan to do more than opaquely pass around and test webkit generated
>>>>>> representations.
>>>>>>
>>>>>> Also, I think dumi has a use case to crack it open in order to form
>>>>>> file path elements of the form 'scheme_host_port'
>>>>>>
>>>>>
>>>>> Actually, Dumi's case is slightly different.  He wants to get
>>>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
>>>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>>>
>>>>
>>>> Dumi has such a method in a CL that he is working on at the moment.
>>>>  Also, note: we don't have a way to use FilePath from the WebKit API, and
>>>> I'm not sure that we should.  We use WebString for file paths in the WebKit
>>>> API.
>>>>
>>>
>>> So then he's adding such a method to WebSecurityOrigin that returns a
>>> string?  If so, sounds good.  What's the CL, btw?
>>>
>>
>> Yes:
>> http://codereview.chromium.org/256073/diff/11001/11029
>>
>>
> we decided to use GURLs instead of string16s to represent SecurityOrigins
> on the chromium side, so we don't need a
> (Web)SecurityOrigin::toFilePath()-like method anymore; we can just do
> GURL(SecurityOrigin::toString()), and then create a file path from
> GURL::scheme(), GURL::host() and GURL::port().
>

The point of this thread is that we should not be converting SecurityOrigins
of GURLs.  I believe michaeln was the primary proponent of this and I
believe we convinced him that we shouldn't be doing it.  And I believe most
if not all the reasons why were in my original email.  (Michael, correct me
if I'm wrong.)


> also, i'd argue that no class representing an origin should have a
> toFilePath()-like method: origins and file paths have nothing in common;
> using the origin URL as part of the DB file name is a database-specific
> decision and the code for that conversion should be kept in some
> database-specific class, or a separate origin_to_file_path_util.h file at
> best. (It was very tempting to use SecurityOrigin::databaseIdentifier() only
> because that method was already there.)
>

Well, SecurityOrigin has a method that creates a database file name.  I
don't see why we can't have a "::databasePath" method of our own.  And if we
do, then it does make sense for it to return a FilePath.

That said, I think what Darin suggested in the code review is actually the
cleanest way to do it.  And I think returning a String is not a big deal.

--~--~-~--~~~---~--~~
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: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher  wrote:
>
>> On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher wrote:
>>>
>>>> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow wrote:
>>>>
>>>>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman 
>>>>> wrote:
>>>>>
>>>>>> +1 SecurityOrigin class
>>>>>> Sounds like a reasonable plan.
>>>>>> I suspect there may already be cases where we're actually comparing a
>>>>>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>>>>>> webkit generated security origin, as produced by
>>>>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of 
>>>>>> the
>>>>>> plan to do more than opaquely pass around and test webkit generated
>>>>>> representations.
>>>>>>
>>>>>> Also, I think dumi has a use case to crack it open in order to form
>>>>>> file path elements of the form 'scheme_host_port'
>>>>>>
>>>>>
>>>>> Actually, Dumi's case is slightly different.  He wants to get
>>>>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
>>>>> have a databaseIdentifier() method that outputs a FilePath object?
>>>>>
>>>>
>>>> Dumi has such a method in a CL that he is working on at the moment.
>>>>  Also, note: we don't have a way to use FilePath from the WebKit API, and
>>>> I'm not sure that we should.  We use WebString for file paths in the WebKit
>>>> API.
>>>>
>>>
>>> So then he's adding such a method to WebSecurityOrigin that returns a
>>> string?  If so, sounds good.  What's the CL, btw?
>>>
>>
>> Yes:
>> http://codereview.chromium.org/256073/diff/11001/11029
>>
>>
>>
>>>
>>>
>>>>  ... and why not use strings?
>>>>>> * does the string contain a trailing slash, or not?
>>>>>> * in the default port case, does the string contain the default port
>>>>>> number or not?
>>>>>>
>>>>>
>>>>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult
>>>>> for a base::SecurityOrigin to be constructed any way besides it coming 
>>>>> from
>>>>> WebKit::WebSecurityOrigin (which only comes from
>>>>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>>>>> if/when we need to.
>>>>>
>>>>>
>>>>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:
>>>>>>
>>>>>>> Right now, we don't have a good story for what to do with
>>>>>>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin 
>>>>>>> in
>>>>>>> WebKit, but if you want to move the data between processes, you need to
>>>>>>> convert it to a string and then send that.  In some cases we then 
>>>>>>> convert
>>>>>>> the string to a GURL, but this seems like the wrong thing to do (more on
>>>>>>> this in a sec).
>>>>>>> To me, the right answer is to create a type in base called
>>>>>>> SecurityOrigin that wraps a string and does equality checks.  The 
>>>>>>> equality
>>>>>>> checks can be done as string comparisons since the
>>>>>>> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in the
>>>>>>> future, we need to do anything more with SecurityOrigins (besides
>>>>>>> transporting them, testing equality, and using them in sets/maps) then 
>>>>>>> we
>>>>>>> can make the class more complex.
>>>>>>>
>>>>>>> Why not use GURL?  For one, the SecurityOrigin has a "null" state
>>>>>>> which is significant and which isn't represented in GURL.  In addition,
>>>>>>> there's a lot of operations you can do with a GURL which don't really 
>>>>>>> make
>>>>>>> sense in the context of a SecurityOrigin.  Passing around a 
>>>>>>> SecurityOrigin
>

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth  wrote:

> On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman 
> wrote:
> > As mentioned f2f, this falls apart as soon as Chrome tries to manufacture
> a
> > security origin. I'm not sure, may already have instances of that in the
> > code base for all I know.
>
> I'm not sure Chrome is smart enough to manufacture a SecurityOrigin.
> There's a lot of tricky work in the canonicalization that we don't
> want to duplicate.
>

I agree.  I think the solution is to (if/when we actually need this!) add a
hook to the WebKit API to ask WebCore to manufacture one for us.

--~--~-~--~~~---~--~~
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: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:
>>
>>> +1 SecurityOrigin class
>>> Sounds like a reasonable plan.
>>> I suspect there may already be cases where we're actually comparing a
>>> chrome generated security origin, as produced by GURL.GetOrigin(), with a
>>> webkit generated security origin, as produced by
>>> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
>>> plan to do more than opaquely pass around and test webkit generated
>>> representations.
>>>
>>> Also, I think dumi has a use case to crack it open in order to form file
>>> path elements of the form 'scheme_host_port'
>>>
>>
>> Actually, Dumi's case is slightly different.  He wants to get
>> SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
>> have a databaseIdentifier() method that outputs a FilePath object?
>>
>
> Dumi has such a method in a CL that he is working on at the moment.  Also,
> note: we don't have a way to use FilePath from the WebKit API, and I'm not
> sure that we should.  We use WebString for file paths in the WebKit API.
>

So then he's adding such a method to WebSecurityOrigin that returns a
string?  If so, sounds good.  What's the CL, btw?


>  ... and why not use strings?
>>> * does the string contain a trailing slash, or not?
>>> * in the default port case, does the string contain the default port
>>> number or not?
>>>
>>
>> WebCore::SecurityOrigin handles these for us.  I'll make it difficult for
>> a base::SecurityOrigin to be constructed any way besides it coming from
>> WebKit::WebSecurityOrigin (which only comes from
>> WebCore::WebSecurityOrigin).  We can then deal with these details only
>> if/when we need to.
>>
>>
>> On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow wrote:
>>>
>>>> Right now, we don't have a good story for what to do with
>>>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
>>>> WebKit, but if you want to move the data between processes, you need to
>>>> convert it to a string and then send that.  In some cases we then convert
>>>> the string to a GURL, but this seems like the wrong thing to do (more on
>>>> this in a sec).
>>>> To me, the right answer is to create a type in base called
>>>> SecurityOrigin that wraps a string and does equality checks.  The equality
>>>> checks can be done as string comparisons since the
>>>> WebCore::SecurityOrigin::toString() method canonicalizes it.  If, in the
>>>> future, we need to do anything more with SecurityOrigins (besides
>>>> transporting them, testing equality, and using them in sets/maps) then we
>>>> can make the class more complex.
>>>>
>>>> Why not use GURL?  For one, the SecurityOrigin has a "null" state which
>>>> is significant and which isn't represented in GURL.  In addition, there's a
>>>> lot of operations you can do with a GURL which don't really make sense in
>>>> the context of a SecurityOrigin.  Passing around a SecurityOrigin object is
>>>> also much more self-documenting.  But, the fact that GURL looks like a
>>>> tempting way to store a SecurityOrigin is actually one of the biggest
>>>> reasons why I think we should make a dedicated type.
>>>>
>>>> If people agree with this, my plan is to create such a type in base and
>>>> modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
>>>>  I'll then convert everything over (or ask people to do the conversion if 
>>>> it
>>>> looks scary).  Finally, I'll remove WebSecurityOrigin::toString().
>>>>
>>>
>
> As I mentioned in person, I'm not happy having WebKit API depend on base
> for too many things.  I would prefer to not introduce this dependency since
> it is a circular dependency (in the way the respective repositories relate).
>  Circular dependencies are evil.  We have them for string16 and
> NullableString16.  Let's not add more.
>

If we have one circular dependency on base, why not add more?  Anyhow,
they're already #if'ed.  So if someone wanted to use the API without base,
they easily could change that #else to a #elif, right?  Maybe we should just
do that now?

I agree the circular dependencies are

[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman wrote:

> +1 SecurityOrigin class
> Sounds like a reasonable plan.
> I suspect there may already be cases where we're actually comparing a
> chrome generated security origin, as produced by GURL.GetOrigin(), with a
> webkit generated security origin, as produced by
> WebSecurityOrigin.toString(). So we may want to accelerate the part of the
> plan to do more than opaquely pass around and test webkit generated
> representations.
>
> Also, I think dumi has a use case to crack it open in order to form file
> path elements of the form 'scheme_host_port'
>

Actually, Dumi's case is slightly different.  He wants to get
SecurityOrigin::databaseIdentifier, right?  Maybe WebSecurityOrigin should
have a databaseIdentifier() method that outputs a FilePath object?

... and why not use strings?
> * does the string contain a trailing slash, or not?
> * in the default port case, does the string contain the default port number
> or not?
>

WebCore::SecurityOrigin handles these for us.  I'll make it difficult for a
base::SecurityOrigin to be constructed any way besides it coming from
WebKit::WebSecurityOrigin (which only comes from
WebCore::WebSecurityOrigin).  We can then deal with these details only
if/when we need to.


On Wed, Oct 14, 2009 at 1:36 PM, Jeremy Orlow  wrote:
>
>> Right now, we don't have a good story for what to do with
>> WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
>> WebKit, but if you want to move the data between processes, you need to
>> convert it to a string and then send that.  In some cases we then convert
>> the string to a GURL, but this seems like the wrong thing to do (more on
>> this in a sec).
>> To me, the right answer is to create a type in base called SecurityOrigin
>> that wraps a string and does equality checks.  The equality checks can be
>> done as string comparisons since the WebCore::SecurityOrigin::toString()
>> method canonicalizes it.  If, in the future, we need to do anything more
>> with SecurityOrigins (besides transporting them, testing equality, and using
>> them in sets/maps) then we can make the class more complex.
>>
>> Why not use GURL?  For one, the SecurityOrigin has a "null" state which is
>> significant and which isn't represented in GURL.  In addition, there's a lot
>> of operations you can do with a GURL which don't really make sense in the
>> context of a SecurityOrigin.  Passing around a SecurityOrigin object is also
>> much more self-documenting.  But, the fact that GURL looks like a tempting
>> way to store a SecurityOrigin is actually one of the biggest reasons why I
>> think we should make a dedicated type.
>>
>> If people agree with this, my plan is to create such a type in base and
>> modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
>>  I'll then convert everything over (or ask people to do the conversion if it
>> looks scary).  Finally, I'll remove WebSecurityOrigin::toString().
>>
>> Does this sound like a good plan?
>>
>> 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] Is it time to create a SecurityOrigin class in Chromium?

[Jeremy Orlow]

Right now, we don't have a good story for what to do with
WebCore::SecurityOrigins in Chromium.  We now have a WebSecurityOrigin in
WebKit, but if you want to move the data between processes, you need to
convert it to a string and then send that.  In some cases we then convert
the string to a GURL, but this seems like the wrong thing to do (more on
this in a sec).
To me, the right answer is to create a type in base called SecurityOrigin
that wraps a string and does equality checks.  The equality checks can be
done as string comparisons since the WebCore::SecurityOrigin::toString()
method canonicalizes it.  If, in the future, we need to do anything more
with SecurityOrigins (besides transporting them, testing equality, and using
them in sets/maps) then we can make the class more complex.

Why not use GURL?  For one, the SecurityOrigin has a "null" state which is
significant and which isn't represented in GURL.  In addition, there's a lot
of operations you can do with a GURL which don't really make sense in the
context of a SecurityOrigin.  Passing around a SecurityOrigin object is also
much more self-documenting.  But, the fact that GURL looks like a tempting
way to store a SecurityOrigin is actually one of the biggest reasons why I
think we should make a dedicated type.

If people agree with this, my plan is to create such a type in base and
modify WebKit::WebSecurityOrigin to do conversions to base::SecurityOrigin.
 I'll then convert everything over (or ask people to do the conversion if it
looks scary).  Finally, I'll remove WebSecurityOrigin::toString().

Does this sound like a good plan?

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: [LTTF][WebKit Gardening]: Keeping up with the weeds.

[Jeremy Orlow]

On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov wrote:

>
> I think we need to change something. I am not sure what -- I have
> ideas, but -- I would appreciate some collective thinking on this.
>
> PROBLEM: We accumulate more test failures via WebKit rolls than we fix
> with our LTTF effort. This ain't right.
>
> ANALYSIS:
>
> Ok, WebKit gardening is hard. So is fixing layout tests. You can't
> call it a successful WebKit roll if it breaks layout tests. But we
> don't revert WebKit rolls. It's a forward-only thing. And we want to
> roll quickly, so that we can react to next "big breaker" faster. So
> we're stuck with roll-now/clean-up-after deal. This sucks, because the
> "clean-up-after" is rarely fully completed. Which brings failing
> layout tests, which brings the suffering and spells asymptotic doom to
> the LTTF effort.
>
> POSSIBLE SOLUTIONS:
>
> * Extend WebKit gardener's duties to 4 days. First two days you roll.
> Next two days you fix layout tests. Not file bugs -- actually fix
> them. The net result of 4 days should be 0 (or less!) new layout test
> failures. This solution kind of expects the gardener to be part of
> LTTF, which is not always the case. So it may not seem totally fair.
>

Putting everything you're doing on hold for 2 days while gardening is hard
enough.  4 days is just not feasible most of the time.  I like the idea that
more of us try to understand and fix more code, but there are some times
when it just doesn't make sense for the gardener to fix stuff.

Also, if a team of people can't seem to keep up, then how is 1 person going
to keep up???  Unless the reason we can't keep up is that our priorities are
not straight.  In which case, that's what we should be fixing.


> * Assign LTTF folks specifically for test clean-up every day. The idea
> here is to slant LTTF effort aggressively toward fixing newer
> failures. This seems nice for the gardeners, but appears to separate
> the action/responsibility dependency: no matter what you roll, the
> LTTF elves will fix it.
>

I think it's best to keep LTTF just looking at the problems that have
plagued us for a long time.

What about having 2 people on the gardener rotation looking at layout test
failures each day.  In other words, the gardeners will create the bugs and
pass them to a dedicated triaging and fixing team.  The team will only
assign a bug to someone else only if it's beyond their ability to figure
out.  And, when they do so, it'll be a P1 or P0.


>
> * [ your idea goes here ]
>
> TIMELINE:
>
> I would like for us to agree on a solution and make the necessary
> changes to the process today. Tomorrow is a new day, full of
> surprising changes upstream.
>

Being aggressive and fixing problems is good, but I don't see why this is an
emergency.  Maybe targeting end of week is a better, more realistic goal.

--~--~-~--~~~---~--~~
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: Please confirm the bug (some bitmaps aren/t displayed)

[Jeremy Orlow]

I think the bigger issue is how/when Area-Misc bugs get triaged.  Do they
ever?  If not, we should probably change that.

On Mon, Oct 12, 2009 at 11:50 AM, Guria  wrote:

>
> Please confirm the bug
> http://code.google.com/p/chromium/issues/detail?id=12900
> It really annoys me.
> I expect that someone will fix it soon. I can provide more examples if
> needed.
> >
>

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

[chromium-dev] Re: Buildbot upgrade

[Jeremy Orlow]

Is there documentation anywhere for all the parameters you can feed into the
buildbot webpage?  If not, a cheat sheet would be really helpful.

On Sat, Oct 10, 2009 at 6:25 PM, Nicolas Sylvain wrote:

> Hello,
> Today I upgraded buildbot to the latest version.
>
> If you have a bookmark for the "failures only" waterfall, you will need to
> change it. Previously it
> was "failures=1" and it is now "show_events=true&failures_only=true"
>
> Other than that, nothing should have changed. If you see any issues with
> the new version, please
> let me know!
>
> Thank you,
>
> 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: Friendly reminder: don't let changes rot

[Jeremy Orlow]

Part of this has to do with your level of experience and how big the review
is.  Doing code reviews for people not yet up to speed is _painful_.  And
large reviews also can be.  I think part of the reason things seem better to
you is a reflection on your level of experience.

That said, some of us (me included!) should try to be better, even in these
cases.

On Oct 8, 2009 1:46 PM, "Mohamed Mansour"  wrote:

Actually, Chromium has improved big time on the review rate. When I first
started, some reviews usually stay unreviewed for more than a week, even
repinging didn't work correctly :) But for the last couple of months, when I
ask for a review, within the same hour I get a response, which is excellent.
I don't even mind if its a day, but if its more than a day, it becomes
unpleasant.
It depends on the people you send the review ;x Its hard for "external"
contributors to know who is on vacation while sending a review, so if they
don't send a reply within a day, I assume they are on vacation, then I ask
another person on irc for a review.

I believe its getting better, better than when the project stated. There are
still some people that once you give them a review, they forget about it and
you look at their list of reviews, and they are too many. Some people tend
to be busy with their important stuff, which is understandable, but 1 day
over turn rate should be the maximum.

 -Mohamed

On Thu, Oct 8, 2009 at 2:00 PM, Mike Pinkerton 
wrote: > > > On Thu, Oct ...

--~--~-~--~~~---~--~~ Chromium Developers
mailing list: chromium-de...

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

[chromium-dev] Re: detecting tabs using a lot of CPU?

[Jeremy Orlow]

Pawel, I was responding to the idea of suspending a tab.  I agree that
exposing this information to extensions wouldn't be too hard and could be
quite useful.

On Wed, Oct 7, 2009 at 12:37 PM, Charles Reis  wrote:

>
>
> On Wed, Oct 7, 2009 at 12:25 PM, Jeremy Orlow  wrote:
>
>> On Wed, Oct 7, 2009 at 11:45 AM, Charles Reis  wrote:
>>
>>>
>>>
>>> On Wed, Oct 7, 2009 at 11:13 AM, Andrew Scherkus 
>>> wrote:
>>>
>>>> It'd be nice to have a non-distracting visual indicator, but to play the
>>>> devil's advocate...
>>>> What about intentionally CPU intensive sites that use , ,
>>>> WebGL?
>>>>
>>>> What about scenarios where it's a plugin that's gone haywire?
>>>>
>>>> Could this be accomplished by an extension that displays a little CPU
>>>> graph?
>>>>
>>>
>>> I would love to see this as an extension-- just like the graph that
>>> Procexp.exe or the Windows Task Manager puts in the tray, only per tab in
>>> the location bar (getting its data from the Chrome Task Manager).  Is that
>>> information available to extensions?
>>>
>>> On a grander scale, it would be great to also have a button to "suspend"
>>> a renderer process if I'm not using it at the moment.  I'm sure there's a
>>> ton of complicated issues there, though-- it might suspend several seemingly
>>> unrelated tabs, the page(s) may have network requests in progress, Flash or
>>> a plugin could be to blame, etc, etc.
>>>
>>
>> I could't imagine many users understanding a feature like this much less
>> finding it particularly useful.
>>
>> What are the use cases?
>>
>
> Only power users, which is why I think such a button only belongs in an
> extension.  (Sorry if that part wasn't clear.)
>
> Basically, I tend to have lots of tabs open, but I'm only using a small set
> at any time.  That means I often find myself annoyed that Gmail or other
> CPU-heavy tabs are chewing up resources (or are making Hulu videos choppy)
> while I'm not using them.  I end up having to kill the CPU-heavy tabs, but
> then I lose my context, as well as the visual reminder to get back to it
> later.  This button would let the user "pause" CPU-heavy tabs without losing
> that context.
>
> This is mainly a problem on my laptop, where battery life is also
> important.
>

That makes sense, but I suspect the cost would be fairly significant (even
if it's just an extension API) compared to the benefit users would get.

One random, related idea: if a page is in the background, maybe we should be
rate limiting their timers?


>
> Charlie
>
>
>>
>>
>>>
>>> Charlie
>>>
>>>
>>>
>>>
>>>>
>>>> On Wed, Oct 7, 2009 at 10:35 AM, Evan Martin  wrote:
>>>>
>>>>>
>>>>> We had also discussed putting icons indicating audio into tabs.  That
>>>>> sounds crowded with icons, though: imaginably a game could have
>>>>> facicon, Unicode symbols, CPU load, audio, and the "x" displayed.  I
>>>>> worry there just aren't enough pixels to display all the relevant
>>>>> information.
>>>>>
>>>>> On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy 
>>>>> wrote:
>>>>> >
>>>>> > Something like yes! Maybe not a dialog, as I use things that peg my
>>>>> > CPU (games) somewhat frequently.
>>>>> >
>>>>> > One idea we toyed with was marking such tabs as 'on fire' (icon or
>>>>> > color), so at least there was a visual indication. I think this would
>>>>> > be a good starting point before anything more obtrusive like a dialog
>>>>> > or bar.
>>>>> >
>>>>> >
>>>>> > On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr.
>>>>> >  wrote:
>>>>> >> Just a while before one of my tabs (GMail) started using a lot of
>>>>> CPU time
>>>>> >> (67% while I was compiling in the background). The browser and the
>>>>> system
>>>>> >> were responsive at all times, but processing power was wasted.
>>>>> >> We have a warning dialog for hanged renderers offering to kill them.
>>>>> What do
>>>>> >> you think about a warning dialog for renderers consistently using a
>>>>> lot of
>>>>> >> CPU?
>>>>> >> >
>>>>> >>
>>>>> >
>>>>> > >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
> >
>

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