Create a really easy way to make new GCLI commands

RESOLVED FIXED in Firefox 16

Status

()

Firefox
Developer Tools: Console
P1
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jwalker, Assigned: jwalker)

Tracking

unspecified
Firefox 16
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Comment hidden (empty)
GCLI Triage.
Target Milestone: Firefox 14 → Firefox 16
Target Milestone: Firefox 16 → Firefox 17
Target Milestone: Firefox 17 → Firefox 16

Comment 2

5 years ago
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.

Comment 4

5 years ago
(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

5 years ago
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

Comment 7

5 years ago
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

5 years ago
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

5 years ago
(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.
Created attachment 635725 [details] [diff] [review]
Upload 1
Assignee: nobody → jwalker
Status: NEW → ASSIGNED
Attachment #635725 - Flags: review?(dcamp)

Comment 12

5 years ago
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)
Created attachment 636078 [details] [diff] [review]
Upload 2
Attachment #635725 - Attachment is obsolete: true
Attachment #636078 - Flags: review?(dcamp)

Comment 14

5 years ago
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://tbpl.mozilla.org/?tree=Try&rev=7a586eb25828
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=b6cb132d8df9
https://hg.mozilla.org/mozilla-central/rev/b6cb132d8df9
Status: ASSIGNED → RESOLVED
Last Resolved: 5 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.
You need to log in before you can comment on or make changes to this bug.