724055 - Create a really easy way to make new GCLI commands

Status: RESOLVED FIXED

(DevTools :: Console, defect, P1)

Comment 1

[Joe Walker [:jwalker]]

GCLI Triage.

Comment 2

[Paul Rouget [:paul]]

Could we build a GCLI command from Scratchpad?

Comment 3

[Joe Walker [:jwalker]]

(In reply to Paul Rouget [:paul] from comment #2)
> Could we build a GCLI command from Scratchpad?

Yes.

I'd like an easy way for them to be persistent too though.

Comment 4

[Paul Rouget [:paul]]

(In reply to Joe Walker from comment #3)
> (In reply to Paul Rouget [:paul] from comment #2)
> > Could we build a GCLI command from Scratchpad?
> 
> Yes.
> 
> I'd like an easy way for them to be persistent too though.

"Save As Command"?

Or we could have a command that opens a sourceeditor that would let you write a command:

> command list
> command create "foobar"

(just some ideas...)

Comment 5

[Paul Rouget [:paul]]

Joe suggested that we could got through a directory and load inner files as commands.
Of course, this would be disabled by default (behind a pref).

Comment 6

[Joe Walker [:jwalker]]

This feature is aimed at web developers who want to add their own custom commands.
Quick bit of documentation as to the current plan:

The user would set a pref: 'devtools.command.dir' to point to a directory which we
should scan for commands on startup (and perhaps on a refresh command).

Command files in this directory would be called *.mozcmd [1]

Command files would look like this:

[{
  name: 'hello',
  description: 'Show a message',
  params: [
    {
      name: 'name',
      type: 'string',
      description: 'Who to say hello to',
    }
  ],
  exec: function(args, context) {
    return 'Good morning, ' + args.name;
  }
}]

The format is basically JSON with the addition of functions. Initially these will be
read using eval, however in the future we could have a custom parser, which allows us
to enforce the constraint that JavaScript in a mozcmd file will only be executed as a
result of the user typing something - i.e. no init step [2].

This format has 2 other benefits:
* It should allow us to register types as well as commands
* It allows us to keep a track of what has been registered, so we can unregister
  them when asked to rescan the command directory.


Notes:
[1] The only reason for the extension is to allow disabling of commands by renaming
    them to have a different extension.
[2] Which should help security

Comment 7

[Paul Rouget [:paul]]

I'd like to add there's already a medium/easy way to create a command:

Go to http://builder.addons.mozilla.org/
Start a new Addon.

Paste this: 
> const { Cu } = require('chrome');
> Cu.import("resource:///modules/devtools/gcli.jsm");
> gcli.addCommand({
>  name: "echo3",
>  description: "echo3 yo!",
>  params: [
>    {
>      name: "message",
>      type: "string",
>      description: "a message"
>    }
>  ],
>  returnType: "string",
>  exec: function Command_echo(args, context) {
>    return "foobar: " + args.message;
>  }
>});

Click test and run, and it works.

It is not "really easy", but it exists.

Comment 8

[Rob Hawkes [:rob]]

Are we planning an even easier approach that doesn't require a Web Developer to create a directory for their commands, open "about:config", fiddle with a preference, and hope it worked, then do the same on all their other versions of FF and machines.

It's definitely 'easy' but it would be awesome to have an approach that; is either enabled by default or much easier to enable, and doesn't require the user to create a new directory and have to manage that (eg. syncing across all their machines). Something more invisible and automatic.

Could these not be stored and synced via Firefox Sync somehow?

Perhaps a suggestion for another bug, but I'd also love to see the ability to add new commands via a URL – just click it and "Would you like to add this new command?" then done. I can just imagine how share-able these commands will become and it'd be a shame for each user to have to recreate/retype commands instead of installing them from a Tweet/their friend.

Comment 9

[Kevin Dangoor]

(In reply to Rob Hawkes [:rob] from comment #8)
> Could these not be stored and synced via Firefox Sync somehow?

That would be cool. Especially if combined with a Source Editor (like Scratchpad) for editing.

> Perhaps a suggestion for another bug, but I'd also love to see the ability
> to add new commands via a URL – just click it and "Would you like to add
> this new command?" then done. I can just imagine how share-able these
> commands will become and it'd be a shame for each user to have to
> recreate/retype commands instead of installing them from a Tweet/their
> friend.

This would also be cool. Lighter weight that even a Jetpack. Also, once the Jetpack SDK has been ported to JS (which is an active project now), it could become possible to create a command and turn it into a Jetpack on AMO really quickly for sharing with others.

Comment 10

[Joe Walker [:jwalker]]

(In reply to Kevin Dangoor from comment #9)
> (In reply to Rob Hawkes [:rob] from comment #8)
> > Could these not be stored and synced via Firefox Sync somehow?
> 
> That would be cool. Especially if combined with a Source Editor (like
> Scratchpad) for editing.

Agreed: bug 767346

> > Perhaps a suggestion for another bug, but I'd also love to see the ability
> > to add new commands via a URL – just click it and "Would you like to add
> > this new command?" then done. I can just imagine how share-able these
> > commands will become and it'd be a shame for each user to have to
> > recreate/retype commands instead of installing them from a Tweet/their
> > friend.
> 
> This would also be cool. Lighter weight that even a Jetpack. Also, once the
> Jetpack SDK has been ported to JS (which is an active project now), it could
> become possible to create a command and turn it into a Jetpack on AMO really
> quickly for sharing with others.

These puppies run with chrome privs, so we're going to need to be really careful here.
But in principle we should be doing something here. I've not raised a bug for this because we don't have a concrete proposal, but feel free to create one.

Thanks.

Comment 11

[Joe Walker [:jwalker]]

Attachment: Upload 1

Comment 12

[Dave Camp (:dcamp)]

Comment on attachment 635725 [details] [diff] [review]
Upload 1

Review of attachment 635725 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/commandline/GcliCommands.jsm
@@ +81,5 @@
> +    }
> +    let source = NetUtil.readInputStreamToString(aStream, aStream.available());
> +    aStream.close();
> +
> +    var data = eval(source);

Could we do this in a sandbox?

Comment 13

[Joe Walker [:jwalker]]

Attachment: Upload 2

Comment 14

[Dave Camp (:dcamp)]

Comment on attachment 636078 [details] [diff] [review]
Upload 2

Review of attachment 636078 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/commandline/GcliCommands.jsm
@@ +130,5 @@
> +  name: "cmd refresh",
> +  description: gcli.lookup("cmdRefreshDesc"),
> +  exec: function Command_cmdRefresh(args, context) {
> +    GcliCommands.refreshAutoCommands(context.environment.chromeDocument.defaultView);
> +  }

It seems like this should be able to do something more useful if the pref isn't set/refers to a missing directory?

Comment 15

[Joe Walker [:jwalker]]

(In reply to Dave Camp (:dcamp) from comment #14)
> Review of attachment 636078 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/devtools/commandline/GcliCommands.jsm
> @@ +130,5 @@
> > +  name: "cmd refresh",
> > +  description: gcli.lookup("cmdRefreshDesc"),
> > +  exec: function Command_cmdRefresh(args, context) {
> > +    GcliCommands.refreshAutoCommands(context.environment.chromeDocument.defaultView);
> > +  }
> 
> It seems like this should be able to do something more useful if the pref
> isn't set/refers to a missing directory?

I raised Bug 767781.

Comment 16

[Joe Walker [:jwalker]]

https://tbpl.mozilla.org/?tree=Try&rev=7a586eb25828

Comment 17

[Joe Walker [:jwalker]]

https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=b6cb132d8df9

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b6cb132d8df9

Comment 19

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Kevin Dangoor from comment #9)
> (In reply to Rob Hawkes [:rob] from comment #8)
> > Could these not be stored and synced via Firefox Sync somehow?
> 
> That would be cool. Especially if combined with a Source Editor (like
> Scratchpad) for editing.
> 
> > Perhaps a suggestion for another bug, but I'd also love to see the ability
> > to add new commands via a URL – just click it and "Would you like to add
> > this new command?" then done. I can just imagine how share-able these
> > commands will become and it'd be a shame for each user to have to
> > recreate/retype commands instead of installing them from a Tweet/their
> > friend.
> 
> This would also be cool. Lighter weight that even a Jetpack. Also, once the
> Jetpack SDK has been ported to JS (which is an active project now), it could
> become possible to create a command and turn it into a Jetpack on AMO really
> quickly for sharing with others.

I've often thought of ways to leverage this, like:

1. edit in scratchpad, then save-as extension. If the code is in browser scope, we generate a page-mod for it. If it is in chrome scope, we wrap it into a CommonJS module and run it.

2. edit css for the current site, then save-as an add-on - we generate a wrapper page-mod that inserts the css as contentStyleFile. Note that there is an existing bug 755606 that details a problem where the style edit and contentStyleFile differ in behaviour due to divergent implementations. IMO the style editor gets it right.