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