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.
2.) If / how --enable-sandbox should uglify the UI. Your list is missing this suggestion by vandebo: """Instead of telling people to use --no-sandbox on the blog, we could tell them to use a new flag, --disable-sandbox-until MM/DD/YYYY. It could limit the maximum amount of time the sandbox was disabled, to say two weeks. After that, the sandbox would automatically be reenabled.""" (which could be in addition to the other stuff, if people think it's a good idea) On Wed, Dec 30, 2009 at 3:56 PM, Jeremy Orlow <jor...@google.com> wrote: > 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 >>> do. Here are the options as I see them: >>> 1) Modal dialog box. Bad for debugging, will probably just be clicked >>> through by users, and not very good for users who leave the browser open for >>> long stretches of time. I'd say it's not a good solution. >> >> I thought it was clear that this was the consensus best idea (see Darin's, >> Glen's, my posts for example). > > Glen didn't support it (only didn't object) and you and Darin were the only > ones that supported it. A couple of us thought it was a bad idea. I don't > see how this is anything close to a consensus. > >> >> I don't see how it's "bad for debugging" (Viet-Trung's objection makes >> absolutely no sense to me),and we don't care about the edge case of users >> who both use --no-sandbox and never restart (this works well enough even for >> restarting once every several weeks, which takes care of practically >> everyone). Clicking through is enough of an annoyance to serve our >> purposes, and this is trivially simple to add (simpler by far than all other >> options including an infobar). >>> >>> 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. >> Basically it's inferior to a modal dialog in every way. > > FYI: The ui-leads (in an off-list thread) seem to like Evan's initial patch > that goes this route. > >>> >>> 3) Add some other persistent UI like the incognito spy guy, an annoying >>> theme (that overrides whatever you have selected), or something else. This >>> seems like a pretty good option to me, but there hasn't been too much >>> discussion around it. What type of UI would be the best? Is this a good >>> option? >> >> No, we shouldn't do this. Way too much effort and code (think about >> making this work on three OSes and with custom themes), we just want >> something trivial. > > Themes are cross platform. Though I agree that this route may be more > trouble than it's worth. >>> >>> 4) Add some warning to the new tab page. Once again, no one's really >>> thought about this seriously. Any thoughts? >> >> Again, inferior to the other options. Doesn't work well for users who >> don't start with the NTP (or ones who never see it -- I don't, I don't use >> ctrl-t or the new tab button, I use middle-click and alt-enter). > > Fair enough. > >> >> If you're planning to implement something, please implement the dialog. > > I'd like to hear what others think as well. > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
