DevTools/Features/CodeEditor

Status

Code Editor
Stage	Complete
Status	Complete
Release target	Firefox 10
Health	OK
Status note	`

Team

Product manager	Kevin Dangoor
Directly Responsible Individual	Kevin Dangoor
Lead engineer	Mihai Sucan
Security lead	`
Privacy lead	`
Localization lead	`
Accessibility lead	`
QA lead	Alex Lakatos
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

Open issues/risks

`

Stage 1: Definition

1. Feature overview

New developer tools features will provide opportunities for users to work directly with their code from within the browser. We would like for our tools to provide an editing interface that is more suited to editing code than a plain textarea or an HTML WYSIWYG interface.

Features that will take advantage of this editor: Scratchpad, Style Editor, devtools-oriented View Source.

2. Users & use cases

Most web developers will benefit from this and anyone doing significant JavaScript work will benefit most.

3. Dependencies

`

4. Requirements

• Orion code editor available for use within Firefox tools
• Integration with Scratchpad as a first step

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`

Feature details

Priority	P1
Rank	3
Theme / Goal	`
Roadmap	Developer Tools
Secondary roadmap	`
Feature list	Desktop
Project	`
Engineering team	DevTools

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	sec-review-complete	complete: 2011.10.15 Notes
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	TestPlan
User experience	`	`
Product marketing	`	`
Operations	`	`

Historical context from the original feature page:

Features that will take advantage of this editor: Scratchpad, CSS Editor, devtools-oriented View Source.

Release Requirements

Because there are "off the shelf" choices for this feature and to help guide discussion of the feature, I am listing the requirements as a table showing which of the choices currently offer each requirement. If a requirement is not presently met by a choice, that does not necessarily eliminate the choice from consideration. That just means that additional work will be required to make that choices a suitable one.

In the table below, "Built-in" refers to the editor that is already built in to Gecko.

Requirement	Built-in	Ace	Orion
License	Tri	Tri	BSD
Syntax Highlighting (HTML, JS, CSS)	No	Yes	TBD
Gutter with line numbers	No	Yes	Yes
Can set/display breakpoints	No	Yes	Yes
Robust international character support	Yes	No	Yes
RTL support	Yes	No	TBD
Accessible	Yes	No	TBD
Responsive editing, even for large files (20,000 lines)	TBD	Yes	Yes

Footnotes:

Desirable qualities, but not required initially:

Feature	Built-in	Ace	Orion
Code-oriented indentation(1)	No	Yes	Yes
Bracket/brace matching	No	Yes	Yes
Highlight current line	No	Yes	Yes
Highlight occurrences of word/symbol	No	Yes	No
Code folding	No	Yes(2)	No
Autocompletion	No	No	TBD
JavaScript syntax checking	No	Yes	No
Reconfigurable keybindings (vi/emacs possible)	No	Yes	No

Footnotes:

1. code oriented indentation means maintaining the indentation level from the previous line and ideally indenting automatically when a new block is started
2. "Unstructured" or "user" folding was just contributed during the week of April 25th

Note: CodeMirror 2 was also considered in the initial round. However, it appeared to have the same i18n and a10y downsides as Ace while lacking other desirable features.

Evaluating the Options

You can read the background section for further information leading up to our current evaluation status.

The short form of where we stand now:

• The built-in editor (contentEditable) must be a part of the solution, because it appears to be the only viable way to handle i18n and a10y needs sufficiently well
• A lot of work (not quantified, but you can get an idea looking at the list above) would be required to make the built-in editor a good code editor
• Ace has a good collection of features, but does not use contentEditable and therefore falls short in a10y and i18n
• Orion has a good start on features (though fewer than Ace), but is closer to our requirements for a10y and i18n

From a time-to-market perspective, Orion looks like the best choice. The only work we'd need to do to get started using it is:

1. work through differences between running in content and chrome
2. ensure that our integrated editor is sufficiently accessible

Over time, Orion would doubtless gain other features from our wishlist. It is an active Eclipse project. However, the Orion project is trying to do quite a bit and their editor component is only a slice of that. Features like code folding, word wrap and Ace's flexible key bindings are non-trivial.

The other option would be to incorporate Orion's editing/rendering model into Ace. That requires some amount of up-front work, but gives us a lot of features right away.

Therefore, the first step is to evaluate just how much work is likely required to merge the Orion input/rendering with the rest of Ace.

Julian Viereck's perspective:

Background: Julian Viereck was a Bespin contributor early in the project. In 2010, he continued working on Skywriter and was full-time on the project and other developer tools during the summer. He contributed word wrap and code folding to Ace in 2011. Julian knows Ace about as well as anyone. What follows is a paraphrasing of some of his thoughts after taking a look at Orion.

In a nutshell, Julian sees more work in taking Orion's rendering and input and merging that into Ace than adding some of Ace's nice features to Orion. Julian followed up with the following:

Basically, as soon as you go with the Orion rendering, you will need to relay on some other parts of Orion like the selection as well. This means, you won't need a lot of stuff that's in Ace. The only parts I see so far that can be reused from the current Ace codebase are the Modes/Syntax highlighting and some of the core infrastructure (keyboard handling etc). Therefore I think it's easier to add the missing features to Orion as instead moving a lot of Orion code on top of the Ace codebase but ignore big chunk of the Ace codebase and instead have to make sure everything is compatible between Orion and Ace.

He thinks that we should talk with the Orion people to get them to follow the same syntax highlighting modes "standard" that Skywriter/Ace/CodeMirror had adopted.

Regarding other features:

• The Skywriter/Ace keyboard mapping code that Julian developed is abstracted and should be possible to port for use with Orion.
• Word wrapping would be tricky, but is not the most important feature in a code editor
• Ace's code folding logic code probably move to Orion
• Features like moving text with the mouse might require changes to contentEditable (he's not sure about that one)
• Features like highlighting every occurrence of the selected word should be possible.

Regarding Code Folding, Julian added:

There is a good change to reuse the ACE code for folding, but I'm not sure how folding is implementable as soon as you start thinking of some text that goes from right to left. This means you can use the underlaying infrastructure of ACE but still will need some (maybe a lot) work to get things work in every situation as expected. Ace doesn't handle these edge cases which means it will need to get implemented in any case.

Regarding moving text with the mouse, Julian added:

The point was not that it might need changes to the contentEditable, but some work on getting text movement working in case of right to left text. Doing the implementation (remove some text here, add it later there) should be doable with what a contentEditable allows currently (from what I can tell so far).

Next Steps & Open Issues

• Solicit additional feedback for the plan on dev.platform (though this really belongs on dev-apps-firefox)
• Proceed with the evaluation
• Verify performance, i18n and a10y characteristics of proposed choice
• Security review of proposed choice

Background

In the dev.platform newsgroup, there were two threads with significant discussion about code editing approaches (1, 2). There was a followup meeting on May 9th in which we (devtools, a10y, Ehsan) discussed the options a bit further and the questions surrounding those options.

We came out of that meeting with some observations:

1. contentEditable is the only sane way to do text input, due to both a10y and i18n considerations
2. we may not need to use the editor for file viewing at stage 1
3. IBM claims that Orion is not fully accessible. dbolter has asked where it falls short.
4. Orion does some accessibility events okay: caret changes and text changes. Does not appear to work with screenreaders yet.
5. RTL works fine in Orion
6. While it may seem like syntax highlighting is a purely visual thing, the metadata for highlighting may be valuable for providing functions like jump-between-methods.
7. CodeMirror appears to have the same problems that Ace does, though without some of the features we want
8. code-oriented indentation is not a requirement for version 1, but tab key support is
9. We should consider the communities around Ace and Orion and how likely it is we can get what we need while working with those communities (FWIW, a10y is important in general to IBM and the Eclipse project)
10. Single long lines is a performance case we should consider, since minified files make this case more likely on the web in general than in normal day-to-day editing
11. Web Inspector appears to use a simple editor that is built into the webkit tree

We also had a couple of questions:

1. What are the requirements for accessibility? (dbolter to followup)
2. What are the performance characteristics of the various choices for our use cases?

1: Use of 3rd party projects 2: In-browser code editor

Using the User's Editor

The Firefox Add-on "It's All Text!" allows users to launch their editor of choice to edit the contents of any textarea. The external editor is launched with a temporary file and that file is reloaded into the textarea when the user returns to the browser. (I don't know if and when those files are cleaned up.)

The positive aspect of this approach is that the user can use the editor that they're already comfortable with and for which they've developed muscle memory. The downside is that there's no real integration between the developer tools and the editor. You can't, for example, set a breakpoint from within the editor or see CSS changes instantly in the browser.

A hybrid approach where editor plugins connect via a remote debugging protocol to the browser is possible, but would require considerable effort to create and maintain support for each editor. Even with that effort, it will be nearly impossible to provide the same level of integration with the developer tools even for a single editor.

Related Bugs & Dependencies

TBD