1215059 - (webextensions-additional-apis) [meta] Extend WebExtensions with custom APIs so more legacy add-ons can be ported

Status: VERIFIED FIXED

(WebExtensions :: General, enhancement, P3)

Description

[Gabor Krizsanits (INACTIVE)]

We've been polling the add-on developer community what APIs they need, and also we have our own ideas. Bill already has some ideas collected here: https://wiki.mozilla.org/WebExtensions/Future and here: https://wiki.mozilla.org/WebExtensions#Additional_APIs, the intention of this bug is to collect any features that we might want to implement and do not belong to webextensions-chrome-gaps.

Comment 3

[Hi-Angel]

Please, could anybody add "Depends on bug 1332447"? I can't edit the bug.

Comment 4

[fdsc]

I think what Bug 1246236 should be added to dependencies.

Comment 5

[est31]

See also Bug 1344646 and Bug 1344648

Comment 7

[Graham Perrin]

Should this bug 1215059 be meta for the two below?

- bug 1303384
- bug 1325692

Comment 8

[Ryan Hendrickson [rhendric on GitLab, GitHub]]

Also bug 1348589, I would think.

Comment 9

[Sam Bull]

One idea I had would be to add a browser.menus related callback that could be used to update the context menus in the current tab whenever the domain changed.

Right now, to implement this in our extension, we have needed to add a listener to tabs.onUpdated, tabs.onActivated and windows.onFocusChanged which runs a function to remove all previously added context menu items and then add new ones relevant to this domain. An alternative approach would be to create 1000s of context menu items using documentUrlPatterns at startup.

Both of these existing solutions seem like an inefficient way to dynamically control the context menus that should be displayed for a given domain name.

Comment 10

[Tim Nguyen :ntim]

