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

Status: REOPENED

(WebExtensions :: Developer Tools, enhancement, P5)

Description

[Tim Nguyen :ntim]

This would allow plugins like http://emmet.io/ 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 = {
  "Name":"Emmet",
  "scriptURL":self.data.url("script.js");
}
Editor.plugins.inject(plugin);

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

We should talk about this in PDX, how add-on developers will use the editor infrastructure we have.

Comment 2

[Firefox Bug Husbandry Bot]

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

Comment 3

[Andy McKay]

Since you've moved this over from the SDK, do you maybe want to outline how this might look in a WebExtensions world ntim?

Comment 4

[Tim Nguyen :ntim]

It could be a manifest field:

"devtools_editor_plugins": ["<script_url>"]

Where script_url is the URL to the codemirror plugin

Comment 5

[Caitlin Neiman [:caitmuenster]]

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: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1vH4wqJJZt1jk-cpx5NOq67b1UNekeQog6bz2HFOHe5E/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 6

[Tim Nguyen :ntim]

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.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

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 https://wiki.mozilla.org/WebExtensions : Changes to Firefox's internal code should be less likely to break add-ons).