KOLANICH Reporter
	Description • 6 years ago

Here is the draft: https://github.com/KOLANICH/webext-experiment-scratchpad

but we can do better.

1 We need a WebComponent to embed the editor into a page. Think about it as about a textarea on steroids working without page-supplied JavaScript. To do it without breaking incapsulation we need to modify ScratchpadManager in the way allowing it to create an iframe.
2 some API for folding and unfolding code
3 some API for plugging own grammars
4 some API for adding own markers, for example error messages
5 some API for retreiving parsed AST
6 some events for notifing that the code have changed significantly enough to update the model.
7 some API for providing own environment and/or sandboxing the code.

	Kris Maglione [:kmag]
	Comment 1 • 6 years ago

Deciding whether we'd land APIs like this would really be up to the devtools team. But, regardless, this seems like a suite of separate but related bugs.

	Andrew Swan [:aswan]
	Comment 2 • 6 years ago

The see also bug (bug 1088996) covers proposed points 2-7 which leaves the first one (allowing extensions to instantiate the editor using something like a web component)

	Patrick Brosset <:pbro>
	Comment 3 • 6 years ago

I don't have a lot of context here. I've been testing the extension locally and read comments here and on the github repo, but I could use some more context about what is this experiment about, what is the end goal.

One question I have is whether Scratchpad is really needed here, or whether the source editor component is enough? 
Comment 0 and comment 2 seems to indicate that really what you want is to embed a source editor only, so I think scratchpad is too much here. It has its own window, and has a ton of added complexity on top of the source editor to do things like saving the source to a file on disk, etc. Plus scratchpad isn't really actively maintained those days, and its XUL code is showing its age. So I'd rather not add too much dependencies on it.
The source editor component however is very much used in many places of devtools, and we depend on it, so it's stable, maintained and will continue to be so. It's basically codemirror right now, just wrapped in in a thing that makes it easy for us to reuse in various places.

Using it is fairly simple, it's in a JS module in devtools that can be imported:

const { devtools } = Cu.import("resource://devtools/shared/Loader.jsm", {});
const { require } = devtools;
const Editor = require("devtools/client/sourceeditor/editor");

const editor = new Editor({
  mode: Editor.modes.html,
  lineWrapping: true,
  styleActiveLine: false,
  extraKeys: {},
  theme: "mozilla markup-view"
});
editor.appendToLocalElement(el);
editor.setText(text);
editor.getText();
...

	KOLANICH Reporter
	Comment 4 • 6 years ago

>One question I have is whether Scratchpad is really needed here, or whether the source editor component is enough? 

I prefer the component having full scratchpad editor (should be configurable by addon dev, but with all features of ScratchPad not harming security, for example we definitely need pretty-printing and menu with save/open (this component is to be used in developer-oriented addons/webapps and they will likely want to save/open files from local FS) ) but without own window (I mean it be opened either in a separate tab entirely, or as a WebComponent, in both cases with some API, but I'm not so familiar with Firefox internals by now to implement it securely).

>The source editor component however is very much used in many places of devtools, and we depend on it, so it's stable, maintained and will continue to be so. It's basically codemirror right now, just wrapped in in a thing that makes it easy for us to reuse in various places.

Thank you for the info. What should I know to create a webcomponent with this available for webpages? I'm not sure that I can pass html elements in messages.

	Luca Greco [:rpl] [:luca] [:lgreco]
	Comment 5 • 6 years ago

I'm going to close this bug as "resolved/wontfix", because it seems pretty out of the scope for the devtools API:
The WebExtension devtools API namespace (which is what this component is mainly about) is all about integrating with the Firefox Developer Toolbox (e.g. the devtools API namespace is not available in any of the extension pages, besides the ones integrated into an instance of the developer toolbox (currently the extension "devtools page", which is invisible, and the extension "devtools panel") and not the other way around (as "integrating UI components using by the Developer Toolbox internals" into arbitrary extension pages or webpages) as it seems to be the case here.

Also, not directly related to this one, but to Bug 1472265 (that has been added as a dependency of this one), at least if I recall correctly, none of the Developer Toolbox UI components is actually available on Firefox for Android, only the pieces related to the backend (the Remote Debugging Server components, and so mostly what lives in devtools/server: https://searchfox.org/mozilla-central/search?q=&path=devtools%2Fserver).

(just to be clear, I'm not saying that Kolanich should not keep experimenting with the idea, especially if it is something that you are still interested in, but we are not convinced that this could be a general purpose API that it is worth to commit to mantain over the time and Firefox releases).