The goal is to annoy you so you will try to stop passing these arguments. Don't we already have other infobars possibly showing at startup (e.g., restore tabs)? -darin
On Fri, Dec 11, 2009 at 9:46 AM, Evan Martin <[email protected]> wrote: > I also like the "infobar on start", especially if there's no way to > say "stop bugging me" on it, so every time you start it will annoy > you. > > I would like to bring back --single-process as well in that case. On > Linux users are much more comfortable sending in stack traces etc. but > trying to walk someone through getting a renderer subprocess crash > into gdb is a pain; if I could say "run 'gdb --args chrome > --single-process" it would save me a lot of time. > > > On Fri, Dec 11, 2009 at 8:06 AM, Darin Fisher <[email protected]> wrote: > > I don't understand the argument for a periodic indicator. We don't have > a > > periodic indicator telling the user when to restart their browser to pick > up > > auto-updates. The only time it makes sense for the user to re-consider > > the command line options is when restarting because they might have > > been upgraded to a version that makes the --no-sandbox option unnecessary > > for their usage. > > -Darin > > > > On Fri, Dec 11, 2009 at 3:02 AM, PhistucK <[email protected]> wrote: > >> > >> Yes, a periodic inforbar would be swell and fairly effective. in my > >> opinion. > >> ☆PhistucK > >> > >> > >> On Fri, Dec 11, 2009 at 11:57, Jeremy Orlow <[email protected]> > wrote: > >>> > >>> On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell <[email protected]> > >>> wrote: > >>>> > >>>> (Resending from chromium.org) > >>>> > >>>> 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. > >>>> > >>>> I don't follow. The --no-sandbox command line argument only takes > >>>> effect for the current invocation of the browser. Most people launch > >>>> Chrome or Chromium from its icon, which will not have that argument > >>>> associated with it. > >>> > >>> On Windows, the most common way for people to launch with arguments is > to > >>> add them to a short cut. The risk is that they'd do this to their main > >>> shortcut and then forget about it. > >>> > >>>> > >>>> > 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. > >>>> > >>>> We will just remove the --no-sandbox option from that wiki page, and > >>>> people testing WebGL will eventually stop specifying it. > >>> > >>> _New_ users will stop specifying it, but I doubt people will be > regularly > >>> checking the wiki page. > >>> > >>>> > >>>> > 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? > >>>> > >>>> I considered this but rejected it because it might lull people into a > >>>> false sense of security -- thinking that they had "just" enabled WebGL > >>>> but were actually browsing without the sandbox. > >>>> > >>>> The best solution is to get the GPU process in place on all platforms, > >>>> at which point WebGL can be run inside the sandbox; this is a high > >>>> priority for me and others. > >>> > >>> We definitely know this is true, and I think it's even safe to assume > >>> this will be true for other features in the future that only work with > the > >>> sandbox off initially. The problem is the time before this is true. > >>> > >>> As for the info bar/modal dialog: I've been thinking for a bit, and > I'm > >>> not sure this is enough. We have plenty of data that shows users often > >>> leave browsers open for a very long time. The main risk is that > someone > >>> sets the flag, starts their browser, trys out the new cool feature, and > then > >>> leaves the browser window open...for a long time. The next time they > start > >>> it they'll see the warning again, but the period of time in between > (that > >>> they're more vulnerable) could be non-trivial. > >>> The solution to this is either the annoying/scary UI can't be > >>> disabled/clicked-through/etc (like a red and white striped theme that > can't > >>> be overridden) or to pop up a modal dialog or info bar periodically (it > >>> could even be once an hour or even day) in addition to popping it up > >>> initially. > >>> > >>> In http://code.google.com/p/chromium/issues/detail?id=24411, Finnur > said > >>> > >>> Also, when thinking about options 1 and 2 above > >>> (changing the appearance of Chrome) I can't help but think of someone > >>> pitching WebGL > >>> (which currently doesn't work in the sandbox) to their development team > >>> and the > >>> audience asking 'why is your browser all red?'. Answer: 'Oh, I have to > >>> turn off all the > >>> security in Chrome to get the demo to work'... :) > >>> > >>> I respectfully disagree. I think it's an opportunity to make it clear > >>> that the browser is normally running at a higher level of security than > any > >>> other and that we're _temporarily_ making Chromium on par with any > other > >>> browser. At the end of the day, Chromium will have these features > within a > >>> sandboxed environment. Other browsers won't. This point could be very > >>> powerful if presented well. > >>> J > >>> > >>> -- > >>> 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
