I wonder... should we show an infobar on startup when the sandbox is disabled?
On Thu, Dec 10, 2009 at 21:38, John Abd-El-Malek <[email protected]> wrote: > 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 > -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
