1547280 - Lay the foundation for implementing the webextension API

Status: RESOLVED FIXED

(Firefox :: Address Bar, task, P2)

Description

[Mike de Boer [:mikedeboer]]

Lay the foundation for implementing the webextension API: create new directories in the tree, add any necessary moz.build and other build-related files, create initial stub implementation of ExtensionAPI subclass, etc.

Comment 1

[Mike de Boer [:mikedeboer]]

Attachment: Bug 1547280 - Create a new 'urlbar' WebExtension API for Mozilla-only experiments. r?mixedpuppy!,mak!

Comment 2

[Mike de Boer [:mikedeboer]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fcd984ce640a40cf035f19f29671cddb9235366

Comment 3

[Mike de Boer [:mikedeboer]]

Shane, David, Mike. I understand that you're not looking forward to having these kind of APIs being created, pile up and potentially become unmaintained. This might not be your main concern, but I don't understand your case to not allow this in the first place, I guess.

I need my team to move forward with this, now, today. We don't have room in our schedule to wait on a new 'experiments' namespace/ API collection and a potential 'expiration' feature and I don't see the value of that for our team in particular.
Remote settings and Normandy pref flips are also not an option and will never be for the type and volume of experiments/ A/B studies that we have in mind.
With this structure in place as a start/ enabler, we plan to be doing a different kind of product development than other teams have done before: 100% test- and data-driven. We've designed and built QuantumBar for that purpose, not to simply 'de-XBL'.

If you would like to meet in person to discuss this matter further, I'd love to. But I would most appreciate a 'GO' here to allow us to proceed and for the addons team to trust in our ability to properly build and maintain an API.
If there is ever going to be a public API, it will be designed and written from scratch. We will not simply 'open up' one of the browser.urlbar ones. Not ever.

Comment 4

[Shane Caraveo (:mixedpuppy)]

(In reply to Mike de Boer [:mikedeboer] from comment #3)

but I don't understand your case to not allow this in the first place, I guess.

We never made that kind of decision.

This API along with multiple others I'm working on and/or reviewing are all for experiments. We're starting to pollute the webextension api with stuff that we're not certain is solid, will have long lives, or have some desired requirements not supported by webextensions (e.g. policy to allow only the search team to use this api). The discussion around how we deal with this via both policy and architecture is important. We don't want to hold things up, but we need to address this.

I need my team to move forward with this, now, today. We don't have room in our schedule to wait on a new 'experiments' namespace/ API collection and a potential 'expiration' feature and I don't see the value of that for our team in particular.
Remote settings and Normandy pref flips are also not an option and will never be for the type and volume of experiments/ A/B studies that we have in mind.

I've given my review feedback and there has been no movement the patch.

With this structure in place as a start/ enabler, we plan to be doing a different kind of product development than other teams have done before: 100% test- and data-driven. We've designed and built QuantumBar for that purpose, not to simply 'de-XBL'.

If you would like to meet in person to discuss this matter further, I'd love to. But I would most appreciate a 'GO' here to allow us to proceed and for the addons team to trust in our ability to properly build and maintain an API.

I trust you can, but we still have to have standards about how APIs are implemented and exposed. Otherwise we will end up with a mess of APIs that all behave and work differently, don't properly use the infrastructure we do have in order to make things work consistently, etc.

If there is ever going to be a public API, it will be designed and written from scratch. We will not simply 'open up' one of the browser.urlbar ones. Not ever.

Then why not use the existing experimental api until the api is a little more fleshed out. That would let you move at whatever speed you desire, and likely give us time to decide on how we want these things to work in general.

Comment 5

[Mike Conca [:mconca]]

(In reply to Mike de Boer [:mikedeboer] from comment #3)

Shane, David, Mike. I understand that you're not looking forward to having these kind of APIs being created, pile up and potentially become unmaintained. This might not be your main concern, but I don't understand your case to not allow this in the first place, I guess.

Having a big pile of unmaintained API is precisely my main concern, but I don't think anyone is suggesting we don't allow this. In fact, I think we'd like to identify a way to make this easier without having every case be a one-off.

If there is ever going to be a public API, it will be designed and written from scratch. We will not simply 'open up' one of the browser.urlbar ones. Not ever.

So what happens to those urlbar APIs? Do they live forever? How do we know if anyone is still using them? Especially several years from now when some people have left and the remaining ones can't remember the details?

From a product standpoint, I love the fact that other teams are taking ownership of landing new API. The add-ons engineering team, though, should be in a position to provide stewardship. Think of it as "tending the WebExtensions garden" so that it remains a high-quality, coherent Firefox product for many years to come.

Comment 6

[Shane Caraveo (:mixedpuppy)]

At this point I think this should be dup'd to bug 1547285 and the patch abandoned.

Comment 7

[Marco Bonardo [:mak]]

For tracking purposes I think the dependency is fine, we can abandon the patch.

Comment 8

[Marco Bonardo [:mak]]

fixed by bug 1547285