Remove old flags from about:flags and add new ones instead.

Remove old flags from about:flags and add new ones instead.

We are moving from nacl64-gdb to debugger via debug stub.
In order to reduce user confusion, we need to leave only new flag.

BUG= none
TEST= bots, launch chrome and open about:flags page.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=157006

[sky, 2012-08-31 15:59:58]

LGTM

[Mark Seaborn, 2012-08-31 20:10:18]

Hmm, I'm not sure we're ready to put '--enable-nacl-debug' in about:flags (and
this overrides the comments about the details) -- see below.

Removing the old options is OK though.

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/app/generated_r...
File chrome/app/generated_resources.grd (right):

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/app/generated_r...
chrome/app/generated_resources.grd:5309: +      <message
name="IDS_FLAGS_ENABLE_NACL_DEBUG_NAME" desc="Name of the 'NaCl debug stub'
lab.">
Maybe write 'NaCl GDB debug stub' to make things clearer.

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/app/generated_r...
chrome/app/generated_resources.grd:5310: +        Native Client debugging
Maybe 'Native Client GDB-based debugging'?

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/app/generated_r...
chrome/app/generated_resources.grd:5313: +        Enable debug stub that stops
Native Client applications at startup and waits for nacl-gdb debugger from NaCl
SDK.
Maybe: "Enable GDB debug stub.  This will stop a Native Client application on
startup and wait for nacl-gdb (from the NaCl SDK) to attach to it."

Do you think this is useful to enable via about:flags?  If someone enables it
and forgets about it, they will find that NaCl apps mysteriously fail to start,
without any indication of why.

It might avoid potential confusion if we only support this via the command line.

Also, currently '--enable-nacl-debug' also requires '--no-sandbox', so enabling 
it via about:flags alone is not very useful.  While we could make
nacl_process_host.cc add kNoSandbox automatically, that is a little scary. 
Maybe we can put effort into making the debug stub work without --no-sandbox
rather than adding --no-sandbox implicitly?

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/browser/about_f...
File chrome/browser/about_flags.cc (right):

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/browser/about_f...
chrome/browser/about_flags.cc:355: kOsWin | kOsLinux | kOsCrOS,
Let's just put kOsAll.  Mac support will be done soon.  There's no need to
create extra work for changing this later -- we're likely to forget.

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/tools/chromeact...
File chrome/tools/chromeactions.txt (right):

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/tools/chromeact...
chrome/tools/chromeactions.txt:13:
0x088990bbea59a185	AboutFlags_disable-website-settings
Looks like an unrelated change.  Can you note why you're doing this in the
commit message?

Is there some command you run to generate this file?  Is there a lack of
awareness about what to run, and how can you address that other than fixing
other people's mistakes after them?

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/tools/chromeact...
chrome/tools/chromeactions.txt:1176: 0xac722301695b9315	PageLoad
Ditto about unrelated change

[halyavin, 2012-08-31 20:32:46]

This is needed for ChromeOS debugging. You can't pass command line flags there
but you can set them via about:flags.

[halyavin, 2012-08-31 20:37:15]

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/tools/chromeact...
File chrome/tools/chromeactions.txt (right):

https://chromiumcodereview.appspot.com/10918021/diff/1/chrome/tools/chromeact...
chrome/tools/chromeactions.txt:13:
0x088990bbea59a185	AboutFlags_disable-website-settings
On 2012/08/31 20:10:18, Mark Seaborn wrote:
> Looks like an unrelated change.  Can you note why you're doing this in the
> commit message?
> 
> Is there some command you run to generate this file?  Is there a lack of
> awareness about what to run, and how can you address that other than fixing
> other people's mistakes after them?
This is autogenerated by chrome/tools/extract_actions.py as requested in
about_flags.cc.
Also, I am told that this file is not used by chrome but by server-side
application.

[Mark Seaborn, 2012-08-31 20:59:46]

On 31 August 2012 13:32, <[email protected]> wrote:

> This is needed for ChromeOS debugging. You can't pass command line flags
> there
> but you can set them via about:flags.
>

