SDK 2013 Roadmap

[Jeff Griffiths]

During December I worked with the rest of the SDK team as well as
other stakeholders to develop a product road-map for the SDK for the
next year. This road-map planning is critical as 2013 promises to be a
very eventful year for both the Jetpack team and the SDK, and I think
a very, very positive one.

The Roadmap is here:

https://wiki.mozilla.org/Jetpack/Roadmap/2013

I've also just posted a blog post that calls out some of the bigger
points over on the AMO blog:

https://blog.mozilla.org/addons/?p=5760

I should caution you, this is the high level view and does not cover
*all* of the things we are going to get up to, however the Roadmap is
should give you a good picture of what is most important to us.

regards, Jeff

[Brett]

Howdy,

Really nice work on the SDK. It's fun to develop with it.

I hope I can have a place here to make a brain dump.

It looks like you already have two of my priorities on your radar, localization (which is a must-have in the Addons builder, and content script JS localization is also a must--the docs also don't mention i18n-izing properties like the Addon name/description, only the preference name/descriptions; and getting the current locale would be a plus).

Why doesn't context-menu support port?

How about an API to allow simple-prefs to be receivable and/or settable within a content script? Given the frequency I'm seeing this need, I'd rather not have to declare events, JSON stringifying, etc., just to let content scripts have access to my add-on's own preferences.

Mention is made at https://addons.mozilla.org/en-US/developers/docs/sdk/latest/dev-guide/tutorials/reusable-modules.html of "the "packages" directory in the SDK root" which no longer appears valid.

What is the best place to discuss the likelihood of 3rd party APIs making it into the SDK, or of modifications making it in, and of helping to make it a reality?

Thanks!
Brett

[Brett]

Also, I didn't see the builder.addons.mozilla.org site as part of your Github repos. Is that available publicly somewhere? (The link to docs there is broken.)

[David C. Mason]

Jeff, 

The Roadmap looks awesome! I'm still super-excited that the APIs are going to land in Firefox.

I was thinking about the future of the sdk, and very specifically builder, after reading this. It might be interesting to start a conversation here, or in a space somewhere else online, for people to share their thoughts on the future of Builder. I know its been a difficult app to deal with in terms of its future, but perhaps now is a good time to at least start the conversation - especially with an eye towards the 2012 goal of "re-implementation of the cfx tool's packaging functionality in JS."

I always felt like there might be a good way to use the builder itself to prompt its users to join in on a conversation like this - otherwise decisions can be made with little to no awareness by the actual users of the app. Maybe a brain dump by those willing to do so first - then a small survey of users through the builder based on that brain dump?

What do you think?

Dave

On Wed, Jan 9, 2013 at 4:23 AM, Brett <bre...@gmail.com> wrote:

Also, I didn't see the builder.addons.mozilla.org site as part of your Github repos. Is that available publicly somewhere? (The link to docs there is broken.)

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mozilla-labs-jetpack/-/9_opVGJyI2oJ.

To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

[Jeff Griffiths]

Thanks!

Yes, Builder is much on our minds... I'm putting together a bunch of
arguments, and even attempting to get stats from builder itself, to
formulate a plan to end-of-life Builder in something like 9 months.
There is no traction for keeping it going internally and the AMO
submission data, while steady, isn't supportive either. It doesn't
help that Builder regularly has xss / security bugs and has almost no
dev resources. 9 months is about as far as I can push it.

This means I'll need to start the conversation with the community
soon, but I also need to provide a more concrete future plan, and
that's something Mossop, dcamp, Bill and I haven't really fleshed out
yet.

One of the frustrations is just that Dan doesn't seem to have any data
for builder usage at all. I'm going to try to work with Wil and get
access to MySQL directly ( or a dump ). It's foolish to try to make
decisions without hard data, even if we get qualitative data and
expressions of support from some community members it means nothing if
builder isn't actually all that active, right?

cheers, Jeff

[Jeff Griffiths]

On Wed, Jan 9, 2013 at 1:21 AM, Brett <bre...@gmail.com> wrote:
> Howdy,
>
> Really nice work on the SDK. It's fun to develop with it.

On behalf of all the contributors, thanks!

> I hope I can have a place here to make a brain dump.
>
> It looks like you already have two of my priorities on your radar,
> localization (which is a must-have in the Addons builder, and content script
> JS localization is also a must--the docs also don't mention i18n-izing
> properties like the Addon name/description, only the preference
> name/descriptions; and getting the current locale would be a plus).

I agree that localization is important, and I believe we have plans
for some of these things, however we did intentionally pause on l10n
work a few months ago for a few reasons: we got to a decent place with
it, we wanted more feedback from the community, and Alex has been
working on Firefox OS recently. I expect he'll have some ideas on
where he wants to take things, and we expect him to return soon.

> Why doesn't context-menu support port?

context-menu is one of the oldest modules we have, and one of the
biggest sources of problems. One side effect is that it only supports
the 'message' event and related onMessage callback.

Dave Townsend recently did a complete re-write of the module and this
work is on track to be released in 1.13. What Dave has done so far is
re-implement context-menu with the same interface but with a much more
reliable implementation underneath.

We've also been discussing how to make context-menu easier to use, and
there are obvious things we would like to do like add an onClick
handler, eg something like this:


cm.Item({
//...
onClick: function(context) { }
});

In the above scenario context would be say the attributes of the
target node, *not* a reference to the target node.

We're also considering deprecating the use of content scripts with
context-menu. Just curious: do you use content scripts with
context-menu a lot? What are your use cases?

> How about an API to allow simple-prefs to be receivable and/or settable
> within a content script? Given the frequency I'm seeing this need, I'd
> rather not have to declare events, JSON stringifying, etc., just to let
> content scripts have access to my add-on's own preferences.
>
> Mention is made at
> https://addons.mozilla.org/en-US/developers/docs/sdk/latest/dev-guide/tutorials/reusable-modules.html
> of "the "packages" directory in the SDK root" which no longer appears valid.

Logged as a bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=828570

> What is the best place to discuss the likelihood of 3rd party APIs making it
> into the SDK, or of modifications making it in, and of helping to make it a
> reality?

This list is a great place to discuss that. We also have a semi-formal
enhancement proposal process that we'd like people to follow:

https://github.com/mozilla/addon-sdk/wiki/JEP

It doesn't seem like too much work. We also have a number of third
party modules either in builder or listed here:

https://github.com/mozilla/addon-sdk/wiki/Community-developed-modules

Thanks for all the great questions! It's been a bit quiet in here of
late so I'm glad my post generated some real discussion!

cheers, Jeff

[CIAvash]

On 01/09/2013 10:27 PM, Jeff Griffiths wrote:

context-menu is one of the oldest modules we have, and one of the
biggest sources of problems. One side effect is that it only supports
the 'message' event and related onMessage callback.

Dave Townsend recently did a complete re-write of the module and this
work is on track to be released in 1.13. What Dave has done so far is
re-implement context-menu with the same interface but with a much more
reliable implementation underneath.

We've also been discussing how to make context-menu easier to use, and
there are obvious things we would like to do like add an onClick
handler, eg something like this:


cm.Item({
    //...
    onClick: function(context) {  }
});

In the above scenario context would be say the attributes of the
target node, *not* a reference to the target node.

 We're also considering deprecating the use of content scripts with
context-menu. Just curious: do you use content scripts with
context-menu a lot? What are your use cases?

You mean we can't use content scripts with context-menu? Not even with the new content script[Proposal]?

Then how can we do operations on the node or the page?

And we had a discussion on contex-menu's messaging here.

Take one of my add-ons, ContextMenuPlus for example:

Some of the items can be changed to use the onClick handler you mentioned. And some of them could be changed to use page-mod, but using content script is a lot easier than using page-mod.

And some items directly change the node.

Specially "Stop Loading Image", "Copy Feed URL" and "Paste & Submit" context menu items.

[Jeff Griffiths]

On Thu, Jan 10, 2013 at 3:52 AM, CIAvash <mibla...@gmail.com> wrote:
...

> You mean we can't use content scripts with context-menu? Not even with the
> new content script[Proposal]?

Sorry if this alarmed you, I'm referring to some discussions we've been having lately around improving context-menu.

What I mean is that we're considering deprecating ( not removing ) content scripts and providing better alternatives, but we definitely wanted some feedback like this before pulling the trigger. In particular, the use cases you just provided are really helpful to understand what sort of capabilities we'd need to provide if we did make this move.

> Then how can we do operations on the node or the page?
>
> And we had a discussion on contex-menu's messaging here.
>
> Take one of my add-ons, ContextMenuPlus for example:
>
> Some of the items can be changed to use the onClick handler you mentioned.
> And some of them could be changed to use page-mod, but using content script
> is a lot easier than using page-mod.
>
> And some items directly change the node.
>
> Specially "Stop Loading Image", "Copy Feed URL" and "Paste & Submit" context
> menu items.

Is the source available for this add-on somewhere?

The other idea Irakli mentioned recently is something called 'invoke()' which is a wrapper function that takes as its first argument a function that would be run in the cntent script sandbox:

cm.Item({
   ...
   contentScript: invoke(function(context) {
        // some code here
    }),
});

Think of this as a utility function that removes the need for in-lining a string, at least.

Curious to hear what you think.

Jeff

[CIAvash]

On 01/10/2013 09:05 PM, Jeff Griffiths wrote:
> Sorry if this alarmed you, I'm referring to some discussions we've
> been having lately around improving context-menu.
>
> What I mean is that we're considering deprecating ( not removing )
> content scripts and providing better alternatives, but we definitely
> wanted some feedback like this before pulling the trigger. In
> particular, the use cases you just provided are really helpful to
> understand what sort of capabilities we'd need to provide if we did
> make this move.

I guess I panicked a little :)

