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
