Closed Bug 724055 Opened 12 years ago Closed 12 years ago

Create a really easy way to make new GCLI commands

Categories

(DevTools :: Console, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 16

People

(Reporter: jwalker, Assigned: jwalker)

Details

Attachments

(1 file, 1 obsolete file)

      No description provided.
GCLI Triage.
Target Milestone: Firefox 14 → Firefox 16
Target Milestone: Firefox 16 → Firefox 17
Target Milestone: Firefox 17 → Firefox 16
Could we build a GCLI command from Scratchpad?
(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.
(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...)
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).
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
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.
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.
(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.
(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.
Attached patch Upload 1 (obsolete) — Splinter Review
Assignee: nobody → jwalker
Status: NEW → ASSIGNED
Attachment #635725 - Flags: review?(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?
Attachment #635725 - Flags: review?(dcamp)
Attached patch Upload 2Splinter Review
Attachment #635725 - Attachment is obsolete: true
Attachment #636078 - Flags: review?(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?
Attachment #636078 - Flags: review?(dcamp) → review+
(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.
https://hg.mozilla.org/mozilla-central/rev/b6cb132d8df9
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED

(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.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.