[chromium-dev] Re: Seeing a grey bar at the bottom of the 211 mac dev release? Read on.
I hope this serves to remind everyone that we need to keep the tree in a state where it is always shippable. If you're going to implement only a portion of a feature, make sure it's not visible to the user until it's fully operational. Even if you intend to flip the rest on in a few hours, something may go awry (tree closures, concerns raised about your cl, a new episode of My Antonio on VH1, etc) that prevents you from landing for a day or more. On Sat, Sep 19, 2009 at 2:37 PM, Nico Weber tha...@chromium.org wrote: By the way: After resizing the window, you can hit cmd-shift-b twice to move the bar back to the bottom of the window. On Sat, Sep 19, 2009 at 11:01 AM, Nico Weber tha...@chromium.org wrote: Hi, wondering why there's a grey, useless bar at the bottom of the latest mac dev release? It is not intentional, and is my fault – sorry. It will be gone again in next week's dev release. It was only active on trunk for a few hours, but this week's dev release was cut in that interval. If you see a bug filed for that, mark it as dupe of 19073 and write something like Bug 19073 landed prematurely and has been backed out. Unfortunately, the 211 build came from the tiny window when it was checked in. Nico -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Green Tree] Week 1
Hi chromium-dev, A small group of us joined forces to create a Green Tree task force. The goal of this task force is to make sure the tree stays green most of the time. The 2 main pain points that we are attacking at this time are reducing the buildbot cycle time, to catch errors earlier, and getting rid of the flakiness, to make sure the tree does not turn red for no reason. I'll be prepending [Green Tree] to the emails I send related to the task force. You can also follow the progress and our tasks there: http://code.google.com/p/chromium/issues/list?q=label:GreenTreeTaskForce For those interested, these are the highlights of the last week: - Make sure all the tasks have bugs associated with them (pamg) - Make sure VMWare Tools is installed on all the slaves (bev / nsylvain) - Disable all services that we don't need on the slaves (bev) - Split the windows chromium tests in 3 slaves (maruel) - Change the gatekeeper to close the tree on more failures (maruel) - Change LKGR to care about more tests, and make it cycle faster (maruel) - Write a status page to see the cycle speed on the slaves (nsylvain) - Make sure we build only what we need on Mac (thomasvl) - Add more try bots (linux views, valgrind) (maruel) - Refactor Linux Valgrind buildbots into builder/testers. (mmoss) - Create a dashboard to see the slowest tests (phajdan) - Speed up the transfer of builds between builders/testers by reducing the compression (mmoss) I'm sure I forgot some, feel free to append to this list. Despite our efforts, this was one of the worse week we've seen in a long time in term of tree closure. This was caused by 5 main events: - Buildbot maintenance went wrong. By changing a mounted drive on the buildbot master, the mount table got corrupted, and we had to reboot the main server. We started the maintenance at 7:30AM (pacific) and we got the buildbot back online shortly after 10AM. It had to cycle a little, so it was closed for almost 3 hours - A webkit merge left some failures in the tree. And it looks like everyone left without fixing it, so it was closed overnight. We fixed it in the morning, but before reopening we let another webkit merge go by, and it also broke the tree, requiring a change on webkit.org to fix the reliability tests (IIRC). Total closure time: 20 hours. - A bad gclient change got checked in. Some machines stopped running runhooks and some bots got confused. The damage seems to have been limited. - A second bad gclient change got checked in. This time causing all the bots to throw away their checkouts. Almost each slaves had to do a full checkout (which takes an hour or so), and some of them ran out of disk space, so we had to manually fix them. The tree was closed for another couple of hours. - A bad DEPS file got checked in. Causing again a bunch of slaves to throw away their checkout. It was closed for another hour or two. 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: Link error for KeystoneGlue on mac ui_tests?
It seems like it's coming from about_window_controller - I'm surprised that's being pulled in by worker_uitest.cc, though. I see some comments in the .gyp file around manually including keystone_glue, which is why I was wondering if I have to do something special for targets that need it. Just adding keystone_glue.h/m to the Mac sources for that target didn't do the trick. -atw On Sun, Sep 20, 2009 at 8:19 PM, Thomas Van Lenten thoma...@chromium.orgwrote: The unittest should be able to skip keystone, since it's part of the update system for official builds. Either we have a shim, or we're pulling in something we've been able to avoid in the past. TVL On Sun, Sep 20, 2009 at 12:47 PM, Drew Wilson atwil...@chromium.orgwrote: Hi all, I'm trying to fix up some of the worker layout tests. worker_uitests is currently disabled on the mac, and when I enable it in chrome.gyp (it's currently added to the !sources line for the mac version of ui_tests due to broken tests), I get the following link error: Undefined symbols: .objc_class_name_KeystoneGlue, referenced from: literal-poin...@__objc@__cls_r...@keystoneglue in libbrowser.a(about_window_controller.o) This used to work just fine before I synced with the recent chrome.gyp refactoring - anyone have any insights about this before I launch a painful hunt for missing dependencies? -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Starting Git Cookbook for chromium
I've started a little wiki to record useful git recipes that people use for developing chromium. http://code.google.com/p/chromium/wiki/GitCookbook Currently, it just has an entry for how to exclude files from a git-cl upload, while preserving them in another branch. If you have a useful recipe, or if you notice a question pop up on IRC multiple times, please add it to the page! The wiki is linked it off our For Developer Page. Happy gitting! -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: OSX cocoa_test_helper.mm and the like in browser.lib.
Why is cocoa_test_helper.mm listed in the browser library? This results in the class being linked into Google Chrome Framework (meaning it ships). Doesn't seem appropriate to me. This came up because I have some helper code I was listing in the unit_tests section of chrome.gyp. Since it's in browser/cocoa/, it will already be excluded from other platforms correctly. I was wondering about test_support_unit or test_support_common, but AFAICT since the file is in chrome/browser/, that would not be appropriate for my file. [cocoa_test_helper.mm doesn't have any dependencies w/in browser, that I can see, so it could maybe move there.] Any thoughts? -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: OSX cocoa_test_helper.mm and the like in browser.lib.
Remove it, see what happens? On Mon, Sep 21, 2009 at 12:47 PM, Scott Hess sh...@chromium.org wrote: Why is cocoa_test_helper.mm listed in the browser library? This results in the class being linked into Google Chrome Framework (meaning it ships). Doesn't seem appropriate to me. This came up because I have some helper code I was listing in the unit_tests section of chrome.gyp. Since it's in browser/cocoa/, it will already be excluded from other platforms correctly. I was wondering about test_support_unit or test_support_common, but AFAICT since the file is in chrome/browser/, that would not be appropriate for my file. [cocoa_test_helper.mm doesn't have any dependencies w/in browser, that I can see, so it could maybe move there.] Any thoughts? -scott -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] user feedback one month in
On Sun, Sep 20, 2009 at 10:56 PM, Joel Stanley j...@jms.id.au wrote: On Mon, Sep 21, 2009 at 15:02, Peter Kasting pkast...@chromium.org wrote: You're referring to crbug.com/406. This is a nasty bug, but it doesn't kick in until you're several megabytes into a resource, so I doubt it is the cause of the images partially load issue. I'd agree, I've been seeing the images issue for a while now. I opened http://crbug.com/22470 and added more (still vague) details. For those following at home, there's been a lot of bug hunting on http://code.google.com/p/chromium/issues/detail?id=22125 and some helpful users have narrowed down the regression window considerably. --~--~-~--~~~---~--~~ 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] user feedback one month in
On Sun, Sep 20, 2009 at 10:43 PM, Evan Martin e...@chromium.org wrote: - He's bookmarking by pasting urls into add page dialog found via the bookmark manager(!). Maybe he doesn't realize the star is the add bookmark button? My response: I'm no UI designer, but I wonder if it'd help to put the bookmark button star in some of the dialogs related to bookmarking? If you don't hover the star you'll never learn what it does; on the other hand, there are only seven buttons on the toolbar and I kind of don't have much pity for people who haven't looked at them. At least on Mac, in the bookmark menu/bar we use the generic globe favicon for sites that don't have their own icon. Perhaps we should switch this to be a star icon? That way there'd be a subtle suggestion to the user that star=bookmark. rsesek / @chromium.org --~--~-~--~~~---~--~~ 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] user feedback one month in
On Mon, Sep 21, 2009 at 10:20 AM, Robert Sesek rse...@chromium.org wrote: At least on Mac, in the bookmark menu/bar we use the generic globe favicon for sites that don't have their own icon. Perhaps we should switch this to be a star icon? That way there'd be a subtle suggestion to the user that star=bookmark. Ack, no. This would just look bizarre and broken. The star is normally an actionable item, and putting it on some bookmarked items but not others is confusing as heck. 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] Make CL summary prefix tags a formal convention?
It seems to be an informal convention amongst some Mac developers to prefix their changes with [Mac] in the CL subject line. This is extremely helpful for quickly picking out changes that only affect the single platform, especially if that information is not clear from the CL's description. I was wondering if we could formalize this convention across all three platforms, using [Windows], [Linux], and [Mac] when a change only affects a single platform? For bi-platform changes we could also use [Windows, Linux]. Thoughts? rsesek / @chromium.org --~--~-~--~~~---~--~~ 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] Week 1
On Mon, Sep 21, 2009 at 8:25 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hi chromium-dev, A small group of us joined forces to create a Green Tree task force. The goal of this task force is to make sure the tree stays green most of the time. The 2 main pain points that we are attacking at this time are reducing the buildbot cycle time, to catch errors earlier, and getting rid of the flakiness, to make sure the tree does not turn red for no reason. I'll be prepending [Green Tree] to the emails I send related to the task force. You can also follow the progress and our tasks there: http://code.google.com/p/chromium/issues/list?q=label:GreenTreeTaskForce For those interested, these are the highlights of the last week: - Make sure all the tasks have bugs associated with them (pamg) - Make sure VMWare Tools is installed on all the slaves (bev / nsylvain) - Disable all services that we don't need on the slaves (bev) - Split the windows chromium tests in 3 slaves (maruel) - Change the gatekeeper to close the tree on more failures (maruel) - Change LKGR to care about more tests, and make it cycle faster (maruel) - Write a status page to see the cycle speed on the slaves (nsylvain) - Make sure we build only what we need on Mac (thomasvl) - Add more try bots (linux views, valgrind) (maruel) - Refactor Linux Valgrind buildbots into builder/testers. (mmoss) - Create a dashboard to see the slowest tests (phajdan) - Speed up the transfer of builds between builders/testers by reducing the compression (mmoss) I'm sure I forgot some, feel free to append to this list. Despite our efforts, this was one of the worse week we've seen in a long time in term of tree closure. This was caused by 5 main events: - Buildbot maintenance went wrong. By changing a mounted drive on the buildbot master, the mount table got corrupted, and we had to reboot the main server. We started the maintenance at 7:30AM (pacific) and we got the buildbot back online shortly after 10AM. It had to cycle a little, so it was closed for almost 3 hours - A webkit merge left some failures in the tree. And it looks like everyone left without fixing it, so it was closed overnight. We fixed it in the morning, but before reopening we let another webkit merge go by, and it also broke the tree, requiring a change on webkit.org to fix the reliability tests (IIRC). Total closure time: 20 hours. The more try bots we get, the better this will get. At the very least, when we check in something that upsets bots covered by try bots, we can always roll back out and triage without the tree closed. Maybe we should have one try bot for each different type of build bot? Btw, in case anyone is wondering what makes WebKit gardening special: WebKit is a freight train that we can't stop. And so, if we get behind by even a day, it has a serious impact on Chromium developers' ability to do a lot of stuff (especially 2 sided patches). I'm not trying to condone the 20 hour closure (I don't know the details), but if we can't figure out what's wrong quickly (when it breaks our stuff) we can get into a pretty bad situation pretty quickly. - A bad gclient change got checked in. Some machines stopped running runhooks and some bots got confused. The damage seems to have been limited. - A second bad gclient change got checked in. This time causing all the bots to throw away their checkouts. Almost each slaves had to do a full checkout (which takes an hour or so), and some of them ran out of disk space, so we had to manually fix them. The tree was closed for another couple of hours. - A bad DEPS file got checked in. Causing again a bunch of slaves to throw away their checkout. It was closed for another hour or two. Possibly crazy idea: Is there any way we can have a bot that only updates itself that all the other bots block on? Assuming that one bot syncing the world is faster than all the bots saving the world, it would save time. It seems like in the normal case, this will go quite quickly and not block things for long. But, when something's wrong with gclient, DEPS, etc it'll take a long time. Sheriffs could then close the tree and stop that bot's build before any of the other bots pick it up. --~--~-~--~~~---~--~~ 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] user feedback one month in
On Mon, Sep 21, 2009 at 10:29 AM, Peter Kasting pkast...@google.com wrote: On Mon, Sep 21, 2009 at 10:20 AM, Robert Sesek rse...@chromium.org wrote: At least on Mac, in the bookmark menu/bar we use the generic globe favicon for sites that don't have their own icon. Perhaps we should switch this to be a star icon? That way there'd be a subtle suggestion to the user that star=bookmark. Ack, no. This would just look bizarre and broken. The star is normally an actionable item, and putting it on some bookmarked items but not others is confusing as heck. We put it on one folder in the bookmark manager. http://www.nirmaltv.com/2008/11/13/google-chrome-to-get-bookmark-manager/es/ That's what made me think of my suggestion. It's not unheard of to put icons within a form field to show relationships: http://www.flickr.com/photos/factoryjoe/320339624/in/set-72157600010029792/ To reiterate, though: I don't care too much about this nor do I imagine I'm the right person to design this. I was just suggesting something to hopefully prompt a better counterproposal. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] git users: please reconfigure git-cl
Please run git cl config http://src.chromium.org/svn/ It will autoconfigure itself. This will make it correctly amend codereviews with whether they've been committed or not. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] third-party C++ extensions for o3d
Hi All, We're having a conversation over on the o3d-discuss list about how to support third-party C++ extensions for o3d: http://groups.google.com/group/o3d-discuss/browse_thread/thread/6fee1142eafd08b1 Does anyone know if adding this capability is currently planned? 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] Q about closing valgrind issues
crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Q about closing valgrind issues
Could it possibly be related to passing a zero-sized rect in somewhere? On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote: crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Q about closing valgrind issues
I have no evidence to confirm/deny that. Even so it deserves an upstreaming. I'll look at it but why would it show up 1/30 times? Avi On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin e...@chromium.org wrote: Could it possibly be related to passing a zero-sized rect in somewhere? On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote: crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Q about closing valgrind issues
No idea! I was just suggesting that if it's possible to work around it, you'd have less memory getting stomped. :) On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman a...@google.com wrote: I have no evidence to confirm/deny that. Even so it deserves an upstreaming. I'll look at it but why would it show up 1/30 times? Avi On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin e...@chromium.org wrote: Could it possibly be related to passing a zero-sized rect in somewhere? On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman a...@google.com wrote: crbug.com/18189 crbug.com/18539 I got the first because it involved the status bubble; I got the second because I got the first. NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it sometimes scribbles off the end of some buffer. I have no idea what we could be doing wrong to cause it nor what we could be doing to affect it at all. I want to just dup one to the other and mark both as CANNOTFIXBADAPPLECODE^WWontFix. Any objections? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] user feedback one month in
On Sun, Sep 20, 2009 at 7:43 PM, Evan Martin e...@chromium.org wrote: It’s been a little over a month since I started using Chromium, the Open Source version of the Google Chrome Web browser. Since then, I’ve been using Chromium quite extensively. While the honeymoon isn’t over yet, I do have a better handle on what I like and dislike about Chromium and how it fits into my Web browsing and use of Web apps. http://scottnesbitt.net/ubuntublog/?p=511 Summary: Likes: speed, web compat(!), font rendering Unexpectedly ok with: lack of extensions Dislikes: - dropdown lists in wordpress admin panel don't behave well My response: any wordpress user here who can repro this? - CSS occasionally lost while browsing My response: I think I've seen this too, but I had been assuming it's site glitches. Does this ring any bells for anyone? - He's bookmarking by pasting urls into add page dialog found via the bookmark manager(!). Maybe he doesn't realize the star is the add bookmark button? My response: I'm no UI designer, but I wonder if it'd help to put the bookmark button star in some of the dialogs related to bookmarking? If you don't hover the star you'll never learn what it does; on the other hand, there are only seven buttons on the toolbar and I kind of don't have much pity for people who haven't looked at them. there are about 10,000 ways to bookmark a page: - drag web page link to bookmark bar - drag omnibox contents to bookmark bar - drag star button to bookmark bar - press star button - right click on bookmark bar, add page - go to bookmark manager, right click, add page - go to bookmark manager, organize menu, add page AFAIK these are basically the same as the options in firefox, which makes me wonder how he does it there. Maybe he expects Bookmark this page to be in the page menu? I have to say that bookmark this page in the page menu seems more logical than cut/copy/paste in that menu.[1] [1] cut/copy/paste in the page menu plain don't work on linux. See http://crbug.com/18030 for my explanation why. Yet I have never once seen a user notice this bug, much less complain about it (aside from our own QA tester). - splash page is annoying (estade removed it on Friday) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Shipping features behind a run-time flag can sometimes still be dangerous
I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. 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: third-party C++ extensions for o3d
http://code.google.com/p/nativeclient/ On Mon, Sep 21, 2009 at 12:44 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi All, We're having a conversation over on the o3d-discuss list about how to support third-party C++ extensions for o3d: http://groups.google.com/group/o3d-discuss/browse_thread/thread/6fee1142eafd08b1 Does anyone know if adding this capability is currently planned? 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: [linux] user feedback one month in
i never experienced images partially load issue, but i see it posted once in a while in crbug.com for example, http://crbug.com/15785 started as such and morphed into a different issue because the reporter couldn't provide real repro steps (at least that's the way i see it...) also there's http://crbug.com/20960 and some more --~--~-~--~~~---~--~~ 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: Shipping features behind a run-time flag can sometimes still be dangerous
That raises an excellent point! I would extend those compile time flags to include prevent experiments from getting into beta/stable as well. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. 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: Shipping features behind a run-time flag can sometimes still be dangerous
It is really useful to have early code compiling and running as much as possible on all platforms right from the beginning. This catches a lot of issues early in the development cycle and prevents scary monolithic integration phases. Could we also fix this problem by doing something in the bindings-generation phase to just not have these features' constructors created? - a On Mon, Sep 21, 2009 at 2:43 PM, Anthony LaForge lafo...@google.com wrote: That raises an excellent point! I would extend those compile time flags to include prevent experiments from getting into beta/stable as well. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread (https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript. I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. 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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. If it's behind a flag, it shouldn't have been exposed, right? On the surface, it sounds like this code was only partially hidden behind the flag? I think it would be a good idea to have a unit test which enumerates all symbols that we're exposing into JS. This should be a controlled list. If we had this unit test, would it have caught this exposure? Mike 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. 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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 2:47 PM, Aaron Boodman a...@chromium.org wrote: It is really useful to have early code compiling and running as much as possible on all platforms right from the beginning. This catches a lot of issues early in the development cycle and prevents scary monolithic integration phases. Even in beta/stable releases? If people want to test bleeding edge features, I'd argue they should be on the dev channel. Could we also fix this problem by doing something in the bindings-generation phase to just not have these features' constructors created? Possibly. It's still possible that it'd have a non-trivial maintenance and/or performance cost though. I believe Drew is going to explore further, but for now (and Chrome 3) we should assume such an option is not available. On Mon, Sep 21, 2009 at 2:52 PM, Mike Belshe mbel...@google.com wrote: On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. If it's behind a flag, it shouldn't have been exposed, right? As I explained, this is not true. On the surface, it sounds like this code was only partially hidden behind the flag? Yes. I think it would be a good idea to have a unit test which enumerates all symbols that we're exposing into JS. This should be a controlled list. If we had this unit test, would it have caught this exposure? Yes. The point is that (pending Drew's investigation) it's probably not practical to completely hide all side effects of run time flags that turn on JavaScript features in WebKit. 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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Sep 21, 2009 at 2:47 PM, Aaron Boodman a...@chromium.org wrote: It is really useful to have early code compiling and running as much as possible on all platforms right from the beginning. This catches a lot of issues early in the development cycle and prevents scary monolithic integration phases. Even in beta/stable releases? If people want to test bleeding edge features, I'd argue they should be on the dev channel. Could we also fix this problem by doing something in the bindings-generation phase to just not have these features' constructors created? Possibly. It's still possible that it'd have a non-trivial maintenance and/or performance cost though. I believe Drew is going to explore further, but for now (and Chrome 3) we should assume such an option is not available. On Mon, Sep 21, 2009 at 2:52 PM, Mike Belshe mbel...@google.com wrote: On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.orgwrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. If it's behind a flag, it shouldn't have been exposed, right? As I explained, this is not true. Oops...misread your statement. Ignore that commentor assume I said As I explained, this is currently not true. On the surface, it sounds like this code was only partially hidden behind the flag? Yes. I think it would be a good idea to have a unit test which enumerates all symbols that we're exposing into JS. This should be a controlled list. This probably makes sense. If we had this unit test, would it have caught this exposure? Yes. The point is that (pending Drew's investigation) it's probably not practical to completely hide all side effects of run time flags that turn on JavaScript features in WebKit. 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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* Having features enabled behind command line flag has been very helpful in tracking down bugs and getting the wider population to test something. It's also useful when debugging on someone's machine. It sounds like the problem is how we're keying off the run time flag (i.e. not in the bindings). When I looked at the database bindings, there was no way to both use the automatically generated constructor and not have side effects. I think it's worth the tradeoff to make it custom in the meantime. I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. 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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek j...@chromium.org wrote: On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* Having features enabled behind command line flag has been very helpful in tracking down bugs and getting the wider population to test something. It's also useful when debugging on someone's machine. Which features/flags (with side effects in JavaScript) have you found helpful when debugging *stable/beta* versions? Which of those were helpful in stable versions? It sounds like the problem is how we're keying off the run time flag (i.e. not in the bindings). No, the problem is the bindings. We'd need to add more logic to them to handle these cases. When I looked at the database bindings, there was no way to both use the automatically generated constructor and not have side effects. Exactly. And so the alternative is to add custom bindings or to change the code generator. Both have a price in terms of development, performance, and maintenance. As I said, I believe Drew is going to explore this when he enables shared workers behind a flag. I think it's worth the tradeoff to make it custom in the meantime. Please reply to https://lists.webkit.org/pipermail/webkit-dev/2009-September/009995.htmlthen. Whether or not we make these run time flags have no side-effects in the future, there's still the matter of what we should do for Chrome 3 since adding in custom getters and such seems like a very high risk for little reward. 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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek j...@chromium.orgwrote: On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.orgwrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* Having features enabled behind command line flag has been very helpful in tracking down bugs and getting the wider population to test something. It's also useful when debugging on someone's machine. Which features/flags (with side effects in JavaScript) have you found helpful when debugging *stable/beta* versions? Which of those were helpful in stable versions? Things like dev tools, OOP, new safe browsing, different memory models and allocators, no activex, disabling plugins/javascript are what comes to my mind. Not just for debugging, but also for using them, and for having users with problems try them out to see if it fixes them. As Chrome is maturing as a browser, feature development will move from infrastructure to web features, which is why the list is biased to the former, but the same benefits still exist. There is also cost of maintaining different dev/beta/stable and Chrome/Chromium releases, in terms of testing, release processes, user confusion etc. It sounds like the problem is how we're keying off the run time flag (i.e. not in the bindings). No, the problem is the bindings. We'd need to add more logic to them to handle these cases. oops, I meant in the bindings, hence my statement below :) When I looked at the database bindings, there was no way to both use the automatically generated constructor and not have side effects. Exactly. And so the alternative is to add custom bindings or to change the code generator. Both have a price in terms of development, performance, and maintenance. As I said, I believe Drew is going to explore this when he enables shared workers behind a flag. I think it's worth the tradeoff to make it custom in the meantime. Please reply to https://lists.webkit.org/pipermail/webkit-dev/2009-September/009995.htmlthen. What's wrong with this thread? We're discussing what to do in Chrome. Whether or not we make these run time flags have no side-effects in the future, there's still the matter of what we should do for Chrome 3 since adding in custom getters and such seems like a very high risk for little reward. Really? Why is it very high risk? 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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 3:51 PM, John Abd-El-Malek j...@chromium.org wrote: On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek j...@chromium.orgwrote: On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.orgwrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* Having features enabled behind command line flag has been very helpful in tracking down bugs and getting the wider population to test something. It's also useful when debugging on someone's machine. Which features/flags (with side effects in JavaScript) have you found helpful when debugging *stable/beta* versions? Which of those were helpful in stable versions? Things like dev tools, OOP, new safe browsing, different memory models and allocators, no activex, disabling plugins/javascript are what comes to my mind. Not just for debugging, but also for using them, and for having users with problems try them out to see if it fixes them. As Chrome is maturing as a browser, feature development will move from infrastructure to web features, which is why the list is biased to the former, but the same benefits still exist. Sorry, I meant to say with side effects in JavaScript even when not enabled. Do any on that list still apply? There is also cost of maintaining different dev/beta/stable and Chrome/Chromium releases, in terms of testing, release processes, user confusion etc. The maintenance should only be a difference in compile time flags and which tests get run, but I do agree that there's a cost to this approach as well. It sounds like the problem is how we're keying off the run time flag (i.e. not in the bindings). No, the problem is the bindings. We'd need to add more logic to them to handle these cases. oops, I meant in the bindings, hence my statement below :) When I looked at the database bindings, there was no way to both use the automatically generated constructor and not have side effects. Exactly. And so the alternative is to add custom bindings or to change the code generator. Both have a price in terms of development, performance, and maintenance. As I said, I believe Drew is going to explore this when he enables shared workers behind a flag. I think it's worth the tradeoff to make it custom in the meantime. Please reply to https://lists.webkit.org/pipermail/webkit-dev/2009-September/009995.htmlthen. What's wrong with this thread? We're discussing what to do in Chrome. What we do in Chrome affects WebKit in terms of performance and maintenance. This is why the thread existed to begin with. Any decision that we make that affects the rest of the ports should be discussed there unless it's obviously the right thing to do for them. (Which this isn't.) Whether or not we make these run time flags have no side-effects in the future, there's still the matter of what we should do for Chrome 3 since adding in custom getters and such seems like a very high risk for little reward. Really? Why is it very high risk? I'm pretty sure it'll be a non-trivial amount of code vs. just compiling out code that should be dead anyway. --~--~-~--~~~---~--~~ 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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 3:59 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Sep 21, 2009 at 3:51 PM, John Abd-El-Malek j...@chromium.orgwrote: On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow jor...@chromium.orgwrote: On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek j...@chromium.orgwrote: On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.orgwrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* Having features enabled behind command line flag has been very helpful in tracking down bugs and getting the wider population to test something. It's also useful when debugging on someone's machine. Which features/flags (with side effects in JavaScript) have you found helpful when debugging *stable/beta* versions? Which of those were helpful in stable versions? Things like dev tools, OOP, new safe browsing, different memory models and allocators, no activex, disabling plugins/javascript are what comes to my mind. Not just for debugging, but also for using them, and for having users with problems try them out to see if it fixes them. As Chrome is maturing as a browser, feature development will move from infrastructure to web features, which is why the list is biased to the former, but the same benefits still exist. Sorry, I meant to say with side effects in JavaScript even when not enabled. Do any on that list still apply? I don't think anyone is arguing that side-effects in JS are ok. There is also cost of maintaining different dev/beta/stable and Chrome/Chromium releases, in terms of testing, release processes, user confusion etc. The maintenance should only be a difference in compile time flags and which tests get run, but I do agree that there's a cost to this approach as well. There are also manual tests. The same binary can't be reused, so a new build will have to be made which means every test that was run before has to be run again (say there was corruption in the second build). We can't just promote one build from a channel to another, etc. You can talk to Mark or others to see how much time the release processes already take. It sounds like the problem is how we're keying off the run time flag (i.e. not in the bindings). No, the problem is the bindings. We'd need to add more logic to them to handle these cases. oops, I meant in the bindings, hence my statement below :) When I looked at the database bindings, there was no way to both use the automatically generated constructor and not have side effects. Exactly. And so the alternative is to add custom bindings or to change the code generator. Both have a price in terms of development, performance, and maintenance. As I said, I believe Drew is going to explore this when he enables shared workers behind a flag. I think it's worth the tradeoff to make it custom in the meantime. Please reply to https://lists.webkit.org/pipermail/webkit-dev/2009-September/009995.htmlthen. What's wrong with this thread? We're discussing what to do in Chrome. What we do in Chrome affects WebKit in terms of performance and maintenance. This is why the thread existed to begin with. Any decision that we make that affects the rest of the ports should be discussed there unless it's obviously the right thing to do for them. (Which this isn't.) Chrome has very different requirements than other products that use WebKit. Our dev/beta/stable channel approach means we can move
[chromium-dev] Re: Shipping features behind a run-time flag can sometimes still be dangerous
I agree. Our practice of releasing experimental features default disabled behinda command line flag is extremely valuable. We should make sure that this works well for new web APIs. It will continue to be a valuable tool down the road. It is important that we have features available in stable, beta, and dev channels this way. Otherwise, what we ship to stable is not the same build configuration as what we ship to beta, and that can cause even more problems. -Darin On Mon, Sep 21, 2009 at 2:47 PM, Aaron Boodman a...@chromium.org wrote: It is really useful to have early code compiling and running as much as possible on all platforms right from the beginning. This catches a lot of issues early in the development cycle and prevents scary monolithic integration phases. Could we also fix this problem by doing something in the bindings-generation phase to just not have these features' constructors created? - a On Mon, Sep 21, 2009 at 2:43 PM, Anthony LaForge lafo...@google.com wrote: That raises an excellent point! I would extend those compile time flags to include prevent experiments from getting into beta/stable as well. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860 ) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript. I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. 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: third-party C++ extensions for o3d
Very cool! I'll check it out :-) On Mon, Sep 21, 2009 at 5:39 PM, Erik Kay erik...@chromium.org wrote: http://code.google.com/p/nativeclient/ On Mon, Sep 21, 2009 at 12:44 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi All, We're having a conversation over on the o3d-discuss list about how to support third-party C++ extensions for o3d: http://groups.google.com/group/o3d-discuss/browse_thread/thread/6fee1142eafd08b1 Does anyone know if adding this capability is currently planned? 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: git users: please reconfigure git-cl
On Mon, Sep 21, 2009 at 12:27 PM, Evan Martin e...@chromium.org wrote: Please run git cl config http://src.chromium.org/svn/ It will autoconfigure itself. This will make it correctly amend codereviews with whether they've been committed or not. BTW, this command just loads $url + '/codereview.settings' and sets up your settings based on that. http://src.chromium.org/svn/codereview.settings --~--~-~--~~~---~--~~ 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: Shipping features behind a run-time flag can sometimes still be dangerous
All right. I'm not 100% convinced, but either way I think we need to understand better how to remove these features' side-effects from JavaScript when disabled. Mads (or anyone else) can you provide any thoughts on how we can implement the following in our bindings generator? (1) We need to be able to disable the JavaScript constructor easily. (2) We need to be able to say C++ NULLs -- JavaScript undefineds. I believe this is fairly easy? (3) We need to be able to manipulate at run-time whether a property should be enumerated. We'd need to do this on at least Window. I assume there are others. On Mon, Sep 21, 2009 at 4:37 PM, Darin Fisher da...@chromium.org wrote: I agree. Our practice of releasing experimental features default disabled behinda command line flag is extremely valuable. We should make sure that this works well for new web APIs. It will continue to be a valuable tool down the road. It is important that we have features available in stable, beta, and dev channels this way. Otherwise, what we ship to stable is not the same build configuration as what we ship to beta, and that can cause even more problems. -Darin On Mon, Sep 21, 2009 at 4:23 PM, John Abd-El-Malek j...@chromium.org wrote: On Mon, Sep 21, 2009 at 3:59 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Sep 21, 2009 at 3:51 PM, John Abd-El-Malek j...@chromium.org wrote: On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow jor...@chromium.org wrote: Please reply to https://lists.webkit.org/pipermail/webkit-dev/2009-September/009995.html then. What's wrong with this thread? We're discussing what to do in Chrome. What we do in Chrome affects WebKit in terms of performance and maintenance. This is why the thread existed to begin with. Any decision that we make that affects the rest of the ports should be discussed there unless it's obviously the right thing to do for them. (Which this isn't.) Chrome has very different requirements than other products that use WebKit. Our dev/beta/stable channel approach means we can move fast, but more differences between these builds pushes us the other direction. This is mostly just a PSA: If we can find ways to solve these problems 100% transparently to everyone else, then sure. But if not, then we need to discuss it on WebKit-dev. Adding run-time flags does affect others, which is why that WebKit-dev thread was started. I guess adding custom functions to the v8 bindings doesn't affect others much (since we're the only port using v8), but I want to be sure that we're conscious of when our decisions have an impact on the rest of the WebKit community and that we bring things up on WebKit-dev when it does. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Fwd: [chromium-dev] Shipping features behind a run-time flag can sometimes still be dangerous
Ooops, sorry. Got bit by reply vs reply-all. See my notes below regarding implementation details. -atw -- Forwarded message -- From: Drew Wilson atwil...@google.com Date: Mon, Sep 21, 2009 at 5:03 PM Subject: Re: [chromium-dev] Shipping features behind a run-time flag can sometimes still be dangerous To: Mike Belshe mbel...@google.com On Mon, Sep 21, 2009 at 2:52 PM, Mike Belshe mbel...@google.com wrote: On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. If it's behind a flag, it shouldn't have been exposed, right? On the surface, it sounds like this code was only partially hidden behind the flag? I think it would be a good idea to have a unit test which enumerates all symbols that we're exposing into JS. This should be a controlled list. If we had this unit test, would it have caught this exposure? I believe this test exists (fast/dom/Window/window-properties.html). I suspect the problem is that people aren't zealously reviewing its contents to check for leaks. Anyhow, it's trivial to change the code generator for a given attribute to map null to undefined, which is what I was planning to do for SharedWorkers. It's somewhat trickier to generate code to enable/disable constructors since there's probably not a common way to tell if a given constructor should be enabled or not (probably simpler just to make the constructor-getter v8-custom, and have custom code to return undefined). Likewise, looks like there's a DontEnum flag we can set on the various prototype table values to hide them from for...in - the trick is how to initialize these tables appropriately (and in a thread-safe way), given that they are statically defined. Disabling enumeration seems like quite a bit of work for not much benefit so I'd push back on doing anything there. I'd say that if we want to hide constructors, we should do it via custom bindings rather than trying to build some general solution since you'd likely need a custom see if feature X is enabled code block anyway. Mike 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. 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: [Green Tree] Week 1
Of the three slowest tests as of last week, two has been fixed (thanks to evan and jcampan) and the third one has a fix being reviewed. The Linux trybots build almost as fast as the Mac trybots now, thanks to shared ccache with a ~80% cache hit rate. Windows trybots are still struggling - taking 3X as long to build vs. Linux/Mac. On Mon, Sep 21, 2009 at 8:25 AM, Nicolas Sylvain nsylv...@chromium.org wrote: Hi chromium-dev, A small group of us joined forces to create a Green Tree task force. The goal of this task force is to make sure the tree stays green most of the time. The 2 main pain points that we are attacking at this time are reducing the buildbot cycle time, to catch errors earlier, and getting rid of the flakiness, to make sure the tree does not turn red for no reason. I'll be prepending [Green Tree] to the emails I send related to the task force. You can also follow the progress and our tasks there: http://code.google.com/p/chromium/issues/list?q=label:GreenTreeTaskForce For those interested, these are the highlights of the last week: - Make sure all the tasks have bugs associated with them (pamg) - Make sure VMWare Tools is installed on all the slaves (bev / nsylvain) - Disable all services that we don't need on the slaves (bev) - Split the windows chromium tests in 3 slaves (maruel) - Change the gatekeeper to close the tree on more failures (maruel) - Change LKGR to care about more tests, and make it cycle faster (maruel) - Write a status page to see the cycle speed on the slaves (nsylvain) - Make sure we build only what we need on Mac (thomasvl) - Add more try bots (linux views, valgrind) (maruel) - Refactor Linux Valgrind buildbots into builder/testers. (mmoss) - Create a dashboard to see the slowest tests (phajdan) - Speed up the transfer of builds between builders/testers by reducing the compression (mmoss) I'm sure I forgot some, feel free to append to this list. Despite our efforts, this was one of the worse week we've seen in a long time in term of tree closure. This was caused by 5 main events: - Buildbot maintenance went wrong. By changing a mounted drive on the buildbot master, the mount table got corrupted, and we had to reboot the main server. We started the maintenance at 7:30AM (pacific) and we got the buildbot back online shortly after 10AM. It had to cycle a little, so it was closed for almost 3 hours - A webkit merge left some failures in the tree. And it looks like everyone left without fixing it, so it was closed overnight. We fixed it in the morning, but before reopening we let another webkit merge go by, and it also broke the tree, requiring a change on webkit.org to fix the reliability tests (IIRC). Total closure time: 20 hours. - A bad gclient change got checked in. Some machines stopped running runhooks and some bots got confused. The damage seems to have been limited. - A second bad gclient change got checked in. This time causing all the bots to throw away their checkouts. Almost each slaves had to do a full checkout (which takes an hour or so), and some of them ran out of disk space, so we had to manually fix them. The tree was closed for another couple of hours. - A bad DEPS file got checked in. Causing again a bunch of slaves to throw away their checkout. It was closed for another hour or two. 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: [Green Tree] Week 1
On Mon, Sep 21, 2009 at 6:24 PM, Lei Zhang thes...@chromium.org wrote: Of the three slowest tests as of last week, two has been fixed (thanks to evan and jcampan) and the third one has a fix being reviewed. The Linux trybots build almost as fast as the Mac trybots now, thanks to shared ccache with a ~80% cache hit rate. Windows trybots are still struggling - taking 3X as long to build vs. Linux/Mac. We finally figured out how to give 4 cpus to the windows try bots instead of 2. This should add a little bit of speed up! Bev is working on this. Nicolas On Mon, Sep 21, 2009 at 8:25 AM, Nicolas Sylvain nsylv...@chromium.org wrote: Hi chromium-dev, A small group of us joined forces to create a Green Tree task force. The goal of this task force is to make sure the tree stays green most of the time. The 2 main pain points that we are attacking at this time are reducing the buildbot cycle time, to catch errors earlier, and getting rid of the flakiness, to make sure the tree does not turn red for no reason. I'll be prepending [Green Tree] to the emails I send related to the task force. You can also follow the progress and our tasks there: http://code.google.com/p/chromium/issues/list?q=label:GreenTreeTaskForce For those interested, these are the highlights of the last week: - Make sure all the tasks have bugs associated with them (pamg) - Make sure VMWare Tools is installed on all the slaves (bev / nsylvain) - Disable all services that we don't need on the slaves (bev) - Split the windows chromium tests in 3 slaves (maruel) - Change the gatekeeper to close the tree on more failures (maruel) - Change LKGR to care about more tests, and make it cycle faster (maruel) - Write a status page to see the cycle speed on the slaves (nsylvain) - Make sure we build only what we need on Mac (thomasvl) - Add more try bots (linux views, valgrind) (maruel) - Refactor Linux Valgrind buildbots into builder/testers. (mmoss) - Create a dashboard to see the slowest tests (phajdan) - Speed up the transfer of builds between builders/testers by reducing the compression (mmoss) I'm sure I forgot some, feel free to append to this list. Despite our efforts, this was one of the worse week we've seen in a long time in term of tree closure. This was caused by 5 main events: - Buildbot maintenance went wrong. By changing a mounted drive on the buildbot master, the mount table got corrupted, and we had to reboot the main server. We started the maintenance at 7:30AM (pacific) and we got the buildbot back online shortly after 10AM. It had to cycle a little, so it was closed for almost 3 hours - A webkit merge left some failures in the tree. And it looks like everyone left without fixing it, so it was closed overnight. We fixed it in the morning, but before reopening we let another webkit merge go by, and it also broke the tree, requiring a change on webkit.org to fix the reliability tests (IIRC). Total closure time: 20 hours. - A bad gclient change got checked in. Some machines stopped running runhooks and some bots got confused. The damage seems to have been limited. - A second bad gclient change got checked in. This time causing all the bots to throw away their checkouts. Almost each slaves had to do a full checkout (which takes an hour or so), and some of them ran out of disk space, so we had to manually fix them. The tree was closed for another couple of hours. - A bad DEPS file got checked in. Causing again a bunch of slaves to throw away their checkout. It was closed for another hour or two. 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: Make CL summary prefix tags a formal convention?
Some subset of the team uses the de-facto standard of area: one-liner
description seen in projects like the kernel.
% git log --pretty=format:'%an %s' | sed -nre 's/^(\w+)@chromium.org
(.{,20}: .*)$/* \1 \2/p'
* pfeldman DevTools: Get rid of utility functions and
ExecuteUtilityFunction as a whole. Eliminates the need in double-JSON
of InjectedScript-related functions.
* evan linux: implement GetCPUUsage() so the task manager shows CPU
* estade GTK: Download item as drag source.
* estade GTK: Add a bunch more widget names for parasite.
* mdm Linux: avoid browser windows moving around by the size of WM
decorations over restart. Use a debounce timer to get the true window
position shortly after the last reconfigure event is delivered, and
save that. BUG=18771 TEST=none
* estade GTK: Get rid of default drag icon for tab drags.
* evan linux: expose the ProcessSingleton timeout to speed tests
* evan linux: add names to some widgets for parasite's benefit
* estade GTK: Don't put a blank line in the tooltip for nameless
bookmark bar bookmarks.
* agl Windows: Warn about outdated plugins.
* estade GTK: Add a dialog for printing.
* agl Build fix: vim wrapped the line
* jhawkins valgrind: memset the window command data structure.
|timestamp| is aligned on a 16 byte boundary leaving 4 bytes of
uninitialized data in the middle of the struct. We write this data to
disk, which is a possible security risk.
* evan posix: clean up shared memory code
* estade Linux: print page to file rather than using shared memory to
send it to the browser.
* agl Linux: remove tcmalloc from build/all.gyp
On Mon, Sep 21, 2009 at 10:35 AM, Robert Sesek rse...@chromium.org wrote:
It seems to be an informal convention amongst some Mac developers to prefix
their changes with [Mac] in the CL subject line. This is extremely helpful
for quickly picking out changes that only affect the single platform,
especially if that information is not clear from the CL's description. I was
wondering if we could formalize this convention across all three platforms,
using [Windows], [Linux], and [Mac] when a change only affects a single
platform? For bi-platform changes we could also use [Windows, Linux].
Thoughts?
rsesek / @chromium.org
--~--~-~--~~~---~--~~
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: Shipping features behind a run-time flag can sometimes still be dangerous
On Mon, Sep 21, 2009 at 5:41 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Sep 21, 2009 at 5:32 PM, Drew Wilson atwil...@chromium.orgwrote: Ooops, sorry. Got bit by reply vs reply-all. See my notes below regarding implementation details. -atw -- Forwarded message -- From: Drew Wilson atwil...@google.com Date: Mon, Sep 21, 2009 at 5:03 PM Subject: Re: [chromium-dev] Shipping features behind a run-time flag can sometimes still be dangerous To: Mike Belshe mbel...@google.com On Mon, Sep 21, 2009 at 2:52 PM, Mike Belshe mbel...@google.com wrote: On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.orgwrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. If it's behind a flag, it shouldn't have been exposed, right? On the surface, it sounds like this code was only partially hidden behind the flag? I think it would be a good idea to have a unit test which enumerates all symbols that we're exposing into JS. This should be a controlled list. If we had this unit test, would it have caught this exposure? I believe this test exists (fast/dom/Window/window-properties.html). I suspect the problem is that people aren't zealously reviewing its contents to check for leaks. Anyhow, it's trivial to change the code generator for a given attribute to map null to undefined, which is what I was planning to do for SharedWorkers. It's somewhat trickier to generate code to enable/disable constructors since there's probably not a common way to tell if a given constructor should be enabled or not (probably simpler just to make the constructor-getter v8-custom, and have custom code to return undefined). Likewise, looks like there's a DontEnum flag we can set on the various prototype table values to hide them from for...in - the trick is how to initialize these tables appropriately (and in a thread-safe way), given that they are statically defined. Disabling enumeration seems like quite a bit of work for not much benefit so I'd push back on doing anything there. I'd say that if we want to hide constructors, we should do it via custom bindings rather than trying to build some general solution since you'd likely need a custom see if feature X is enabled code block anyway. I really hate adding yet more custom code. There are already sooo many steps to adding a feature bindings wise. And it'll be very easy for people to screw it up. I guess tests can help, though... Also, I'm not sure I agree that side-effects in enumeration is OK if we're shipping this stuff in stable. This will bite us at some point or another. If we were leaving things in experimental state for long periods of time, then sure. But given that typically things hang out in experimental for no more than a quarter or two (typically for a web feature that isn't widely deployed on other browsers yet either) and people generally don't use enumeration for capabilities testing, I suspect we'll never run into any problems with it. That said, I certainly would not discourage people from submitting patches to address this - it just seems like a bunch of work for something that's unlikely to cause compatibility problems in practice, so I wasn't planning to do anything in that area. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. *As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript.* I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next
[chromium-dev] Re: Shipping features behind a run-time flag can sometimes still be dangerous
Indeed. BTW I filed http://crbug.com/18577 so it'd be easier to find (and copy-paste) the command line flags used for a build. We can add this to the default template if it'd be useful. -Ben On Mon, Sep 21, 2009 at 4:37 PM, Darin Fisher da...@chromium.org wrote: I agree. Our practice of releasing experimental features default disabled behinda command line flag is extremely valuable. We should make sure that this works well for new web APIs. It will continue to be a valuable tool down the road. It is important that we have features available in stable, beta, and dev channels this way. Otherwise, what we ship to stable is not the same build configuration as what we ship to beta, and that can cause even more problems. -Darin On Mon, Sep 21, 2009 at 2:47 PM, Aaron Boodman a...@chromium.org wrote: It is really useful to have early code compiling and running as much as possible on all platforms right from the beginning. This catches a lot of issues early in the development cycle and prevents scary monolithic integration phases. Could we also fix this problem by doing something in the bindings-generation phase to just not have these features' constructors created? - a On Mon, Sep 21, 2009 at 2:43 PM, Anthony LaForge lafo...@google.com wrote: That raises an excellent point! I would extend those compile time flags to include prevent experiments from getting into beta/stable as well. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread ( https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860 ) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript. I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. 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: svn --depth not recognized?
It's only available in 1.5+. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Sep 21, 2009 at 9:03 PM, Drew Wilson atwil...@chromium.org wrote: Hi all, I'm trying to do a gcl try on my mac, but getting this error: svn checkout --depth empty svn://svn.chromium.org/chrome-try/try/var/folders/zz/zzzivhrRnAmviuee++2D3++-1lE/-Tmp-/tmpMRXSrL --username atwil...@google.com Ouput: svn: invalid option: --depth Type 'svn help' for usage. Sorry, Tryserver is not available. My macbook comes with SVN 1.4.4 - do we require a newer version (I didn't see anything about that on dev.chromium.org). I've been able to do gcl try in the past with no problems, so I'm not sure what's suddenly going wrong now... Any tips for me? I'd prefer not to upgrade SVN unless I know it's necessary, since I don't know if/how it'd affect my webkit development. -atw --~--~-~--~~~---~--~~ 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: svn --depth not recognized?
Drew Wilson wrote: I'm trying to do a gcl try on my mac, but getting this error: svn checkout --depth empty svn://svn.chromium.org/chrome-try/try /var/folders/zz/zzzivhrRnAmviuee++2D3++-1lE/-Tmp-/tmpMRXSrL --username atwil...@google.com Ouput: svn: invalid option: --depth Type 'svn help' for usage. Sorry, Tryserver is not available. My macbook comes with SVN 1.4.4 - do we require a newer version (I didn't see anything about that on dev.chromium.org). I've been able to do gcl try in the past with no problems, so I'm not sure what's suddenly going wrong now... Any tips for me? I'd prefer not to upgrade SVN unless I know it's necessary, since I don't know if/how it'd affect my webkit development. Apparently, gcl try over svn requires svn 1.5. gcl try also works over http. In fact, I think http is the default - but only if you can see the try http server. You may not be able to. The try svn server is more accessible. According to gcl help try, --use_http, --host, --port, and --proxy can be used to control access over HTTP. We don't require svn 1.5 in most cases, we want our tools to be compatible with the svn that most people are using, which on Leopard systems is 1.4. I'm not sure if it would be easy to make try server svn access work without --depth. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] svn --depth not recognized?
Hi all, I'm trying to do a gcl try on my mac, but getting this error: svn checkout --depth empty svn://svn.chromium.org/chrome-try/try/var/folders/zz/zzzivhrRnAmviuee++2D3++-1lE/-Tmp-/tmpMRXSrL --username atwil...@google.com Ouput: svn: invalid option: --depth Type 'svn help' for usage. Sorry, Tryserver is not available. My macbook comes with SVN 1.4.4 - do we require a newer version (I didn't see anything about that on dev.chromium.org). I've been able to do gcl try in the past with no problems, so I'm not sure what's suddenly going wrong now... Any tips for me? I'd prefer not to upgrade SVN unless I know it's necessary, since I don't know if/how it'd affect my webkit development. -atw --~--~-~--~~~---~--~~ 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: svn --depth not recognized?
No comment on 1.4 compatibility goals. :) I would bet most developers would want to upgrade to 1.6 for all the speed improvements. Official package: http://www.open.collab.net/downloads/community/ (Which installs it in the strange place of /opt/subversion/bin.) -eric On Mon, Sep 21, 2009 at 9:12 PM, Mark Mentovai m...@chromium.org wrote: Drew Wilson wrote: I'm trying to do a gcl try on my mac, but getting this error: svn checkout --depth empty svn://svn.chromium.org/chrome-try/try /var/folders/zz/zzzivhrRnAmviuee++2D3++-1lE/-Tmp-/tmpMRXSrL --username atwil...@google.com Ouput: svn: invalid option: --depth Type 'svn help' for usage. Sorry, Tryserver is not available. My macbook comes with SVN 1.4.4 - do we require a newer version (I didn't see anything about that on dev.chromium.org). I've been able to do gcl try in the past with no problems, so I'm not sure what's suddenly going wrong now... Any tips for me? I'd prefer not to upgrade SVN unless I know it's necessary, since I don't know if/how it'd affect my webkit development. Apparently, gcl try over svn requires svn 1.5. gcl try also works over http. In fact, I think http is the default - but only if you can see the try http server. You may not be able to. The try svn server is more accessible. According to gcl help try, --use_http, --host, --port, and --proxy can be used to control access over HTTP. We don't require svn 1.5 in most cases, we want our tools to be compatible with the svn that most people are using, which on Leopard systems is 1.4. I'm not sure if it would be easy to make try server svn access work without --depth. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: svn --depth not recognized?
Thanks, updating my svn version and updating my EMAIL_ADDRESS setting (so it uses the proper acct for svn access) did the trick. -atw On Mon, Sep 21, 2009 at 9:18 PM, Eric Seidel esei...@chromium.org wrote: No comment on 1.4 compatibility goals. :) I would bet most developers would want to upgrade to 1.6 for all the speed improvements. Official package: http://www.open.collab.net/downloads/community/ (Which installs it in the strange place of /opt/subversion/bin.) -eric On Mon, Sep 21, 2009 at 9:12 PM, Mark Mentovai m...@chromium.org wrote: Drew Wilson wrote: I'm trying to do a gcl try on my mac, but getting this error: svn checkout --depth empty svn://svn.chromium.org/chrome-try/try /var/folders/zz/zzzivhrRnAmviuee++2D3++-1lE/-Tmp-/tmpMRXSrL --username atwil...@google.com Ouput: svn: invalid option: --depth Type 'svn help' for usage. Sorry, Tryserver is not available. My macbook comes with SVN 1.4.4 - do we require a newer version (I didn't see anything about that on dev.chromium.org). I've been able to do gcl try in the past with no problems, so I'm not sure what's suddenly going wrong now... Any tips for me? I'd prefer not to upgrade SVN unless I know it's necessary, since I don't know if/how it'd affect my webkit development. Apparently, gcl try over svn requires svn 1.5. gcl try also works over http. In fact, I think http is the default - but only if you can see the try http server. You may not be able to. The try svn server is more accessible. According to gcl help try, --use_http, --host, --port, and --proxy can be used to control access over HTTP. We don't require svn 1.5 in most cases, we want our tools to be compatible with the svn that most people are using, which on Leopard systems is 1.4. I'm not sure if it would be easy to make try server svn access work without --depth. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