Was this mentioned somewhere, like weekly meetings? Cause I don't
remember any talks on this.

> Is the source available for this add-on somewhere?

https://github.com/CIAvash/ContextMenuPlus

> The other idea Irakli mentioned recently is something called
> 'invoke()' which is a wrapper function that takes as its first
> argument a function that would be run in the cntent script sandbox:
>
> cm.Item({
> ...
> contentScript: invoke(function(context) {
> // some code here
> }),
> });
>
> Think of this as a utility function that removes the need for
> in-lining a string, at least.
>
> Curious to hear what you think.

So instead of creating a content script object we can define a function
and use it as a content script and even reuse it and share it between APIs?

More questions:

- With this, even context-menu can use the 'port' in content script for
messaging?
- Can APIs pass/receive messages to/from each other(if the content
script is shared)?
- What about 'context' and 'click' events for context-menu?
- What will happen to contentScriptFile?
- How is the scope of this content script sandbox? Will it be the same
as current? What are the limitations? Will there be a way to use
functions and variables from the main code or that will be the port's
job? Will there be a way to use APIs in content scripts, like the one
Irakli wrote in the content script proposal?

The more I think about it, the more I get confued, I don't know how deep
you're going to change content script and context menu. I'm not even
sure if you wanted to talk about content scripts!

