[chromium-dev] Re: buildbot failure in Chromium on Chromium Builder (dbg), revision 36644
on it. Sorry. On Wed, Jan 20, 2010 at 10:52 AM, build...@chromium.org 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 15729http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/shell_1/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/shell_2/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/gclient/logs/stdio compile failed stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/compile/logs/stdio Changed by: *jor...@chromium.org* Changed at: *Wed 20 Jan 2010 10:50:07* Branch: *src* Revision: *36644*http://src.chromium.org/viewvc/chrome?view=revrevision=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
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 n179...@gmail.com 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
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 rryk...@gmail.com 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] RFC: Extensions Incognito
On Wed, Jan 13, 2010 at 3:48 PM, Antony Sargent asarg...@google.com 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 mpcompl...@chromium.orgwrote: On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth aba...@chromium.org 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, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG 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 Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations. [image: Google Docs logo] http://docs.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 -- 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
On Wed, Jan 13, 2010 at 3:55 PM, Chase Phillips ch...@chromium.org wrote: On Wed, Jan 13, 2010 at 14:50, Chase Phillips ch...@chromium.org 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] WebKit Gardeners 3 rebaseline.py -w
Same here. On Fri, Jan 8, 2010 at 4:51 PM, Drew Wilson atwil...@chromium.org 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 dglaz...@chromium.orgwrote: 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] Replicated State among tabs in Chromium
On Thu, Jan 7, 2010 at 1:10 PM, Charlie Reis cr...@chromium.org wrote: On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie b...@google.com wrote: On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel fadysam...@gmail.com 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 cr...@chromium.orgwrote: 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 pkast...@google.comwrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.comwrote: 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 WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA
Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to
(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 pkast...@google.com 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
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 cr...@chromium.org 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 fadysam...@gmail.com 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
On Thu, Jan 7, 2010 at 1:38 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org 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] Don't use Empty[String,WString,String16,GURL]() unless you really need to
What about renaming the function? EmptyStringHACK() or something? On Thu, Jan 7, 2010 at 1:49 PM, Peter Kasting pkast...@google.com wrote: On Thu, Jan 7, 2010 at 1:43 PM, Jeremy Orlow jor...@chromium.org 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] [WebGL] Recommending --no-sandbox
On Wed, Dec 30, 2009 at 3:43 PM, Peter Kasting pkast...@google.com wrote: On Wed, Dec 30, 2009 at 3:22 PM, Jeremy Orlow jor...@google.com 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
On Wed, Dec 30, 2009 at 4:15 PM, Nico Weber tha...@chromium.org 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 jor...@google.com wrote: On Wed, Dec 30, 2009 at 3:43 PM, Peter Kasting pkast...@google.com wrote: On Wed, Dec 30, 2009 at 3:22 PM, Jeremy Orlow jor...@google.com 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] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell k...@chromium.org wrote: (Resending from chromium.org) On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org 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] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 8:06 AM, Darin Fisher da...@chromium.org 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] Extensions and the Mac
Or reject extensions that could be written without a NPAPI component. *ducks* On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.com wrote: On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com 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] Extensions and the Mac
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 jabdelma...@google.comwrote: NaCl is the answer to all these problems... On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow jor...@google.com wrote: Or reject extensions that could be written without a NPAPI component. *ducks* On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.comwrote: On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com 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] [WebGL] Recommending --no-sandbox
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org 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 jor...@google.com 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] [WebGL] Recommending --no-sandbox
On Thu, Dec 10, 2009 at 9:29 PM, Jeremy Orlow jor...@google.com wrote: On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org 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 jor...@google.com 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
[chromium-dev] Re: Chromium Tech Talks
On Tue, Dec 8, 2009 at 11:25 AM, Jeremy Orlow jor...@chromium.org 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
Re: [chromium-dev] Re: Chromium Tech Talks
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 jacques.ag...@googlemail.comwrote: On Dec 8, 10:49 pm, Paweł Hajdan Jr. phajdan...@chromium.org 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
Re: [chromium-dev] Reflecting SSL state in a world with SharedWorkers and cross-window sharing/x-domain messaging
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 aba...@chromium.org 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 atwil...@chromium.org 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
[chromium-dev] Chromium Tech Talks
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
[chromium-dev] Re: Chromium Tech Talks
On Tue, Dec 8, 2009 at 11:25 AM, Jeremy Orlow jor...@chromium.org 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
Re: [chromium-dev] Need a linux-views build buddy.
Isn't gcl try cl -b linux_view what you want? On Thu, Dec 3, 2009 at 1:46 PM, Mike Pinkerton pinker...@chromium.orgwrote: 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] Beginning with development
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 robj.pe...@gmail.com 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 jor...@chromium.orgwrote: On Tue, Nov 10, 2009 at 2:31 PM, Roberto Perez robj.pe...@gmail.comwrote: 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 mar...@google.comwrote: And you can use distcc. On Tue, Nov 10, 2009 at 1:21 PM, Paweł Hajdan jr phajdan...@gmail.com 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
Re: [chromium-dev] Any interest in command line tools for network stack?
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 cbent...@gmail.com 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] More sheriffs?
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 pkast...@google.com 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] Re: [chromium-extensions] openDatabase() maximum size
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 a...@chromium.org 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 asarg...@google.com 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 hotchpo...@gmail.com 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.comchromium-extensions%2bunsubscr...@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.comchromium-extensions%2bunsubscr...@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] Re: [chromium-extensions] openDatabase() maximum size
On Fri, Nov 13, 2009 at 1:21 PM, Aaron Boodman a...@chromium.org wrote: On Fri, Nov 13, 2009 at 1:07 PM, Jeremy Orlow jor...@chromium.org 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: More sheriffs?
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 pkast...@google.com 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: sheriff's keep the tree *open* WAS: [chromium-dev] More sheriffs?
+1 (for what it's worth) On Fri, Nov 13, 2009 at 2:28 PM, Ojan Vafai o...@google.com wrote: On Fri, Nov 13, 2009 at 1:25 PM, Peter Kasting pkast...@google.comwrote: On Fri, Nov 13, 2009 at 1:15 PM, Finnur Thorarinsson fin...@google.comwrote: 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] More sheriffs?
On Fri, Nov 13, 2009 at 3:38 PM, Peter Kasting pkast...@google.com wrote: On Fri, Nov 13, 2009 at 2:56 PM, Dirk Pranke dpra...@chromium.org 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 nsylv...@google.com 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
[chromium-dev] Re: OWP feature owners: Please update the OWP roadmap.
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 jor...@chromium.org 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
[chromium-dev] OWP feature owners: Please update the OWP roadmap.
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] WebKit Windows try server?
On Thu, Nov 12, 2009 at 1:30 PM, Peter Kasting pkast...@google.com 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
Re: [chromium-dev] WebKit Windows try server?
On Thu, Nov 12, 2009 at 1:46 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 12, 2009 at 1:43 PM, Nicolas Sylvain nsylv...@google.comwrote: On Thu, Nov 12, 2009 at 1:30 PM, Peter Kasting pkast...@google.comwrote: 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?
On Thu, Nov 12, 2009 at 1:50 PM, Adam Barth aba...@chromium.org wrote: On Thu, Nov 12, 2009 at 1:46 PM, Jeremy Orlow jor...@google.com 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?
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 aba...@chromium.org 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 mar...@chromium.org 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 jor...@google.com wrote: On Thu, Nov 12, 2009 at 1:50 PM, Adam Barth aba...@chromium.org wrote: On Thu, Nov 12, 2009 at 1:46 PM, Jeremy Orlow jor...@google.com 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] Re: Tech talk topics
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 jor...@chromium.org 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 scher...@chromium.orgwrote: 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 m...@chromium.orgwrote: +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 s...@chromium.org 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 jor...@chromium.org 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] Re: Tech talk topics
I'll see what I can do... :-) On Wed, Nov 11, 2009 at 12:41 PM, Freddy Rose freddybr...@gmail.com 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 buakaw@gmail.com 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 pkast...@google.com wrote: On Wed, Nov 11, 2009 at 11:20 AM, Jeremy Orlow jor...@chromium.org 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
[chromium-dev] Local Storage directory moved as of rev 31584
*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 31584http://src.chromium.org/viewvc/chrome?view=revrevision=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
Re: [chromium-dev] Beginning with development
On Tue, Nov 10, 2009 at 2:31 PM, Roberto Perez robj.pe...@gmail.com 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 mar...@google.comwrote: And you can use distcc. On Tue, Nov 10, 2009 at 1:21 PM, Paweł Hajdan jr phajdan...@gmail.com 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: 437k files checked out for an official build
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 lafo...@google.com 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: Large commit - update your .gclient files to avoid
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 aba...@chromium.org wrote: Can we note this on dev.chromium.org somewhere? Adam On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.org 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] Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: 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
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 sh...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org 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] Re: Changes to using threads in the browser process
On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.org 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::RefCountedThreadSafeFoo, 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 cases if the target thread exists or not, and to make Valgrind
[chromium-dev] Tech talk topics
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
On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.orgwrote: 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::RefCountedThreadSafeFoo, 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? I'm not sure which object that you're referring to? The PostTaskHelper will delete the task. But if you have a DeleteSoon task, deleting the task (i.e. because the target thread is gone) doesn't delete the object. So this means the memory will just be leaked? That won't work for DOM Storage since the backing database is shut down in destructors. As for simultaneously deleting an object, if more than 1 thread are accessing an object, they should each have a reference to it. They can't ensure that releasing their reference will cause deletion, since there could be other refences. Sure, but what if the ref count is not thread safe? Or they access an object that's not thread safe. I often do this because I only touch those members on specific threads, but if I can't guarantee that only one thread could be deleting
[chromium-dev] Re: Tech talk topics
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 s...@chromium.org 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 jor...@chromium.org 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
On Thu, Nov 5, 2009 at 2:01 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:42 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow jor...@chromium.orgwrote: On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.orgwrote: 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::RefCountedThreadSafeFoo, 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? I'm not sure which object that you're referring to? The PostTaskHelper will delete the task. But if you have a DeleteSoon task, deleting the task (i.e. because the target thread is gone) doesn't delete the object. So this means the memory will just be leaked? That won't work for DOM Storage since the backing database is shut down in destructors. If the object doesn't need to be closed on a specific thread, and you want to ensure that it's deleted on any thread, then ReleaseSoon and ChromeThread::DeleteOnIOThread aren't going to serve your need. You'll probably want to have either a singleton or an object like ResourceDispatcherHost that BrowserProcess
[chromium-dev] The future for test shell (WAS: test_shell performance is bad compared to Chromium)
On Thu, Nov 5, 2009 at 2:46 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org 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: Tech talk topics
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 jer...@chromium.orgwrote: 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 s...@chromium.org 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 jor...@chromium.org 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 s...@chromium.org 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 jor...@chromium.org 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)
On Thu, Nov 5, 2009 at 3:01 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 2:46 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org 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
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 scher...@chromium.orgwrote: 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 m...@chromium.org 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 s...@chromium.org 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 jor...@chromium.org 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: Why is Linux Chrome so fast?
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 li...@google.com wrote: scrolling jank in gmail http://crbug.com/25741 Linus On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin e...@chromium.org 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 UI widgets. You can see this if you focus on the bottom of where the bookmark bar is going to be (especially when the bookmark bar is set to show only on the NTP). You'll see an edge there when the bookmark bar is draw by while the main
[chromium-dev] Re: Which editor do you recommend on Mac OS X?
On Tue, Nov 3, 2009 at 10:12 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: On Tue, Nov 3, 2009 at 19:08, Drew Wilson atwil...@chromium.org 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] PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
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!
On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess sh...@chromium.org 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 jor...@chromium.org 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: Fwd: Switching vs2008 to be preferred when present.
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\username\.gyp\include.gypi, or if you are on Vista:
C:\Users\username\.gyp\include.gypi. Make sure you rungclient 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) b...@chromium.orgwrote:
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 mbel...@google.com 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)
b...@chromium.orgwrote:
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: b...@chromium.org
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
On Tue, Oct 27, 2009 at 11:37 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: On Wed, Oct 28, 2009 at 00:44, Ian Fette i...@chromium.org 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
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 j...@chromium.org 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 s...@chromium.org 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 e...@chromium.org 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: [linux] how to work around nacl errors in 64-bit build
I'll follow up with the NaCl team to make sure they are. On Wed, Oct 21, 2009 at 11:57 AM, John Grabowski j...@chromium.org wrote: On Wed, Oct 21, 2009 at 11:37 AM, Jeremy Orlow jor...@chromium.orgwrote: 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] Crashing layout tests
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
On Tue, Oct 20, 2009 at 10:19 AM, David Levin le...@google.com 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 jor...@chromium.org 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
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 dglaz...@chromium.orgwrote: 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 le...@chromium.org 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 jor...@chromium.org wrote: On Tue, Oct 20, 2009 at 10:19 AM, David Levin le...@google.com 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 jor...@chromium.org 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: WebKit API wrapper for Document
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 magreenbl...@gmail.com wrote: On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth aba...@chromium.org 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 magreenbl...@gmail.com 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: LTTF helping the GTTF make cycle times *minutes* faster
On Fri, Oct 16, 2009 at 2:34 PM, Ojan Vafai o...@google.com 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 o...@google.com 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 LayoutTests/plugins/geturl-replace-query.html LayoutTests/plugins/npruntime.html
[chromium-dev] Re: When disabling a test, please assign to whoever wrote it
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 a...@chromium.org 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 j...@chromium.org 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?
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 da...@chromium.org wrote: On Wed, Oct 14, 2009 at 7:17 PM, Jeremy Orlow jor...@chromium.org 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 da...@chromium.org wrote: On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow jor...@chromium.orgwrote: 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
[chromium-dev] Re: Canary bot, now with formatted layout test results
Christmas came early for anyone working on WebKit! Thanks Glen. :-) On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry erik.co...@gmail.com wrote: This makes me very happy! 2009/10/15 Glenn Wilson gwil...@chromium.org: 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?
On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com 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: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 12:17 PM, Michael Nordman micha...@google.comwrote: On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman micha...@google.comwrote: On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com 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] Is it time to create a SecurityOrigin class in Chromium?
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?
On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman micha...@google.comwrote: +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 jor...@chromium.org 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?
On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman micha...@google.comwrote: +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 jor...@chromium.orgwrote: 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 bad, but they're already there. And, honestly, the WebKit API (in its current form) is not useful unless you are including base. Whatsmore, if we output stuff as a string, then we're just hoping someone goes ahead and immediately converts that to a SecurityOrigin. But there's no guarantee they won't. Or that they won't do something incredibly stupid before such a conversion. By forcing things to go straight to a base::SecurityOrigin (and comments in that code explaining why) it'll be much harder for someone to do something dangerous without doing it willfully. Personally, I think we should have more functions for converting to base:: types rather than less. -Darin Does this sound like a good plan? J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http
[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com 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?
On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman micha...@google.comwrote: +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 jor...@chromium.orgwrote: 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? Because they can be a source of great pain. This is a slippery slope. We can basically never change base/string16.h or base/nullable_string16.h. I don't want more of that. Things like ChromiumBridge exist so we can avoid having more of these. If we're making a DLL out of WebKit, then you're right. Every time we changed base, we'd need to take extra care to make sure base is rolled properly. How are we going to provide developers such a DLL, though? If it's checked in, then whenever someone changes base they can check in a new copy of WebKit.dll. And, if we do things some other way, I'm sure we can find other reasonable solutions. 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
[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc d...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman micha...@google.comwrote: +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?
On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:00 PM, Michael Nordman micha...@google.comwrote: +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 jor...@chromium.orgwrote: 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: layout test dashboard goofup
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 pkast...@google.com wrote: On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai o...@google.com 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
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 e...@chromium.org wrote: Sounds like we've got a volunteer! :D :D :D On Wed, Oct 14, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org 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 pkast...@google.com wrote: On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai o...@google.com 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?
On Wed, Oct 14, 2009 at 4:32 PM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:03 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:58 PM, Dumitru Daniliuc d...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.orgwrote: 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 can do it for us. As Adam said, duplicating this kind of code in Chromium is not really useful. Let's let WebCore take care of it for us. 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?
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 da...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.orgwrote: 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 jor...@chromium.orgwrote: 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? Because they can be a source of great pain. This is a slippery slope. We can basically never change base/string16.h or base/nullable_string16.h. I don't want more of that. Things like ChromiumBridge exist so we can avoid having more of these. If we're making a DLL out of WebKit, then you're right. We are (for debug builds). That has always been the plan :-) But this is not the reason. Every time we changed base, we'd need to take extra care to make sure base is rolled properly. What does rolling base mean? base
[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
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 da...@chromium.org wrote: On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow jor...@chromium.org 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 da...@chromium.org 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 da...@chromium.orgwrote: 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 jor...@chromium.orgwrote: 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 da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 3:59 PM, Jeremy Orlow jor...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:48 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:47 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:30 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:23 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:08 PM, Jeremy Orlow jor...@chromium.org 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
[chromium-dev] Re: Please confirm the bug (some bitmaps aren/t displayed)
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 guria...@gmail.com 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
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 nsylv...@chromium.orgwrote: 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=truefailures_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
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 m...@chromium.org 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 pinker...@chromium.org 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?
Pawel, I was responding to the idea of suspending a tab. I agree that exposing this information to extensions wouldn't be too hard and could be quite useful. On Wed, Oct 7, 2009 at 12:37 PM, Charles Reis cr...@chromium.org wrote: On Wed, Oct 7, 2009 at 12:25 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Oct 7, 2009 at 11:45 AM, Charles Reis cr...@chromium.org wrote: On Wed, Oct 7, 2009 at 11:13 AM, Andrew Scherkus scher...@chromium.orgwrote: It'd be nice to have a non-distracting visual indicator, but to play the devil's advocate... What about intentionally CPU intensive sites that use canvas, video, WebGL? What about scenarios where it's a plugin that's gone haywire? Could this be accomplished by an extension that displays a little CPU graph? I would love to see this as an extension-- just like the graph that Procexp.exe or the Windows Task Manager puts in the tray, only per tab in the location bar (getting its data from the Chrome Task Manager). Is that information available to extensions? On a grander scale, it would be great to also have a button to suspend a renderer process if I'm not using it at the moment. I'm sure there's a ton of complicated issues there, though-- it might suspend several seemingly unrelated tabs, the page(s) may have network requests in progress, Flash or a plugin could be to blame, etc, etc. I could't imagine many users understanding a feature like this much less finding it particularly useful. What are the use cases? Only power users, which is why I think such a button only belongs in an extension. (Sorry if that part wasn't clear.) Basically, I tend to have lots of tabs open, but I'm only using a small set at any time. That means I often find myself annoyed that Gmail or other CPU-heavy tabs are chewing up resources (or are making Hulu videos choppy) while I'm not using them. I end up having to kill the CPU-heavy tabs, but then I lose my context, as well as the visual reminder to get back to it later. This button would let the user pause CPU-heavy tabs without losing that context. This is mainly a problem on my laptop, where battery life is also important. That makes sense, but I suspect the cost would be fairly significant (even if it's just an extension API) compared to the benefit users would get. One random, related idea: if a page is in the background, maybe we should be rate limiting their timers? Charlie Charlie On Wed, Oct 7, 2009 at 10:35 AM, Evan Martin e...@chromium.org wrote: We had also discussed putting icons indicating audio into tabs. That sounds crowded with icons, though: imaginably a game could have facicon, Unicode symbols, CPU load, audio, and the x displayed. I worry there just aren't enough pixels to display all the relevant information. On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: networking code in src/third_party/WebKit/WebCore/platform/network/mac
I'm 99% sure we use what's in third_party On Mon, Oct 5, 2009 at 11:06 PM, hap 497 hap...@gmail.com wrote: Hi, Can you please tell me if chromium on Mac OS X uses the networking code in src/third_party/WebKit/WebCore/platform/network/mac? Or the code there is for Webkit? I asked because chromium has this 'sandbox' architecture, so I am not sure if chromium's networking code is totally different (chromium specified) because of this difference in architecture. Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. For what it's worth: This makes sense to me. It seems like pulling SQLite into its own process would be helpful for the reasons you laid out. I wonder if the only reason no one else has chimed in on this thread is that no one wants to have to implement it. :-) But I am unsure how to calculate, for example a random bit flip on the backingstores, which add to at least 10M on most machines does not hurt, or in the middle of a cache entry, or in the data part of some structure. I imagine there's no way we can know when corruption happen in steady-state and the next query leads to some other browser memory (or another database) getting corrupted? On Tue, Oct 6, 2009 at 3:58 PM, Huan Ren hu...@google.com wrote: It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: build time speed improvement with solid state drive?
On Mon, Oct 5, 2009 at 11:14 AM, Amanda Walker ama...@chromium.org wrote: On Mon, Oct 5, 2009 at 2:08 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: I'm putting together a new computer and I'd like to optimize my chromium build times :-) Is anyone currently building chromium using a solid state drive? Have you noticed any compile or link time speed improvements relative to using a second traditional SATA drive? Other people can chime in about windows ssd performance, but I have an SSD in a Mac laptop that I sometimes do builds on. Total build time is only marginally better than a traditional SATA drive (a few percent), but the machine is noticeably less sluggish doing other things during a build (when there's any disk contention happening, the faster seek time and i/o operations per second are a definite win). But for overall build time, I've found that RAM and CPU cores make much more of a difference than the drive. From what I've heard, SVN and searching within a project are faster with a SSD. As for the system getting sluggish during compile: this can also be solved by having a 2nd hard drive that contains all the source + build files. --~--~-~--~~~---~--~~ 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: Drive Chrome Automation from Outside Browser Process
How is this different from ChromeBot? How you control things depends on what level of realism you want. If you're just verifying the sites work correctly, you might just use the code the UI tests use. If you want to actually simulate button clicks and such, then you'll need something more like selenium. If you just care about testing the rendering engine, then you could just hook straight into the WebKit API (note that it's not _quite_ done yet...so you'd need to use Glue some as well). I think maybe you should explore what's there a bit more and/or figure out exactly what you want to test so you can ask more specific questions. J On Mon, Oct 5, 2009 at 7:12 PM, TJ Shah tejass...@chromium.org wrote: Hi, I have recently started working on Chrome Release process automation where I want to automate Visiting various sites (e.g. Top 200 sites) using Chrome and other browsers and look for possible App-compat issues. I am fairly new to this kind of automation in Chrome, so looking for possible ways to automate that. I found some references to using Automation Proxy, Web Driver and Selenium, but not sure on where to get more information on those tools. Can someone throw some light here? Which is better and more supported? Any previous work done in this kind of area? Looking for more longer term cross-plat tool which we can reply on. Remember, I want to drive the chrome automation from outside browser process so test doesn't die when browser crashes. So I think, In-proc browser will be of little help here. Any help will be appreciated !!! Thanks, TJ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I totally agree. I envision it being something much more like RSS feeds. In my mind, it should always advertise itself to the browser and then the browser should decide how to advertise it to the user. Requiring scripts to initiate things seems silly to me. Is this API even part of any standard? Maybe we should bring this up on WhatWG? On Fri, Oct 2, 2009 at 2:43 PM, Ben Goodger (Google) b...@chromium.orgwrote: BTW I think this API (and the associated registerContentHandler) aren't that great... imagine a feed reader that wants to handle feed types and feed protocol links... do they need to call these functions one per protocol scheme and per feed content type (there are several), showing a UI for each? This sort of thing seems better handled through some kind of manifest. -Ben On Thu, Oct 1, 2009 at 8:06 PM, Darin Fisher da...@chromium.org wrote: I've added this to my list for review by the group. -Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. 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: [DESIGN DOC] registerProtocolHandler HTML5 API
That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. 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: XP Perf page load regression on morejs and moz page cyclers
On Thu, Oct 1, 2009 at 12:38 PM, Scott Hess sh...@chromium.org wrote: On Thu, Oct 1, 2009 at 11:32 AM, Mike Belshe mbel...@google.com wrote: On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess sh...@chromium.org wrote: Could we set jemalloc on selected renderer processes? I realize that wouldn't necessarily only impact the target domains, but it might be better than making the change global. It can be set by a per-process environment variable. So... yes, this could be done. Mix-and-match allocators might be a little strange for anything other than debugging/testing. I was thinking enabling for the gmail renderer (and whoever gets stuck in that process) might be more useful than enabling for everyone - but obviously we'd need ways to identify the source of any uploaded data. That said, being able to enable alternate malloc libraries in the browser process might have relatively low performance costs compared to the value of the data generated. I don't mean to imply that browser-process performance is not important, but rather that race conditions and double-frees and the like are much more dangerous there. Also, interpreting the data would probably be easier (renderer data and browser results would be internally consistent). Both of these points seem like big wins to me, for what it's worth. --~--~-~--~~~---~--~~ 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: MSVC2005 vs Win7 PlatformSDK
I saw this on Vista 64 as well. On Wed, Sep 30, 2009 at 10:39 AM, Stephen White senorbla...@chromium.orgwrote: Just in case someone else runs into this: I recently installed MSVC2005 and the Win7 Platform SDK on my win7/64 machine and it gave me this error at link time: shell32.lib(shguid.obj) : fatal error LNK1103: debugging information corrupt; recompile module Installing hotfix 949009 ( https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=18623) fixed it. We currently have that hotfix listed in the build instructions as to be confirmed (it's still in beta). Stephen -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ 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 has a buildbot console view too!
S much better than grid view. :-) On Wed, Sep 30, 2009 at 3:49 PM, Adam Barth aba...@chromium.org wrote: Nice! On Wed, Sep 30, 2009 at 3:47 PM, Eric Seidel esei...@chromium.org wrote: Who knew? Looks like Mark (Rowe) recently updated their buildbot: http://build.webkit.org/console Very hot. There is no link to it anywhere that I can see. -eric --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
