We disable --single-process and --in-process-plugins on release Google Chrome builds to avoid the support headache that it causes. I think we should do the same for --no-sandbox.
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? > > -Darin > > -- > Chromium Developers mailing list: [email protected] > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
