Closed Bug 1252272 Opened 9 years ago Closed 8 years ago

[tracking] Migrate developers to WebExtensions

Categories

(WebExtensions :: Compatibility, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: andy+bugzilla, Unassigned)

References

Details

(Keywords: meta, Whiteboard: triaged)

This is a general tracker for all the things we'd like to do to help add-on developers to port over to WebExtensions, including using WebExtensions APIs from legacy add-ons from the SDK.
Depends on: 1270763
Depends on: 1270782
Depends on: 1208596
Depends on: 1270786
Depends on: 1270787
Whiteboard: triaged
No longer depends on: 1270782
No longer depends on: 1270786
No longer depends on: 1270763
No longer depends on: 1208596
End users install extensions to obtain capabilities that are not implemented in the "vanilla" application. In some cases, the extension provides a capability that has been removed from the application. There are a number of "orphan" extensions. These are extensions that currently work as intended but whose developers have abandoned. While they remain desirable, they will break when WebExtensions is finally completed and released to the end users. What provision is being made for Mozilla to handle the conversion of such orphan extensions to be compatible with WebExtensions?
(In reply to David E. Ross from comment #1) > What provision is being made for Mozilla to handle the conversion of such > orphan extensions to be compatible with WebExtensions? Add-on listings belong to their developers, so we won't take them over or offer them to others. We are approaching all developers to make them aware of the upcoming changes, and in some cases we might offer automatically-converted add-ons so they can more easily update their listings. However, if they choose not to respond, we won't do anything more than mark these add-ons as incompatible when they start breaking. I have confidence that if an add-on abandoned can be implemented as a WebExtension and is popular/useful enough, someone in the community will create a fork to keep it alive.
Well said, Pangloss. How are you identifying orphaned extensions, David?
(In reply to Jorge Villalobos [:jorgev] from comment #2) > > I have confidence that if an add-on abandoned can be implemented as a > WebExtension and is popular/useful enough, someone in the community will > create a fork to keep it alive. In U.S. football, a long pass by the quarterback that he does not know if any of his team is in position to receive the ball is termed a "hail Mary". Your answer is also a hail Mary in that you do not know if anyone is both interested and qualified to adopt an orphan extension. I have 28 extensions installed in my primary SeaMonkey profile. Three of them have not been updated in two years; that lack of activity indicates they might have been abandoned. I believe additional extensions will also be abandoned when their developers decide not to expend the effort to convert them for WebExtensions. One of the most popular extensions is PrefBar, whose developer is already questioning whether to continue development.
Hey I'm writing a new Addon which is injecting javascript code in pages. Since webextensions are supporting the cloneInto etc. functions it's really neat, but I still need the possibility to pass data to the content script before the page is loaded or starts loading. Therefor I can not rely on the asynchronus message or storage api. The sdk page_mod api supports contentScriptOptions and contentScriptWhen for script injection. I would like to see something similar for webextensions executeScript or something else which would meet my needs. more information in my original post: https://bugzilla.mozilla.org/show_bug.cgi?id=1305856#c1
Component: WebExtensions: Untriaged → WebExtensions: Compatibility
Priority: -- → P3
All the dependencies are closed, closing this bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.