[chromium-dev] LayoutTest unexpected success
Looking at the buildbot, there are a bunch of LayoutTests that are supposed to fail, timeout, or crash, but which actually pass. We should update our test expectations / close the cooresponding bugs. I'll do this tomorrow afternoon if no one beats me to it. Enjoy: Expected to fail, but passed (26): LayoutTests/accessibility/non-native-image-crash.html LayoutTests/fast/dynamic/flash-replacement-test.html LayoutTests/fast/loader/loadInProgress.html LayoutTests/http/tests/security/xssAuditor/base-href-control-char.html LayoutTests/http/tests/security/xssAuditor/base-href-safe3.html LayoutTests/http/tests/security/xssAuditor/base-href-scheme-relative.html LayoutTests/http/tests/security/xssAuditor/base-href.html LayoutTests/http/tests/security/xssAuditor/embed-tag-control-char.html LayoutTests/http/tests/security/xssAuditor/embed-tag.html LayoutTests/http/tests/security/xssAuditor/inline-event-HTML-entities.html LayoutTests/http/tests/security/xssAuditor/javascript-link-HTML-entities-control-char.html LayoutTests/http/tests/security/xssAuditor/javascript-link-HTML-entities-named.html LayoutTests/http/tests/security/xssAuditor/javascript-link-HTML-entities-null-char.html LayoutTests/http/tests/security/xssAuditor/javascript-link-HTML-entities.html LayoutTests/http/tests/security/xssAuditor/javascript-link-control-char.html LayoutTests/http/tests/security/xssAuditor/javascript-link.html LayoutTests/http/tests/security/xssAuditor/link-onclick-entities.html LayoutTests/http/tests/security/xssAuditor/object-embed-tag-control-char.html LayoutTests/http/tests/security/xssAuditor/object-embed-tag.html LayoutTests/http/tests/security/xssAuditor/object-tag.html LayoutTests/http/tests/security/xssAuditor/script-tag-entities.html LayoutTests/http/tests/security/xssAuditor/script-tag-src-redirect-safe.html LayoutTests/http/tests/security/xssAuditor/script-tag-with-source-double-quote.html LayoutTests/http/tests/security/xssAuditor/script-tag-with-source-entities.html LayoutTests/http/tests/security/xssAuditor/script-tag-with-source-no-quote.html LayoutTests/plugins/return-error-from-new-stream-callback-in-full-frame-plugin.html Expected to timeout, but passed (1): LayoutTests/fast/dom/frame-loading-via-document-write.html Expected to crash, but passed (9): LayoutTests/fast/dom/offset-parent-positioned-and-inline.html LayoutTests/fast/events/message-channel-gc-2.html LayoutTests/fast/events/message-channel-gc-4.html LayoutTests/fast/events/message-channel-listener-circular-ownership.html LayoutTests/fast/events/message-port-constructor-for-deleted-document.html LayoutTests/fast/events/message-port-deleted-frame.html LayoutTests/fast/events/mouseover-mouseout2.html LayoutTests/fast/images/favicon-as-image.html LayoutTests/fast/images/pdf-as-background.html --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
Wow, there are even more on Mac: Expected to fail, but passed (39) Adam On Tue, Jul 14, 2009 at 12:38 AM, Adam Barthaba...@chromium.org wrote: Looking at the buildbot, there are a bunch of LayoutTests that are supposed to fail, timeout, or crash, but which actually pass. We should update our test expectations / close the cooresponding bugs. I'll do this tomorrow afternoon if no one beats me to it. Enjoy: Expected to fail, but passed (26): LayoutTests/accessibility/non-native-image-crash.html LayoutTests/fast/dynamic/flash-replacement-test.html LayoutTests/fast/loader/loadInProgress.html LayoutTests/http/tests/security/xssAuditor/base-href-control-char.html LayoutTests/http/tests/security/xssAuditor/base-href-safe3.html LayoutTests/http/tests/security/xssAuditor/base-href-scheme-relative.html LayoutTests/http/tests/security/xssAuditor/base-href.html LayoutTests/http/tests/security/xssAuditor/embed-tag-control-char.html LayoutTests/http/tests/security/xssAuditor/embed-tag.html LayoutTests/http/tests/security/xssAuditor/inline-event-HTML-entities.html LayoutTests/http/tests/security/xssAuditor/javascript-link-HTML-entities-control-char.html LayoutTests/http/tests/security/xssAuditor/javascript-link-HTML-entities-named.html LayoutTests/http/tests/security/xssAuditor/javascript-link-HTML-entities-null-char.html LayoutTests/http/tests/security/xssAuditor/javascript-link-HTML-entities.html LayoutTests/http/tests/security/xssAuditor/javascript-link-control-char.html LayoutTests/http/tests/security/xssAuditor/javascript-link.html LayoutTests/http/tests/security/xssAuditor/link-onclick-entities.html LayoutTests/http/tests/security/xssAuditor/object-embed-tag-control-char.html LayoutTests/http/tests/security/xssAuditor/object-embed-tag.html LayoutTests/http/tests/security/xssAuditor/object-tag.html LayoutTests/http/tests/security/xssAuditor/script-tag-entities.html LayoutTests/http/tests/security/xssAuditor/script-tag-src-redirect-safe.html LayoutTests/http/tests/security/xssAuditor/script-tag-with-source-double-quote.html LayoutTests/http/tests/security/xssAuditor/script-tag-with-source-entities.html LayoutTests/http/tests/security/xssAuditor/script-tag-with-source-no-quote.html LayoutTests/plugins/return-error-from-new-stream-callback-in-full-frame-plugin.html Expected to timeout, but passed (1): LayoutTests/fast/dom/frame-loading-via-document-write.html Expected to crash, but passed (9): LayoutTests/fast/dom/offset-parent-positioned-and-inline.html LayoutTests/fast/events/message-channel-gc-2.html LayoutTests/fast/events/message-channel-gc-4.html LayoutTests/fast/events/message-channel-listener-circular-ownership.html LayoutTests/fast/events/message-port-constructor-for-deleted-document.html LayoutTests/fast/events/message-port-deleted-frame.html LayoutTests/fast/events/mouseover-mouseout2.html LayoutTests/fast/images/favicon-as-image.html LayoutTests/fast/images/pdf-as-background.html --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] FYI canvas is hosed
https://bugs.webkit.org/show_bug.cgi?id=27187 -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
On Tue, Jul 14, 2009 at 3:40 AM, Adam Barthaba...@chromium.org wrote: Wow, there are even more on Mac: Expected to fail, but passed (39) If some of those are plugin related, it's because I didn't remember last night that the --enable-plugins flag I checked in didn't affect test shell, so many plugin tests should have suddenly started passing. I'll go take a look at those. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
On Tue, Jul 14, 2009 at 3:38 AM, Adam Barthaba...@chromium.org wrote: Expected to crash, but passed (9): LayoutTests/fast/dom/offset-parent-positioned-and-inline.html LayoutTests/fast/events/message-channel-gc-2.html LayoutTests/fast/events/message-channel-gc-4.html LayoutTests/fast/events/message-channel-listener-circular-ownership.html LayoutTests/fast/events/message-port-constructor-for-deleted-document.html LayoutTests/fast/events/message-port-deleted-frame.html LayoutTests/fast/events/mouseover-mouseout2.html LayoutTests/fast/images/favicon-as-image.html LayoutTests/fast/images/pdf-as-background.html These started failing late yesterday afternoon--I'd double check to make sure they're actually happy again before re-enabling them. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 01:52, Evan Martine...@chromium.org wrote: I've used it to browse on real hardware; the Beagleboard, an OMAP3 based ARM board with 128MB of RAM. Wow, impressive. How much do you think multi-process hurts us? The full story is 128MB of RAM + 128MB of swap on a slow (class 4) SD card. Multi-process changes the game, at least wrt memory. Normally once you hit the memory ceiling the system is unresponsive until the OOM killer takes out something (on the OLPC XO this would often be X, losing the entire session). With Chrome, opening a 3rd tab results in the new renderer instantly crashing (if it's even starting?), leaving you restricted to two tabs but free to continue browsing in those two. So IMO, multi-process makes us fail in much nicer ways :) But we will hit that memory ceiling sooner due to the overheads of being multi-process. The ~500Mhz CPU is pegged when rendering, but the system goes near-idle once drawing has finished. Scrolling takes it back up to 100%. I haven't used it much, but will do more often going forward now that I can build using the tree. On the topic of the ARM build, it would be great if we could have a buildbot doing cross compiles. I filed a bug at http://crbug.com/16321, is there anything else I can do to follow that up? One piece to look at is the code that calls SetProcessBackgrounded(), which on Windows marks the process as one that can be paged out but on Linux is not implemented. I don't know how it decides it's ok to do that, but it'd be good logic to examine. I'll take a look. My email was kicked off after discovering the SystemMonitor class, which I understand is only used for switching on and off high-res timers on Windows. These both sound like good switches for enabling efficient behaviour. I think it'd be pretty interesting to fully suspend background tabs, but doing it safely is likely tricky. For example, imagine a page that has Javascript that is driving a Flash plugin playing background music. I wonder if it would be possible to detect that sound is coming from a tab. Perhaps it's not worth it, as the case of IM in the background tab will be really hard to detect in a generic fashion. The only reliable way the browser will discover that a tab is inactive is for the user to tell it. Right click - Pause this tab? This would be a UI win over my current `pgrep firefox | xargs kill -STOP` :) Other things to look at would be timers that fire 'too often', and pausing animated content such as gifs and flash. Even for stuff like gifs that don't have audio, you could imagine a page with a very long animated gif, where I might switch away from the tab and expect it to be farther along when I come back. Here's an idea: when a page is in the background don't let it repaint. That means when you switch to it you'll have to wait for it to repaint, but maybe that's an ok tradeoff. (Maybe we do this already.) So we do this for GIFs. Can anyone tell me if background tabs re-paint themselves? If not, I'll add it to the TODO. A final idea is simply looking at performance overall. We haven't yet looked at even a profile and we very well could be doing a lot of unnecessary work. For example, I believe the renderer spams the browser repeatedly with set tooltip messages as you move the mouse around. I think I saw a bug filed suggesting we could have the renderer only send the message if the tooltip changed. Maybe that's not enough work to waste much battery, though. This is more generic, but perhaps more realistic. This would be best discovered by looking at IPC traffic going past? Thanks for the reply, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 03:09, Craig Schlentercraig.schlen...@gmail.com wrote: I've mentioned this to Joel off-list but in case anyone else is interested, I have code that runs background tabs at lower scheduling priorities on linux. Thanks. Are you able to post the newer version you mentioned? Tweaks to /etc/security/limits.conf are necessary to make it work though (to grant priority raising abilities). If we're just tweaking the priority level between 0 and 20 a normal user will have no worries. It's only when we try to take it below 0 that more capabilities are needed. $ renice +1 31404 31404: old priority 0, new priority 1 $ renice -1 31404 renice: 31404: setpriority: Permission denied $ renice +3 31404 31404: old priority 1, new priority 3 $ renice +1 31404 31404: old priority 3, new priority 1 OTOH, renicing isn't really going to help my quest to end unnecessary background work, it's just going to make sure the foreground gets more CPU share. Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
Lets wait a bit before re-enabling tests, but they seem to act happy, unlike last night. If no one re-enables them, I can do it when I get home around 6 EST. -- Mohamed Mansour On Tue, Jul 14, 2009 at 8:24 AM, Amanda Walker ama...@chromium.org wrote: On Tue, Jul 14, 2009 at 3:38 AM, Adam Barthaba...@chromium.org wrote: Expected to crash, but passed (9): LayoutTests/fast/dom/offset-parent-positioned-and-inline.html LayoutTests/fast/events/message-channel-gc-2.html LayoutTests/fast/events/message-channel-gc-4.html LayoutTests/fast/events/message-channel-listener-circular-ownership.html LayoutTests/fast/events/message-port-constructor-for-deleted-document.html LayoutTests/fast/events/message-port-deleted-frame.html LayoutTests/fast/events/mouseover-mouseout2.html LayoutTests/fast/images/favicon-as-image.html LayoutTests/fast/images/pdf-as-background.html These started failing late yesterday afternoon--I'd double check to make sure they're actually happy again before re-enabling them. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 00:53, Dan Kegeld...@kegel.com wrote: It'd be nice if users didn't have to do that... does HTML 5 specify any kind of low power idle state for applications? Ideally when the screen blanks, we'd want all the apps to go into some kind of low power state, wouldn't we? It would be great if Gmail (or similar) could ask Chrome if it's in the background, and do less work until it comes back into focus. Mmm and use Android style tickles to wake up when new email arrives... Perhaps we could run a powertop bot, that monitors an idle session with a few tabs opened to catch any regressions with timers. I like that idea a lot. Cool! I need inside help to make that happen, are you the person I can poke? I've spent today looking into collecting powertop numbers. The latest version of gnome-power-manager has a powertop-like tab, and it's scraping it's data from devicekit-power. Karmic has both of these, I thought Jaunty had devkit-power but looking again I might have been mistaken. So once we have a system that has devicekit-power, we can use a tool[1] from the source tree to dump stats: $ ./devkit-power -w Total wakeups per minute: 462 Wakeup sources: userspace:0 id:12, interrupts:216.0, cmdline:interrupt, details:i8042 userspace:0 id:4082, interrupts:91.0, cmdline:kernel-ipi, details:Rescheduling interrupts userspace:0 id:30, interrupts:64.5, cmdline:interrupt, details:PCI-MSI-edge iwlagn userspace:0 id:28, interrupts:43.0, cmdline:interrupt, details:PCI-MSI-edge i915 userspace:0 id:14, interrupts:15.0, cmdline:interrupt, details:ata_piix userspace:1 id:5971, interrupts:8.9, cmdline:/home/shenki/chrome/chrome, details:hrtimer_start_range_ns (hrtimer_wakeup) userspace:1 id:29472, interrupts:8.5, cmdline:/usr/lib/firefox-3.5/firefox-3.5, details:hrtimer_start_range_ns (hrtimer_wakeup) Next is collecting them in the same manner that other perf stats are collected... Joel [1] http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/tree/tools --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
I think we should re-enable them ASAP unless there's some good reason why you want to wait. J On Tue, Jul 14, 2009 at 6:32 AM, Mohamed Mansour m...@chromium.org wrote: Lets wait a bit before re-enabling tests, but they seem to act happy, unlike last night. If no one re-enables them, I can do it when I get home around 6 EST. -- Mohamed Mansour On Tue, Jul 14, 2009 at 8:24 AM, Amanda Walker ama...@chromium.orgwrote: On Tue, Jul 14, 2009 at 3:38 AM, Adam Barthaba...@chromium.org wrote: Expected to crash, but passed (9): LayoutTests/fast/dom/offset-parent-positioned-and-inline.html LayoutTests/fast/events/message-channel-gc-2.html LayoutTests/fast/events/message-channel-gc-4.html LayoutTests/fast/events/message-channel-listener-circular-ownership.html LayoutTests/fast/events/message-port-constructor-for-deleted-document.html LayoutTests/fast/events/message-port-deleted-frame.html LayoutTests/fast/events/mouseover-mouseout2.html LayoutTests/fast/images/favicon-as-image.html LayoutTests/fast/images/pdf-as-background.html These started failing late yesterday afternoon--I'd double check to make sure they're actually happy again before re-enabling them. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Working on a new feature? Add extensions support.
We (the core extensions subteam) typically spec all new APIs and send them out for comment to the wider team. This helps keep things consistent and is easier since we are most familiar with the capabilities of the system. - a On Mon, Jul 13, 2009 at 10:25 PM, Darin Fisherda...@chromium.org wrote: What is the review process for new extension APIs? -Darin On Mon, Jul 13, 2009 at 5:17 PM, Erik Kay erik...@chromium.org wrote: If you're not working on any new features or new UI, you can probably skip the rest of this email. If you are, then please take the time to think about whether your feature should be accessible from extensions. Hopefully, no should be more of the exception than the rule. It turns out that adding extensions support is pretty easy. Here's a recent sample CL that adds a getLanguage() function that uses compact language detection: http://codereview.chromium.org/150062 (it's a fair number of files, but the changes are small and easy to understand) Feel free to send questions to the list. We're happy to help with everything from basic how-to questions, to API design, etc. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlowjor...@chromium.org wrote: I think we should re-enable them ASAP unless there's some good reason why you want to wait. They've been stable and passing all morning, so that works for me. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Working on a new feature? Add extensions support.
I think Aaron's mail makes the point, but just to be clear: before starting coding any new APIs, please send a rough proposal to Aaron and myself. We'll put together an API design based on your proposal and then send it around for broader feedback. Then we'll start looking at the CLs. Our turnaround time is pretty fast on this, so don't expect this to be a heavyweight process. thanks, Erik On Mon, Jul 13, 2009 at 5:17 PM, Erik Kay erik...@chromium.org wrote: If you're not working on any new features or new UI, you can probably skip the rest of this email. If you are, then please take the time to think about whether your feature should be accessible from extensions. Hopefully, no should be more of the exception than the rule. It turns out that adding extensions support is pretty easy. Here's a recent sample CL that adds a getLanguage() function that uses compact language detection: http://codereview.chromium.org/150062 (it's a fair number of files, but the changes are small and easy to understand) Feel free to send questions to the list. We're happy to help with everything from basic how-to questions, to API design, etc. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 5:53 AM, Joel Stanley j...@jms.id.au wrote: So we do this for GIFs. Can anyone tell me if background tabs re-paint themselves? If not, I'll add it to the TODO. IIRC renderers don't actually paint until the browser tells them to. Background renderers may set dirty regions so they know what they'll need to repaint though. (I could be wrong on all this, darin is the one who knows best.) I think I was overzealous saying that GIFs don't animate when in background tabs. They're designed not to, but the actual signal they use is (among other things) ScrollView::isOffscreen(), which looks like it's pretty much a NOP for our port. So one thing you could try is seeing if you can implement a Chromium version of platformIsOffscreen() and anything else that function needs, and check whether that helps lower CPU (e.g. for animated images in background tabs). 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: Improving power usage
On Tue, Jul 14, 2009 at 10:44 AM, Peter Kastingpkast...@google.com wrote: On Tue, Jul 14, 2009 at 5:53 AM, Joel Stanley j...@jms.id.au wrote: So we do this for GIFs. Can anyone tell me if background tabs re-paint themselves? If not, I'll add it to the TODO. IIRC renderers don't actually paint until the browser tells them to. Background renderers may set dirty regions so they know what they'll need to repaint though. (I could be wrong on all this, darin is the one who knows best.) I think I was overzealous saying that GIFs don't animate when in background tabs. They're designed not to, but the actual signal they use is (among other things) ScrollView::isOffscreen(), which looks like it's pretty much a NOP for our port. So one thing you could try is seeing if you can implement a Chromium version of platformIsOffscreen() and anything else that function needs, and check whether that helps lower CPU (e.g. for animated images in background tabs). Another way to approach this in general is to take a high-CPU site, put it in a background tab, then attach gdb to the process and break. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI canvas is hosed
On Tue, Jul 14, 2009 at 3:11 AM, Dean McNamee de...@chromium.org wrote: https://bugs.webkit.org/show_bug.cgi?id=27187 Maybe the spec needs to change? It seems like the patch moved away from spec-compliant behavior to match Gecko. I'm not sure what chromium-dev can do for you on this issue. Is there some way we can help? 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: FYI canvas is hosed
We weren't spec compliant: http://dev.w3.org/html5/spec/Overview.html The lineTo(x, y) method must do nothing if the context has no subpaths. On Tue, Jul 14, 2009 at 8:13 PM, Peter Kastingpkast...@chromium.org wrote: On Tue, Jul 14, 2009 at 3:11 AM, Dean McNamee de...@chromium.org wrote: https://bugs.webkit.org/show_bug.cgi?id=27187 Maybe the spec needs to change? It seems like the patch moved away from spec-compliant behavior to match Gecko. I'm not sure what chromium-dev can do for you on this issue. Is there some way we can help? 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: FYI canvas is hosed
On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee de...@chromium.org wrote: We weren't spec compliant: http://dev.w3.org/html5/spec/Overview.html The lineTo(x, y) method must do nothing if the context has no subpaths. Isn't that what I just said? That the current behavior doesn't match the spec? I still don't understand what's going on or what chromium-dev should do about it. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI canvas is hosed
My point was the behavior before the patch was wrong. What they did now is closer, but still wrong. On Tue, Jul 14, 2009 at 8:22 PM, Peter Kastingpkast...@chromium.org wrote: On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee de...@chromium.org wrote: We weren't spec compliant: http://dev.w3.org/html5/spec/Overview.html The lineTo(x, y) method must do nothing if the context has no subpaths. Isn't that what I just said? That the current behavior doesn't match the spec? I still don't understand what's going on or what chromium-dev should do about it. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Javascript scope within PAC files?
Can someone explain the scope of javascript calls available within PAC files that chrome parses? What I'm getting at is, can we use the chrome api javascript calls within PAC files? Why would you want/need this? First thought is to determine if the browser is in incognito mode or not, but there may be other applications. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Javascript scope within PAC files?
I tend to think incognito mode as a personal (and very private) decision. As a result, I'd tend to prefer that it be very difficult to leak such status further than absolutely necessary. Allowing your proxy provider to detect this status seems like a violation of the need to know, but perhaps that because I see a proxy provider as an ISP in the common case. If I thought I could trust my proxy provider, perhaps I'd be more open about this status. ...but perhaps that was not the best example of your need for the API access?? Jim On Tue, Jul 14, 2009 at 11:35 AM, Peter peter.j.obr...@gmail.com wrote: Can someone explain the scope of javascript calls available within PAC files that chrome parses? What I'm getting at is, can we use the chrome api javascript calls within PAC files? Why would you want/need this? First thought is to determine if the browser is in incognito mode or not, but there may be other applications. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Javascript scope within PAC files?
On Jul 14, 12:23 pm, Jim Roskind j...@chromium.org wrote: I tend to think incognito mode as a personal (and very private) decision. As a result, I'd tend to prefer that it be very difficult to leak such status further than absolutely necessary. Any web page that wishes can determine if you are (likely) in Incognito Mode: http://jeremiahgrossman.blogspot.com/2009/03/detecting-private-browsing-mode.html It's not something that these modes try and prevent - they are all about not leaving tracks on the client. Cheers Chris Allowing your proxy provider to detect this status seems like a violation of the need to know, but perhaps that because I see a proxy provider as an ISP in the common case. If I thought I could trust my proxy provider, perhaps I'd be more open about this status. ...but perhaps that was not the best example of your need for the API access?? Jim On Tue, Jul 14, 2009 at 11:35 AM, Peter peter.j.obr...@gmail.com wrote: Can someone explain the scope of javascript calls available within PAC files that chrome parses? What I'm getting at is, can we use the chrome api javascript calls within PAC files? Why would you want/need this? First thought is to determine if the browser is in incognito mode or not, but there may be other applications. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Javascript scope within PAC files?
I guess such a function could be used to 'detect' incognito mode in a forced - PAC environment, ie where the PAC is served by your employer at work. My intention was to devise a way to set an alternate proxy server to use within incognito mode. Developers have opposed adding proxy configuration to Chrome proper. (http://code.google.com/p/chromium/issues/detail?id=266) I'm trying to find ways to make advanced proxy configurations. In this case, a user could add a test case to the PAC file to check if the browser is incognito, and if it is, use a proxy. See related here (http://code.google.com/p/chromium/issues/detail? id=509) and my comment (10). On Jul 14, 3:23 pm, Jim Roskind j...@chromium.org wrote: I tend to think incognito mode as a personal (and very private) decision. As a result, I'd tend to prefer that it be very difficult to leak such status further than absolutely necessary. Allowing your proxy provider to detect this status seems like a violation of the need to know, but perhaps that because I see a proxy provider as an ISP in the common case. If I thought I could trust my proxy provider, perhaps I'd be more open about this status. ...but perhaps that was not the best example of your need for the API access?? Jim On Tue, Jul 14, 2009 at 11:35 AM, Peter peter.j.obr...@gmail.com wrote: Can someone explain the scope of javascript calls available within PAC files that chrome parses? What I'm getting at is, can we use the chrome api javascript calls within PAC files? Why would you want/need this? First thought is to determine if the browser is in incognito mode or not, but there may be other applications. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] WebCore.gypi and JavaScriptCore.gypi now online.
Dear All, Just a few hours ago, I switched over webkit.gyp to pull the list of WebCore and JavaScriptCore files from upstream-living WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi, respectively. This change should alleviate a lot of pain for WebKit gardeners and those landing two-sided patches. In many cases, this will eliminate the need for two-sided patches. Please let me know if you are encountering weird problems and/or deep spiritual experiences after syncing past this change. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
And as soon as I took them out, they started failing again. We're reverting. --Amanda On Tue, Jul 14, 2009 at 12:08 PM, Amanda Walkerama...@chromium.org wrote: On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlowjor...@chromium.org wrote: I think we should re-enable them ASAP unless there's some good reason why you want to wait. They've been stable and passing all morning, so that works for me. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebCore.gypi and JavaScriptCore.gypi now online.
2009/7/14 Dimitri Glazkov dglaz...@chromium.org: This change should alleviate a lot of pain for WebKit gardeners and those landing two-sided patches. In many cases, this will eliminate the need for two-sided patches. I owe you a beer then!:) -- Gilda Radner - Adopted kids are such a pain - you have to teach them how to look like you. - http://www.brainyquote.com/quotes/authors/g/gilda_radner.html --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
I'd leave decisions about the worker related message port tests for drew and dimich... the feature isn't fully functional yet in chrome (even if they don't crash and happen to pass and such). I've been unable to dup the LayoutTests/fast/events/mouseover-mouseout2.html failure locally and have no clue why it started failing yesterday afternoon... ditto with the embed-display-none.html test. On Tue, Jul 14, 2009 at 1:06 PM, Amanda Walker ama...@chromium.org wrote: And as soon as I took them out, they started failing again. We're reverting. --Amanda On Tue, Jul 14, 2009 at 12:08 PM, Amanda Walkerama...@chromium.org wrote: On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlowjor...@chromium.org wrote: I think we should re-enable them ASAP unless there's some good reason why you want to wait. They've been stable and passing all morning, so that works for me. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
On Tue, Jul 14, 2009 at 1:28 PM, Michael Nordmanmicha...@google.com wrote: I'd leave decisions about the worker related message port tests for drew and dimich... the feature isn't fully functional yet in chrome (even if they don't crash and happen to pass and such). Seems like we should turn the test on so we know if it regresses. :) Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Buildbot performance issue.
Hello, We reached a point where we have too many build slaves and too many users to get good performance/latency out of our current buildbot waterfall and console view page. We've been tweaking the page a lot lately to make it faster to load, but the number of new slaves every day, and the number of new users make it going slower faster than we can address the problem. This morning buildbot was completely unresponsive because it was not able to keep up with the demand. To make it come back to life, I disabled two features, which account for about 50% of all traffics : The buildbot chrome extensions, and the top 3 overview bars at the top of the waterfall. This will be able to make it stay online for a while, but this is not ideal. It's time to think of a better solution. The underlying problem with buildbot is the database format, which is just hundred of thousand of files on the harddrive, with no seek capability, and the fact that the webserver itself is single threaded. We currently have 63 slaves on our main waterfall. I think this is too many for what buildbot can really support. We would ideally need to split it. Q1: Want kind of split would you prefer? mac/linux/windows or chromium/webkit/modules or full/windows/mac/linux/memory, etc? the main buildbot page would most likely become a bunch of iframe to display all the slaves at the same time. The console view integration might be a little bit less nice. If there is anyone with web devel experience who wants to help, we could modify the current waterfall to fetch only json data from the buildbot, and merge them together, client side, to get a combined view. Q2: How many changes do we need to display on the console view? We are currently displaying the last 50 changes. Which is usually half-day. If people don't mind about this, we could scale back to 30. This would make it a little faster to load. Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? Q4: How much build history do we need? Right now stdio log are kept for 3 weeks and build results (green, red) are kept for 1 month. Older build results are archived but can't be accessed directly by the buildbot. If you have any other suggestions, please let me know! Some things that we can't do: - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. - Change buildbot to use non-single threaded web server. This is way too much involved. *WHAT I NEED YOU HELP WITH :* 1. No more scraping of the waterfall please! If you need to crawl the logs, let me know and I can run your script on the database directly. 2. If you know about apache mod_cache / mod_proxy, and wants to help, please let me know. build.chromium.org is a proxied cache of the real buildbot server, and the cache does not work well. This contribute to another got 25/30% of the overall load on the buildbot. Thanks! Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Invitation to collaborate on Metalink and improve downloading the open web
Hi, This is an invitation to people from Chromium and other browser/ download application makers to collaborate on Metalink. Metalink has the potential to improve the usability of the Internet at a large scale, particularly for users in countries with poor Internet connectivity (but also for others). Error correction, increased security, and failover to alternate mirrors are some of the benefits. It also provides structured information about downloads that can be used by download sites and search engines. Metalink is an XML file format feature set that download apps support to offer improved downloads. It's developed by an open source community project that, after 3.5 years, is currently in Internet Draft form at the IETF [1]. About 50 apps currently support Metalink, including browsers, FTP clients, P2P apps, download managers, and the popular Firefox addon DownThemAll! [2] Metalink is frequently used by open source projects like OpenOffice.org, and many Linux distributions. http://www.metalinker.org http://en.wikipedia.org/wiki/Metalink Chromium bug: http://code.google.com/p/chromium/issues/detail?id=1751 -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads [1] http://tools.ietf.org/html/draft-bryan-metalink [2] http://www.metalinker.org/images/dta_ubuntu.png --~--~-~--~~~---~--~~ Chromium 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 performance issue.
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org wrote: The underlying problem with buildbot is the database format, which is just hundred of thousand of files on the harddrive, with no seek capability, and the fact that the webserver itself is single threaded. We currently have 63 slaves on our main waterfall. I think this is too many for what buildbot can really support. We would ideally need to split it. Can we get upstream buildbot devs involved in this discussion? It seems they ought to be able to scale better than they have. It seems to me a caching layer that only ever hit the backend every ten seconds would allow it ten seconds to grind through its computations, which should be more than sufficient, without any extra splitting up required. That is, we should (a) fix the proxy and (b) make every use the proxy. Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? I personally hate auto-refresh. We should make it opt-in since I doubt most users need it and it adds load. I expect many people (myself included) leave the buildbot page open in a background tab and have it continually refreshing despite not looking at it. (My other common use case: the tree is red, I start scrolling down to see what's gone wrong, and then the page refreshes out from under me and I lose where I was looking.) - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. This is absurdly powerful! It should have all the data necessary to generate the page in RAM already, no need for even touching the disks (?). --~--~-~--~~~---~--~~ Chromium 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 performance issue.
On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? Why do we even default the waterfall to autorefresh? Most of the time when I commit, I refresh it myself obsessively anyways. I get the impression that most people do this. I imagine that turning off autorefresh and allowing people that really want it to opt in would save a lot of unnecessary overhead (e.g. people leave the waterfall page open for hours when they're not at their desk). I'll note that upstream WebKit's waterfall does not autorefresh and I've never heard someone complain about it. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Invitation to collaborate on Metalink and improve downloading the open web
On Tue, Jul 14, 2009 at 2:24 PM, Ant Bryananthonybr...@gmail.com wrote: This is an invitation to people from Chromium and other browser/ download application makers to collaborate on Metalink. This sounds pretty cool, but I suspect you know more about what is needed to make this work than we do, and also more motivation to make it happen. I think if you brought up a design questions like in http://groups.google.com/group/metalink-discussion/msg/2c63ced761bc95e6?hl=en on this mailing list you'd find some helpful answers. --~--~-~--~~~---~--~~ Chromium 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 performance issue.
I was just thinking... doesn't it have a reverse proxy in front of it? It could also force content cache time of 60s or even more... Something like Squid or Varnish. Oh, and today morning was probably me scraping the logs. :-( Sorry. On Tue, Jul 14, 2009 at 14:18, Nicolas Sylvainnsylv...@chromium.org wrote: Hello, We reached a point where we have too many build slaves and too many users to get good performance/latency out of our current buildbot waterfall and console view page. We've been tweaking the page a lot lately to make it faster to load, but the number of new slaves every day, and the number of new users make it going slower faster than we can address the problem. This morning buildbot was completely unresponsive because it was not able to keep up with the demand. To make it come back to life, I disabled two features, which account for about 50% of all traffics : The buildbot chrome extensions, and the top 3 overview bars at the top of the waterfall. This will be able to make it stay online for a while, but this is not ideal. It's time to think of a better solution. The underlying problem with buildbot is the database format, which is just hundred of thousand of files on the harddrive, with no seek capability, and the fact that the webserver itself is single threaded. We currently have 63 slaves on our main waterfall. I think this is too many for what buildbot can really support. We would ideally need to split it. Q1: Want kind of split would you prefer? mac/linux/windows or chromium/webkit/modules or full/windows/mac/linux/memory, etc? the main buildbot page would most likely become a bunch of iframe to display all the slaves at the same time. The console view integration might be a little bit less nice. If there is anyone with web devel experience who wants to help, we could modify the current waterfall to fetch only json data from the buildbot, and merge them together, client side, to get a combined view. Q2: How many changes do we need to display on the console view? We are currently displaying the last 50 changes. Which is usually half-day. If people don't mind about this, we could scale back to 30. This would make it a little faster to load. Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? Q4: How much build history do we need? Right now stdio log are kept for 3 weeks and build results (green, red) are kept for 1 month. Older build results are archived but can't be accessed directly by the buildbot. If you have any other suggestions, please let me know! Some things that we can't do: - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. - Change buildbot to use non-single threaded web server. This is way too much involved. WHAT I NEED YOU HELP WITH : 1. No more scraping of the waterfall please! If you need to crawl the logs, let me know and I can run your script on the database directly. 2. If you know about apache mod_cache / mod_proxy, and wants to help, please let me know. build.chromium.org is a proxied cache of the real buildbot server, and the cache does not work well. This contribute to another got 25/30% of the overall load on the buildbot. Thanks! Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Buildbot performance issue.
If I understand right, simply serving the auto-refresh requests is substantial? At least for the main page, a reverse in accelerator mode could turn that into a constant load. [I'd offer to help, but I don't know what kind of technology we're talking about, here.] -scott On Tue, Jul 14, 2009 at 2:25 PM, Evan Martine...@chromium.org wrote: On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org wrote: The underlying problem with buildbot is the database format, which is just hundred of thousand of files on the harddrive, with no seek capability, and the fact that the webserver itself is single threaded. We currently have 63 slaves on our main waterfall. I think this is too many for what buildbot can really support. We would ideally need to split it. Can we get upstream buildbot devs involved in this discussion? It seems they ought to be able to scale better than they have. It seems to me a caching layer that only ever hit the backend every ten seconds would allow it ten seconds to grind through its computations, which should be more than sufficient, without any extra splitting up required. That is, we should (a) fix the proxy and (b) make every use the proxy. Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? I personally hate auto-refresh. We should make it opt-in since I doubt most users need it and it adds load. I expect many people (myself included) leave the buildbot page open in a background tab and have it continually refreshing despite not looking at it. (My other common use case: the tree is red, I start scrolling down to see what's gone wrong, and then the page refreshes out from under me and I lose where I was looking.) - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. This is absurdly powerful! It should have all the data necessary to generate the page in RAM already, no need for even touching the disks (?). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Javascript scope within PAC files?
What I'm getting at is, can we use the chrome api javascript calls within PAC files? The PAC environment does not allow access to any of the chrome extension APIs. Moreover, both incognito requests and non-incognito requests flow through the same PAC script instance, so there is no way to figure out from within the PAC script if the request originated from an incognito profile or not. Your suggestion of augmenting the PAC enviroment to expose incognito information could be done, and I am interested to hear more about the use-cases. Can someone explain the scope of javascript calls available within PAC files that chrome parses? The PAC environment in chromium exposes the same functions as in Firefox: alert() convert_addr() dateRange() dnsDomainIs() dnsDomainLevelIs() dnsResolve() isInNet() isPlainHostName() isResolvable() localHostOrDomainIs() myIpAddress() shExpMatch() timeRange() weekdayRange() Developers have opposed adding proxy configuration to Chrome proper. (http://code.google.com/p/chromium/issues/detail?id=266) I expect that this UI-level restriction on not giving the option to override use of system proxy settings is going to change. In particular, the use-case that comes to mind is chrome extensions. These guys should have the ability to change the proxy settings, so there necessarily will need to be some indication in the UI whether you are using the system proxy settings, or a custom set of proxy settings. Note that you can currently override the proxy settings, using command line flags: --no-proxy-server --proxy-auto-detect --proxy-bypass-urls=... --proxy-pac-url=... On Tue, Jul 14, 2009 at 12:46 PM, Peterpeter.j.obr...@gmail.com wrote: I guess such a function could be used to 'detect' incognito mode in a forced - PAC environment, ie where the PAC is served by your employer at work. My intention was to devise a way to set an alternate proxy server to use within incognito mode. Developers have opposed adding proxy configuration to Chrome proper. (http://code.google.com/p/chromium/issues/detail?id=266) I'm trying to find ways to make advanced proxy configurations. In this case, a user could add a test case to the PAC file to check if the browser is incognito, and if it is, use a proxy. See related here (http://code.google.com/p/chromium/issues/detail? id=509) and my comment (10). On Jul 14, 3:23 pm, Jim Roskind j...@chromium.org wrote: I tend to think incognito mode as a personal (and very private) decision. As a result, I'd tend to prefer that it be very difficult to leak such status further than absolutely necessary. Allowing your proxy provider to detect this status seems like a violation of the need to know, but perhaps that because I see a proxy provider as an ISP in the common case. If I thought I could trust my proxy provider, perhaps I'd be more open about this status. ...but perhaps that was not the best example of your need for the API access?? Jim On Tue, Jul 14, 2009 at 11:35 AM, Peter peter.j.obr...@gmail.com wrote: Can someone explain the scope of javascript calls available within PAC files that chrome parses? What I'm getting at is, can we use the chrome api javascript calls within PAC files? Why would you want/need this? First thought is to determine if the browser is in incognito mode or not, but there may be other applications. --~--~-~--~~~---~--~~ Chromium 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 performance issue.
On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org wrote: The underlying problem with buildbot is the database format, which is just hundred of thousand of files on the harddrive, with no seek capability, and the fact that the webserver itself is single threaded. We currently have 63 slaves on our main waterfall. I think this is too many for what buildbot can really support. We would ideally need to split it. Can we get upstream buildbot devs involved in this discussion? It seems they ought to be able to scale better than they have. I talked to them a little. They do plan some of that for their 1.0 release, but they said that it was not on the radar until then. It seems to me a caching layer that only ever hit the backend every ten seconds would allow it ten seconds to grind through its computations, which should be more than sufficient, without any extra splitting up required. That is, we should (a) fix the proxy and (b) make every use the proxy. That makes a lot of sense. I agree that we should fix the proxy, and make more people use it. Some direct buildbot access would still be required internally to force a build and stuff like that. Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? I personally hate auto-refresh. We should make it opt-in since I doubt most users need it and it adds load. I expect many people (myself included) leave the buildbot page open in a background tab and have it continually refreshing despite not looking at it. (My other common use case: the tree is red, I start scrolling down to see what's gone wrong, and then the page refreshes out from under me and I lose where I was looking.) Yep, a lot of people told me the same thing. Some other told me they would like a faster reload. Now i'm tempted to let the user control the reload and not give a default one. - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. This is absurdly powerful! It should have all the data necessary to generate the page in RAM already, no need for even touching the disks (?). Yeah, i'm not too sure how to debug this. When I strace the process I only see file reads, scrolling, like crazy, all the time. 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: Buildbot performance issue.
On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org wrote: The underlying problem with buildbot is the database format, which is just hundred of thousand of files on the harddrive, with no seek capability, and the fact that the webserver itself is single threaded. We currently have 63 slaves on our main waterfall. I think this is too many for what buildbot can really support. We would ideally need to split it. Can we get upstream buildbot devs involved in this discussion? It seems they ought to be able to scale better than they have. I talked to them a little. They do plan some of that for their 1.0 release, but they said that it was not on the radar until then. It seems to me a caching layer that only ever hit the backend every ten seconds would allow it ten seconds to grind through its computations, which should be more than sufficient, without any extra splitting up required. That is, we should (a) fix the proxy and (b) make every use the proxy. That makes a lot of sense. I agree that we should fix the proxy, and make more people use it. Some direct buildbot access would still be required internally to force a build and stuff like that. Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? I personally hate auto-refresh. We should make it opt-in since I doubt most users need it and it adds load. I expect many people (myself included) leave the buildbot page open in a background tab and have it continually refreshing despite not looking at it. (My other common use case: the tree is red, I start scrolling down to see what's gone wrong, and then the page refreshes out from under me and I lose where I was looking.) Yep, a lot of people told me the same thing. Some other told me they would like a faster reload. Now i'm tempted to let the user control the reload and not give a default one. - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. This is absurdly powerful! It should have all the data necessary to generate the page in RAM already, no need for even touching the disks (?). Yeah, i'm not too sure how to debug this. When I strace the process I only see file reads, scrolling, like crazy, all the time. That is pretty nuts. Is it calling fsync or something crazy? Since you said strace, I'm assmuming linux. In that case, the buffer cache should be saving you from disk accesses for most everything. -Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Buildbot performance issue.
On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvainnsylv...@chromium.org wrote: - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. This is absurdly powerful! It should have all the data necessary to generate the page in RAM already, no need for even touching the disks (?). Yeah, i'm not too sure how to debug this. When I strace the process I only see file reads, scrolling, like crazy, all the time. Nicolas Can't we use RAM disk? If we made a RAM disk and moved all the relevant files there, shouldn't it speed things up? Ryosuke --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Javascript scope within PAC files?
On Tue, Jul 14, 2009 at 2:35 PM, Eric Roman ero...@chromium.org wrote: Your suggestion of augmenting the PAC enviroment to expose incognito information could be done, and I am interested to hear more about the use-cases. Incognito isn't designed to hide user details from websites (e.g. by sending requests through Tor, changing referrers, blocking cookies, etc.) and I'm uncomfortable with changes designed to allow partial movement in that direction. I don't think Incognito's meaning should be overloaded. I would be more comfortable with changes that allow someone to e.g. write a Chrome extension that provides everything needed for cover your tracks online browsing. 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: Buildbot performance issue.
On Tue, Jul 14, 2009 at 2:40 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: That is pretty nuts. Is it calling fsync or something crazy? Since you said strace, I'm assmuming linux. In that case, the buffer cache should be saving you from disk accesses for most everything. Of course, vmstat 1 will tell you what disk IO is happening. If you don't have noatime, that would probably be good. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Buildbot performance issue.
On Tue, Jul 14, 2009 at 2:35 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org wrote: It seems to me a caching layer that only ever hit the backend every ten seconds would allow it ten seconds to grind through its computations, which should be more than sufficient, without any extra splitting up required. That is, we should (a) fix the proxy and (b) make every use the proxy. That makes a lot of sense. I agree that we should fix the proxy, and make more people use it. Some direct buildbot access would still be required internally to force a build and stuff like that. Can we make this stuff be based on IP instead of what URL you hit, e.g. have the force build UI there on the proxy, but have it return a 403 + descriptive error page when you try to do it? Alternately, can we have the internal URLs also use the proxy? Or have them use a different proxy if that's easier? Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebCore.gypi and JavaScriptCore.gypi now online.
I think there's enough of us that it'd be cheaper to just buy him a keg together. :-) On Tue, Jul 14, 2009 at 1:06 PM, Michelangelo De Simone micde...@gmail.comwrote: 2009/7/14 Dimitri Glazkov dglaz...@chromium.org: This change should alleviate a lot of pain for WebKit gardeners and those landing two-sided patches. In many cases, this will eliminate the need for two-sided patches. I owe you a beer then!:) -- Gilda Radner - Adopted kids are such a pain - you have to teach them how to look like you. - http://www.brainyquote.com/quotes/authors/g/gilda_radner.html --~--~-~--~~~---~--~~ Chromium 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 performance issue.
On Tue, Jul 14, 2009 at 2:42 PM, Adam Langley a...@chromium.org wrote: On Tue, Jul 14, 2009 at 2:40 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: That is pretty nuts. Is it calling fsync or something crazy? Since you said strace, I'm assmuming linux. In that case, the buffer cache should be saving you from disk accesses for most everything. Of course, vmstat 1 will tell you what disk IO is happening. If you don't have noatime, that would probably be good. atop is a really nice program for getting a birds eye view of what's going on with the system. It's not installed by default, but if you're running ubuntu, it's easy to install. More generally: I think there are a couple uses of the build bots: 1) Most people just want to know can I commit and then are watching one specific CL's status. In this case, not auto-refreshing is fine and not much history is fine. 2) Sheriffing is the one case where I think you actually do need auto-refreshing, but normally you don't need a lot of history. That said, sometimes things fail and then 3) You're trying to fix things: In this case you want to see a lot of history (or at least need the option to see more) and you do NOT want it to auto refresh. I've definitely had times when I wish there was a show me more button. And I've definitely have been reading something far down the page only to have it refresh on me. It seems to me that these requirements are diverse enough that one single configuration isn't going to make everyone happy. I know you can do a bunch of customization so you can see exactly what you want, but I assume that will only chew up more resources. Maybe the right way to go is a couple customized pages for each roll? There's definitely much more information there than people need most of the time, though. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Javascript scope within PAC files?
On Tue, Jul 14, 2009 at 3:34 PM, Peter O'Brienpeter.j.obr...@gmail.com wrote: The PAC environment does not allow access to any of the chrome extension APIs. Thanks for the clarification. Your suggestion of augmenting the PAC enviroment to expose incognito information could be done, and I am interested to hear more about the use-cases. Initial use case is simply detecting an incognito instance and routing requests through a socks proxy, for instance to avoid ISP filtering, protect data/privacy, etc. I'm sure there are other ways this can be done, perhaps through an API as Peter suggested above. For other use cases, it might be interesting to open the PAC script up to an API so that extensions can access it in memory. It would make writing an ad-blocking extension trivial, for example. Not sure if that would be appropriate or work well. I expect that this UI-level restriction on not giving the option to override use of system proxy settings is going to change. Good to hear. For the PAC command-line, can you specify filesystem locations or does it have to be served via http? It can be file-system local, by using file:// urls. --~--~-~--~~~---~--~~ Chromium 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 performance issue.
I would like to see auto refresh turned off by default. That might help the load. -- Mohamed Mansour On Tue, Jul 14, 2009 at 7:15 PM, Michael Nordman micha...@google.comwrote: Turning off auto refresh by default sounds reasonable idea right now... with an option to enable it if really desired... autorefresh[=n] where n is a number of minutes maybe (defaults to 1) type thing. A fair amount of the load may just evaporate with that change. On Tue, Jul 14, 2009 at 3:32 PM, Jeremy Orlow jor...@google.com wrote: On Tue, Jul 14, 2009 at 2:42 PM, Adam Langley a...@chromium.org wrote: On Tue, Jul 14, 2009 at 2:40 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: That is pretty nuts. Is it calling fsync or something crazy? Since you said strace, I'm assmuming linux. In that case, the buffer cache should be saving you from disk accesses for most everything. Of course, vmstat 1 will tell you what disk IO is happening. If you don't have noatime, that would probably be good. atop is a really nice program for getting a birds eye view of what's going on with the system. It's not installed by default, but if you're running ubuntu, it's easy to install. More generally: I think there are a couple uses of the build bots: 1) Most people just want to know can I commit and then are watching one specific CL's status. In this case, not auto-refreshing is fine and not much history is fine. 2) Sheriffing is the one case where I think you actually do need auto-refreshing, but normally you don't need a lot of history. That said, sometimes things fail and then 3) You're trying to fix things: In this case you want to see a lot of history (or at least need the option to see more) and you do NOT want it to auto refresh. I've definitely had times when I wish there was a show me more button. And I've definitely have been reading something far down the page only to have it refresh on me. It seems to me that these requirements are diverse enough that one single configuration isn't going to make everyone happy. I know you can do a bunch of customization so you can see exactly what you want, but I assume that will only chew up more resources. Maybe the right way to go is a couple customized pages for each roll? There's definitely much more information there than people need most of the time, though. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
On Tue, Jul 14, 2009 at 5:48 PM, Drew Wilson atwil...@google.com wrote: I would actually have expected the normal (non-worker) MessagePort tests to pass/not-crash, as I don't think that jam has gotten far enough into the implementation to break the non-cross-process versions :) I have a work item on my plate to review all of the message port tests, as even the non-passing ones should run without crashing. I'll try to get to it later this week or early next week. -atw On Tue, Jul 14, 2009 at 1:28 PM, Michael Nordman micha...@google.comwrote: I'd leave decisions about the worker related message port tests for drew and dimich... the feature isn't fully functional yet in chrome (even if they don't crash and happen to pass and such). I've been unable to dup the LayoutTests/fast/events/mouseover-mouseout2.html failure locally and have no clue why it started failing yesterday afternoon... ditto with the embed-display-none.html test. On Tue, Jul 14, 2009 at 1:06 PM, Amanda Walker ama...@chromium.orgwrote: And as soon as I took them out, they started failing again. We're reverting. --Amanda On Tue, Jul 14, 2009 at 12:08 PM, Amanda Walkerama...@chromium.org wrote: On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlowjor...@chromium.org wrote: I think we should re-enable them ASAP unless there's some good reason why you want to wait. They've been stable and passing all morning, so that works for me. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux developers: you need to read this
* If you update your google-chrome-unstable packages and your development builds start hanging, sync to = 20710 * Details: The latest google-chrome packages contain a sandbox binary, which the development builds of chromium will pick up on automatically. However, for safety reasons, the sandbox binary will only exec a fixed chrome binary location. Since development builds will be somewhere else in the filesystem, this means that they will fail to start their zygote processes and generally be very sad. I've committed a change which changes the default path so that we won't pickup the system sandbox anyway. However, we /do/ want people developing with the sandbox, but we don't want the general sandbox binary to be able to exec anything. We could have chromium try and find its sandbox binary relative to the build directory, but some people build on NFS and, since the sandbox binary needs to be SUID, this won't work for them. So, there's now a GYP variable which will build a sandbox binary that doesn't enforce the path restriction, it only requires that the binary being run be owned by the current user and be non-SUID and non-GUID. Also, you can now select the sandbox binary to run with the environment variable CHROME_DEVEL_SANDBOX (iff the current binary is owned by the current real user). So, if you're developing on Linux, you should do the following: * Sync up to = 20710 * Edit build/common.gypi and change linux_suid_sandbox_restrictions from Path to User * build chrome_sandbox * sudo cp out/Debug/chrome_sandbox /usr/local/sbin/chrome-devel-sandbox * sudo chown root:root /usr/local/sbin/chrome-devel-sandbox * sudo chmod 4755 /usr/local/sbin/chrome-devel-sandbox * export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox * Put the last line in your ~/.bashrc (or .zshenv etc) Cheers AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linux developers: you need to read this
On Tue, Jul 14, 2009 at 7:12 PM, Adam Langley a...@chromium.org wrote: * If you update your google-chrome-unstable packages and your development builds start hanging, sync to = 20710 * Details: The latest google-chrome packages contain a sandbox binary, which the development builds of chromium will pick up on automatically. However, for safety reasons, the sandbox binary will only exec a fixed chrome binary location. Since development builds will be somewhere else in the filesystem, this means that they will fail to start their zygote processes and generally be very sad. I've committed a change which changes the default path so that we won't pickup the system sandbox anyway. However, we /do/ want people developing with the sandbox, but we don't want the general sandbox binary to be able to exec anything. We could have chromium try and find its sandbox binary relative to the build directory, but some people build on NFS and, since the sandbox binary needs to be SUID, this won't work for them. So, there's now a GYP variable which will build a sandbox binary that doesn't enforce the path restriction, it only requires that the binary being run be owned by the current user and be non-SUID and non-GUID. Also, you can now select the sandbox binary to run with the environment variable CHROME_DEVEL_SANDBOX (iff the current binary is owned by the current real user). So, if you're developing on Linux, you should do the following: * Sync up to = 20710 * Edit build/common.gypi and change linux_suid_sandbox_restrictions from Path to User Does this part need to be sticky, or is it just to build the chrome-devel-sandbox ? If the former it is going to be painful. Antoine * build chrome_sandbox * sudo cp out/Debug/chrome_sandbox /usr/local/sbin/chrome-devel-sandbox * sudo chown root:root /usr/local/sbin/chrome-devel-sandbox * sudo chmod 4755 /usr/local/sbin/chrome-devel-sandbox * export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox * Put the last line in your ~/.bashrc (or .zshenv etc) Cheers AGL -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? --~--~-~--~~~---~--~~ Chromium 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 developers: you need to read this
On Tue, Jul 14, 2009 at 8:09 PM, Jeremy Orlowjor...@chromium.org wrote: Also, will the try bots and build bots run with the sandbox on? No, the build-bots currently run without a sandbox. I agree this should probably be changed and it's on my TODO list. Unfortunately, it's a very long list right now. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linux developers: you need to read this
On Tue, Jul 14, 2009 at 8:14 PM, Antoine Labourpi...@google.com wrote: Does this part need to be sticky, or is it just to build the chrome-devel-sandbox ? If the former it is going to be painful. You only need to build and install it once. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linux developers: you need to read this
On Tue, Jul 14, 2009 at 8:19 PM, Adam Langley a...@chromium.org wrote: On Tue, Jul 14, 2009 at 8:14 PM, Antoine Labourpi...@google.com wrote: Does this part need to be sticky, or is it just to build the chrome-devel-sandbox ? If the former it is going to be painful. You only need to build and install it once. AGL I meant the change in common.gpyi. Once I built the chrome-devel-sandbox I can revert that file, right ? Antoine --~--~-~--~~~---~--~~ Chromium 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 developers: you need to read this
On Tue, Jul 14, 2009 at 8:21 PM, Antoine Labourpi...@google.com wrote: I meant the change in common.gpyi. Once I built the chrome-devel-sandbox I can revert that file, right ? Yes. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linux developers: you need to read this
On Wed, Jul 15, 2009 at 02:12, Adam Langleya...@chromium.org wrote: * build chrome_sandbox I think the defines got messed up somewhere... http://codereview.chromium.org/149667 fixes it for me. Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: LayoutTest unexpected success
Right now there's a bunch of unexpected passing media layout tests, but they should start failing again as soon as the WebKit builder bot is clobbered (we're temporarily expecting them to fail until we sort out some issues). Andrew On Tue, Jul 14, 2009 at 5:50 PM, Drew Wilson atwil...@chromium.org wrote: On Tue, Jul 14, 2009 at 5:48 PM, Drew Wilson atwil...@google.com wrote: I would actually have expected the normal (non-worker) MessagePort tests to pass/not-crash, as I don't think that jam has gotten far enough into the implementation to break the non-cross-process versions :) I have a work item on my plate to review all of the message port tests, as even the non-passing ones should run without crashing. I'll try to get to it later this week or early next week. -atw On Tue, Jul 14, 2009 at 1:28 PM, Michael Nordman micha...@google.comwrote: I'd leave decisions about the worker related message port tests for drew and dimich... the feature isn't fully functional yet in chrome (even if they don't crash and happen to pass and such). I've been unable to dup the LayoutTests/fast/events/mouseover-mouseout2.html failure locally and have no clue why it started failing yesterday afternoon... ditto with the embed-display-none.html test. On Tue, Jul 14, 2009 at 1:06 PM, Amanda Walker ama...@chromium.orgwrote: And as soon as I took them out, they started failing again. We're reverting. --Amanda On Tue, Jul 14, 2009 at 12:08 PM, Amanda Walkerama...@chromium.org wrote: On Tue, Jul 14, 2009 at 12:05 PM, Jeremy Orlowjor...@chromium.org wrote: I think we should re-enable them ASAP unless there's some good reason why you want to wait. They've been stable and passing all morning, so that works for me. --Amanda --~--~-~--~~~---~--~~ Chromium 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 developers: you need to read this
On Tue, Jul 14, 2009 at 8:50 PM, Joel Stanleyj...@jms.id.au wrote: I think the defines got messed up somewhere... Crap, yes. Thanks for that. Fixed. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
