Open Bug 1088996 Opened 5 years ago Updated 4 months ago

Add a way to inject CodeMirror plugins inside the DevTools Editor component


(WebExtensions :: Developer Tools, enhancement, P5)



(Not tracked)



(Reporter: ntim, Unassigned)



(Whiteboard: [design-decision-needed] [needs-follow-up])

This would allow plugins like to be injected inside the Firefox DevTools Editor component.

Proposed API :
// Todo : Expose the Editor() component to the addon sdk ?
var Editor = require("sdk/devtools/editor/"); 
var plugin = {
We should talk about this in PDX, how add-on developers will use the editor infrastructure we have.
Priority: -- → P1
Depends on: 1089428
Priority: P1 → --
Closed: 2 years ago
Resolution: --- → INCOMPLETE
Component: General → WebExtensions: Developer Tools
Product: Add-on SDK → Toolkit
Resolution: INCOMPLETE → ---
Since you've moved this over from the SDK, do you maybe want to outline how this might look in a WebExtensions world ntim?
Severity: normal → enhancement
Priority: -- → P5
Whiteboard: [design-decision-needed]
Flags: needinfo?(ntim.bugs)
It could be a manifest field:

"devtools_editor_plugins": ["<script_url>"]

Where script_url is the URL to the codemirror plugin
Flags: needinfo?(ntim.bugs)
Hi Tim, this has been added to the agenda for the December 5, 2017 WebExtensions APIs triage. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting:
* Meeting agenda:
* Vision doc for WebExtensions:
Flags: needinfo?(lgreco)
Reading the meeting notes, there were questions about sandboxing. 

The devtools code editor can be loaded in two modes: iframed (like in the style editor), inline (like in the netmonitor). 

The iframe mode is safe to inject in, since the frame URL will be a data URI (unprivileged). As for the inline mode, it's not safe to inject in, as the editor is loaded inline in the chrome URI.
Whiteboard: [design-decision-needed] → [design-decision-needed] [needs-follow-up]
Product: Toolkit → WebExtensions

Besides the sandbox issue (described by ntim in Comment 6), some another "design issues" that we may need to be discussed/solved could be:

  • how to make the user aware which extensions are "augmenting" a given DevTools code editor
  • how to deal with multiple extensions that all wants to "augment" the same DevTools code editor (and how to deal with potential conflicts)

An even more important "design issue" that we may have to consider is that the API as currently described seems to be too specific to the current implementation ("Firefox DevTools editors all based on codemirror"), and such an API would break if we decide to migrate the Firefox DevTools editors to a different implementation (e.g. let's say as an example that at some point we are evaluating to migrate from codemirror to another code editor library like monaco).

In general, exposing a specific implementation detail would prevent changes to the internal implementation without also introducing breaking changes for the existing extensions, which goes against the design principles of the WebExtensions APIs (and the very reason that pushed Firefox to introduce this new extension framework and deprecate the previous ones, mentioned in the goals listed at : Changes to Firefox's internal code should be less likely to break add-ons).

Flags: needinfo?(lgreco)
You need to log in before you can comment on or make changes to this bug.