[Jeff Griffiths]

On Thu, Jan 10, 2013 at 1:35 PM, CIAvash <mibla...@gmail.com> wrote:

Was this mentioned somewhere, like weekly meetings? Cause I don't remember any talks on this.

Nothing that organized, just IRC discussion mainly. We don't even have a JEP I can point you to, we're just bouncing around ideas. The good thing is that your questions here mean we're bouncing around ideas in public!

 

...So instead of creating a content script object we can define a function and use it as a content script and even reuse it and share it between APIs?

I think `invoke()` is meant to be a light-weight way to replace inline strings for the contentScript property.
 

More questions:

- With this, even context-menu can use the 'port' in content script for messaging?

- Can APIs pass/receive messages to/from each other(if the content script is shared)?
- What about 'context' and 'click' events for context-menu?

Your questions are more in line with Irakli's content script object JEP ( https://github.com/mozilla/addon-sdk/wiki/JEP-Content-scripts ) that you referred to. I take it you're generally happy with what is proposed in that JEP?
 

- What will happen to contentScriptFile?
- How is the scope of this content script sandbox? Will it be the same as current? What are the limitations? Will there be a way to use functions and variables from the main code or that will be the port's job? Will there be a way to use APIs in content scripts, like the one Irakli wrote in the content script proposal?

These are all details that we need to work out. I can see some interesting possibilities if you could share the content script sandbox between page-mod and context-menu, like the first one that attaches creates the sandbox and the rest are injected. You'd need to handle potential collisions, but that would come out in testing, right? :)
 

The more I think about it, the more I get confued, I don't know how deep you're going to change content script and context menu. I'm not even sure if you wanted to talk about content scripts!

I'd like to apologize for causing confusion. We're not completely set on any particular way to move forward, we're just unhappy with some aspects of the current implementation. If we do anything in the short medium term, it will be to implement onClick and preserve the existing functionality as-is.

If we're actually planning on implementing breaking changes, you'll see a lot of posts here and on the blog about it first and we'll deprecate for a few versions.
 
Thanks for the questions, and ask any more that occur to you!

Jeff

[CIAvash]

On 01/11/2013 02:40 AM, Jeff Griffiths wrote:
> Your questions are more in line with Irakli's content script object
> JEP ( https://github.com/mozilla/addon-sdk/wiki/JEP-Content-scripts )
> that you referred to. I take it you're generally happy with what is
> proposed in that JEP?

Yes, I liked the idea.

> I'd like to apologize for causing confusion. We're not completely set
> on any particular way to move forward, we're just unhappy with some
> aspects of the current implementation. If we do anything in the short
> medium term, it will be to implement onClick and preserve the existing
> functionality as-is.
>
> If we're actually planning on implementing breaking changes, you'll
> see a lot of posts here and on the blog about it first and we'll
> deprecate for a few versions.

It's okay, I'm just confused because I'm not aware of the discussions
you had.

I hope the new implementation is not going to leave out anything
essential! :)

Thanks for the answers.