(In reply to Sam Bull from comment #9)
> One idea I had would be to add a browser.menus related callback that could
> be used to update the context menus in the current tab whenever the domain
> changed.
> 
> Right now, to implement this in our extension, we have needed to add a
> listener to tabs.onUpdated, tabs.onActivated and windows.onFocusChanged
> which runs a function to remove all previously added context menu items and
> then add new ones relevant to this domain. An alternative approach would be
> to create 1000s of context menu items using documentUrlPatterns at startup.
> 
> Both of these existing solutions seem like an inefficient way to dynamically
> control the context menus that should be displayed for a given domain name.

Adding something like browser.menus.onShown/onBeforeShown seems reasonable (that allows populating the context menu when it's shown), can you file a bug ?

Comment 11

[Brett Zamir]

Since the bug mentioned polling the community, I thought I'd express my wish to see the following add-on categories, whose functionality I've been missing, reimplementable:

1. Ability to modify the location bar as with https://addons.mozilla.org/en-US/firefox/addon/ui-enhancer/
2. Ability to modify the search bar as with https://addons.mozilla.org/en-US/firefox/addon/clear-search-2/

(AFAIC, these particular features could be made into built-in Firefox options, obviating the need perhaps for extensibility, but maybe others want to extend in other ways.)

I'd also VERY much like to see a common accepted means for using Node within extensions (not just building from npm, mind you, but actually using its APIs for file access, etc.), even if it still requires native messaging. I don't know where https://github.com/mozilla/spidernode or https://github.com/NiklasGollenstede/native-ext may fit in.

Comment 12

[mirh]

Can we please add and reopen bug 1188835?

Comment 13

[David Durst [:ddurst]]

This bug was originally filed to allow us to track our API progression as we migrated to Web Extensions; specifically, this was intended to track APIs that we wanted to provide which were considered part of the Chrome compatibility gap.

We are tracking these things in other ways (via Product Management, other already-prioritized bugs, and bugs filed for discrete API requests), so this bug is no longer necessary as a tracking bug.

In fact, the presence of this bug sends a wrong implied message -- that marking a bug as blocking this is somehow meaningful. In reality, this bug has no impact on dependent bugs, and no impact on the likelihood of legacy add-ons being ported. "Chrome compatibility" is not defined by the number of legacy add-ons ported, or this bug in general.

Therefore, I'm closing this bug as RESOLVED FIXED. Specific API requests may be filed, but need not be related to this bug at all.

Comment 14

[Yuri Khan]

Hey, what? The legacy add-ons issue was never about Chrome compatibility. It is about tracking the regression in the quality of life for users who were accustomed to legacy add-ons in Firefox pre-57. The top message in this bug specifically says:

> features that we might want to implement and do not belong to webextensions-chrome-gaps.

Please reopen, and please honor the original intent of this bug: Useful things that add-ons could do before Firefox 57 but not now.

Comment 15

[Sebastian Zartner [:sebo]]

(In reply to Yuri Khan from comment #14)
> Hey, what? The legacy add-ons issue was never about Chrome compatibility. It
> is about tracking the regression in the quality of life for users who were
> accustomed to legacy add-ons in Firefox pre-57. The top message in this bug
> specifically says:
> 
> > features that we might want to implement and do not belong to webextensions-chrome-gaps.

That's bug 1161828, btw.

Sebastian

Comment 16

[Marat Tanalin]

(In reply to Sebastian Zartner [:sebo] from comment #15)

To be clear:

* bug 1161828 you’ve referred to is about Chrome compatibility;

* bug 1215059 (this one) is about making WebExtensions API more comparable feature-wise with XUL/XPCOM.

So Yuri is probably right, this bug has nothing to do with Chrome compatibility. As Gabor Krizsanits (the original reporter) said, “this bug is to collect any features that […] do not belong to webextensions-chrome-gaps”.

Comment 17

[David Durst [:ddurst]]

Ah yes, that is in error:

> This bug was originally filed to allow us to track our API progression as we migrated to Web Extensions; 
> specifically, this was intended to track APIs that we wanted to provide which were considered part of 
> the Chrome compatibility gap.

should read:

> This bug was originally filed to allow us to track our API progression as we migrated to Web Extensions; 
> specifically, this was intended to track APIs that we wanted to provide which were NOT considered part of 
> the Chrome compatibility gap.

But the rest of it stands. This bug has no significance as a tracker or meta or signal of any kind. Any API request should just be filed and need not be attached to this bug, as this bug will not be tracked.

Comment 18

[Yuri Khan]

I still think this tracking bug is useful. I follow it, and I get mail notifications when people add dependencies to it, and I can go check them out and decide if they are important to me and follow them too. Maybe even say “oh yes I forgot I used to be able to do that”.

By saying this tracking is unimportant, you are conveying that you’d rather like people to forget what they lost.

Comment 19

[Eddie Carswell]

I agree with Yuri. This bug may not be that useful to the devs, but others, including myself, use it to keep track of all the WebExtension bugs of interest.

Comment 20

[Kris Maglione [:kmag]]

(In reply to Eddie J Carswell II from comment #19)
> I agree with Yuri. This bug may not be that useful to the devs, but others,
> including myself, use it to keep track of all the WebExtension bugs of
> interest.

Then you can track them in a different component, if you have a particular desire to do so. But for us, the owners of this component and the people responsible for tracking and organizing Web Extensions development, this bug is only a source of noise, which has no practical use in guiding development.

Comment 21

[Yuri Khan]

(In reply to Kris Maglione [:kmag] from comment #20)

> Then you can track them in a different component, if you have a particular
> desire to do so. But for us, the owners of this component and the people
> responsible for tracking and organizing Web Extensions development, this bug
> is only a source of noise, which has no practical use in guiding development.

Will you be so kind as to suggest a component in the WebExtensions product that will not bother you?

Comment 22

[David Durst [:ddurst]]

If we wanted to completely eliminate this, we would close comments or move it to another (inaccurate) component -- but that's not what we're doing.

If this bug is useful in some way to people, that's fine. It can function that way whether it's open or closed. As long as it's clear that we are not monitoring this, setting the status of the bug is sufficient to remove it from our recurring triage. If we were to leave it open, it's simply (as Kris said) a noisy honeypot (and a mixed message, from a product point of view).

Please feel free to continue to file bugs for APIs, noting that these are enhancement requests and we will see them via their own characteristics, and not because of this bug.