On Wed, Dec 30, 2009 at 3:43 PM, Peter Kasting pkast...@google.com wrote:
On Wed, Dec 30, 2009 at 3:22 PM, Jeremy Orlow jor...@google.com wrote:
I just got back from vacation and would like to take action on this. I
read through the thread, but I don't see any sort of consensus on what to
On Wed, Dec 30, 2009 at 3:56 PM, Jeremy Orlow jor...@google.com wrote:
2) Info bar. This seems like one of the more popular options at the
moment.
This is a bad idea, we shouldn't do it. It's not as annoying as a modal
dialog, it has problems with clashing with other infobars on start.
I thought there were two separate issues here:
1.) The specific webgl switch. Darin suggested that it should imply
--disable-sandbox until webgl works in the sandbox. This way, people
don't have to add --disable-sandbox explicitly and will automatically
be safe once webgl works in the sandbox.
On Wed, Dec 30, 2009 at 4:15 PM, Nico Weber tha...@chromium.org wrote:
I thought there were two separate issues here:
1.) The specific webgl switch. Darin suggested that it should imply
--disable-sandbox until webgl works in the sandbox. This way, people
don't have to add --disable-sandbox
This is exactly what I was thinking. An infobar is the right choice in my
opinion.
Having a modal dialog on startup for those who use this switch regularly due
to issues, should not be suddenly have a *really annoying* modal dialog
every time they start their browser.
An infobar, on the other
On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.org wrote:
I don't think we should take away --no-sandbox in official builds. It's a
valuable debugging tool in case an end-user is experiencing a startup crash
or other wackiness.
I understand the argument, but do we really end
(adding Alice)
Alice: do you have a rough estimate for how often we ask users to turn off
the sandbox when debugging problems?
Thanks
On Fri, Dec 11, 2009 at 11:33 AM, John Abd-El-Malek j...@chromium.orgwrote:
On Thu, Dec 10, 2009 at 11:34 PM, Darin Fisher da...@chromium.org wrote:
I
Alice's reply is below. I'm still convinced that Google Chrome shouldn't
run without the sandbox, and if someone needs that, then they can use
Chromium builds.
We actually rarely ask users to turn off the sandbox and after we confirm
that they can run it with the flag, we tell them do remove it
We actually rarely ask users to turn off the sandbox and after we confirm
that they can run it with the flag, we tell them do remove it immediately
due to security vulnerabilities. The only problem is that after this point,
it's hard for users to figure out what's preventing Google Chrome to run
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,
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:
Perhaps --enable-webgl should instead implicitly disable the sandbox today
I think this is better than having users manually disable it. They'll be
running without a sandbox either way, but this (a) makes the enabling
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org 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
On Thu, Dec 10, 2009 at 9:29 PM, Jeremy Orlow jor...@google.com wrote:
On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org 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
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 da...@chromium.org wrote:
After reading the WebGL blog post today,
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 j...@chromium.org wrote:
We disable --single-process and --in-process-plugins on release Google
Chrome builds to avoid the support headache that it causes. I think
That would be nice to have. Everyone agrees that is a critical option to
turn on, so a light red tone info bar would be great for that.
-Mohamed Mansour
On Fri, Dec 11, 2009 at 12:49 AM, Finnur Thorarinsson
fin...@chromium.orgwrote:
I wonder... should we show an infobar on startup when the
On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.org 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.
There are legit reasons we have
On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote:
On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote:
We disable --single-process and --in-process-plugins on release
I don't think we should take away --no-sandbox in official builds. It's a
valuable debugging tool in case an end-user is experiencing a startup crash
or other wackiness.
I think we should just add a modal dialog at startup that you must dismiss
each time you launch Chrome until you remove the
19 matches
Mail list logo