OK, I hadn't thought about Chrome OS.  But we still need to address the
"--no-sandbox" requirement in some way.

Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[Mark Seaborn, 2012-08-31 20:59:47]

On 31 August 2012 13:32, <[email protected]> wrote:

> This is needed for ChromeOS debugging. You can't pass command line flags
> there
> but you can set them via about:flags.
>

OK, I hadn't thought about Chrome OS.  But we still need to address the
"--no-sandbox" requirement in some way.

Mark

[halyavin, 2012-09-03 12:04:39]

http://codereview.chromium.org/10918021/diff/1/chrome/app/generated_resources...
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/10918021/diff/1/chrome/app/generated_resources...
chrome/app/generated_resources.grd:5309: +      <message
name="IDS_FLAGS_ENABLE_NACL_DEBUG_NAME" desc="Name of the 'NaCl debug stub'
lab.">
On 2012/08/31 20:10:18, Mark Seaborn wrote:
> Maybe write 'NaCl GDB debug stub' to make things clearer.

Done.

http://codereview.chromium.org/10918021/diff/1/chrome/app/generated_resources...
chrome/app/generated_resources.grd:5310: +        Native Client debugging
On 2012/08/31 20:10:18, Mark Seaborn wrote:
> Maybe 'Native Client GDB-based debugging'?

Done.

http://codereview.chromium.org/10918021/diff/1/chrome/app/generated_resources...
chrome/app/generated_resources.grd:5313: +        Enable debug stub that stops
Native Client applications at startup and waits for nacl-gdb debugger from NaCl
SDK.
On 2012/08/31 20:10:18, Mark Seaborn wrote:
> Maybe: "Enable GDB debug stub.  This will stop a Native Client application on
> startup and wait for nacl-gdb (from the NaCl SDK) to attach to it."
> 
> Do you think this is useful to enable via about:flags?  If someone enables it
> and forgets about it, they will find that NaCl apps mysteriously fail to
start,
> without any indication of why.
> 
> It might avoid potential confusion if we only support this via the command
line.
> 
> Also, currently '--enable-nacl-debug' also requires '--no-sandbox', so
enabling 
> it via about:flags alone is not very useful.  While we could make
> nacl_process_host.cc add kNoSandbox automatically, that is a little scary. 
> Maybe we can put effort into making the debug stub work without --no-sandbox
> rather than adding --no-sandbox implicitly?

Done. I think we should address no-sandbox issue in a separate CL(s).

http://codereview.chromium.org/10918021/diff/1/chrome/browser/about_flags.cc
File chrome/browser/about_flags.cc (right):

http://codereview.chromium.org/10918021/diff/1/chrome/browser/about_flags.cc#...
chrome/browser/about_flags.cc:355: kOsWin | kOsLinux | kOsCrOS,
On 2012/08/31 20:10:18, Mark Seaborn wrote:
> Let's just put kOsAll.  Mac support will be done soon.  There's no need to
> create extra work for changing this later -- we're likely to forget.

Done.

[halyavin, 2012-09-04 12:10:30]

http://codereview.chromium.org/10918021/diff/1/chrome/app/generated_resources...
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/10918021/diff/1/chrome/app/generated_resources...
chrome/app/generated_resources.grd:5313: +        Enable debug stub that stops
Native Client applications at startup and waits for nacl-gdb debugger from NaCl
SDK.
On 2012/08/31 20:10:18, Mark Seaborn wrote:
> Also, currently '--enable-nacl-debug' also requires '--no-sandbox', so
enabling 
> it via about:flags alone is not very useful.  While we could make
> nacl_process_host.cc add kNoSandbox automatically, that is a little scary. 
> Maybe we can put effort into making the debug stub work without --no-sandbox
> rather than adding --no-sandbox implicitly?

I investigated the issue and talked with people from ChromeOS team. They
explained that adding --no-sandbox is not possible without switching to dev mode
and changing OS image (and sandbox can't be disabled for NaCl without disabling
it for all processes). If, on the other hand, we could make debug stub work
without --no-sandbox, one can debug NaCl applications in ChromeOS even without
switching to dev mode.