Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Use of 3rd party projects

81 views
Skip to first unread message

Joe Walker

unread,
Apr 26, 2011, 5:57:43 PM4/26/11
to dev-pl...@lists.mozilla.org

As part of Developer Tools, we'd like to make use of a 3rd party project
- Ace, in a similar way to SQLite, so I'm checking out what if anything
we need to do to make that happen.

Ace, grew out of the merger of Skywriter (a.k.a Bespin) with the Ace
editor. We would like to use it for displaying, and editing CSS,
Javascript, and HTML. We would also like to make use of the graphical
command line component in the Web Console.

Questions I anticipate people asking:
- What is the license of this code?:
Tri-license like normal Mozilla code

- How much code is there?
In total, about 40k lines (including comments, headers etc)

- Where is the code?
https://github.com/ajaxorg/ace and our fork
https://github.com/mozilla/ace along with
https://github.com/mozilla/cockpit

- What control does Mozilla have over the projects?
As a significant contributor to the project we can strongly
influence it's direction and can dictate what happens on our fork of the
repo

- Will we be up-streaming patches?
Yes! As key contributors...

- What unit testing is done on these projects?
Unit tests for these projects have been written. There are areas
where we will be adding more tests and we will be creating integration
tests for use in mozilla

- How frequently are releases made?
We can arrange releases to coincide with firefox releases

- What is the alternative?
Starting from scratch, or forking the project and losing the
benefits of a wider community

Thanks,

Joe.

Kyle Huey

unread,
Apr 26, 2011, 6:48:05 PM4/26/11
to Joe Walker, dev-pl...@lists.mozilla.org
My questions would be:

- How much of this code is dedicated to cross-browser compatibility (and
thus unnecessary when shipped in the product.) IIRC Panorama originally
used JQuery and we stripped out the bits we didn't care about and called it
iq or something like that. Since we are a "significant contributor" there
would be a tension here between avoiding shipping unnecessary code and
avoiding forking upstream that didn't really exist with JQuery ...

- How well tested is this code? "Unit tests for these projects have been
written" doesn't sound particularly encouraging. What is the general
quality of this code?

- IIRC Bespin used <canvas> for rendering. Is this still true? Does this
code handle localization, RTL, and accessibility correctly?

Those are the first ones that come to my mind.

- Kyle

On Tue, Apr 26, 2011 at 5:57 PM, Joe Walker <jwa...@mozilla.com> wrote:

>
> As part of Developer Tools, we'd like to make use of a 3rd party project -
> Ace, in a similar way to SQLite, so I'm checking out what if anything we
> need to do to make that happen.
>
> Ace, grew out of the merger of Skywriter (a.k.a Bespin) with the Ace
> editor. We would like to use it for displaying, and editing CSS, Javascript,
> and HTML. We would also like to make use of the graphical command line
> component in the Web Console.
>
> Questions I anticipate people asking:
> - What is the license of this code?:
> Tri-license like normal Mozilla code
>
> - How much code is there?
> In total, about 40k lines (including comments, headers etc)
>
> - Where is the code?

> https://github.com/ajaxorg/ace and our fork https://github.com/mozilla/acealong with


> https://github.com/mozilla/cockpit
>
> - What control does Mozilla have over the projects?
> As a significant contributor to the project we can strongly influence
> it's direction and can dictate what happens on our fork of the repo
>
> - Will we be up-streaming patches?
> Yes! As key contributors...
>
> - What unit testing is done on these projects?
> Unit tests for these projects have been written. There are areas where
> we will be adding more tests and we will be creating integration tests for
> use in mozilla
>
> - How frequently are releases made?
> We can arrange releases to coincide with firefox releases
>
> - What is the alternative?
> Starting from scratch, or forking the project and losing the benefits of
> a wider community
>
> Thanks,
>
> Joe.
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Joe Walker

unread,
Apr 27, 2011, 4:48:14 AM4/27/11
to dev-pl...@lists.mozilla.org
On Tue, Apr 26, 2011 at 23:48, Kyle Huey <m...@kylehuey.com> wrote:

> My questions would be:
>
> - How much of this code is dedicated to cross-browser compatibility (and
> thus unnecessary when shipped in the product.) IIRC Panorama originally
> used JQuery and we stripped out the bits we didn't care about and called it
> iq or something like that. Since we are a "significant contributor" there
> would be a tension here between avoiding shipping unnecessary code and
> avoiding forking upstream that didn't really exist with JQuery ...
>

There is a component called Pilot that does cross-browser, and shim type
stuff. There are 2 versions of this library, one designed for the web and
one for firefox. So in answer to your question: None of the code that would
ship.


> - How well tested is this code? "Unit tests for these projects have been
> written" doesn't sound particularly encouraging. What is the general
> quality of this code?
>

The general quality of the code is good. There are places where we know the
unit tests need improving, and we are working on that.

- IIRC Bespin used <canvas> for rendering. Is this still true? Does this
> code handle localization, RTL, and accessibility correctly?
>

Ace does not use canvas for rendering, it uses the DOM. There are areas both
for accessibility and l10n that we need to improve, and are working on that.

Joe.

Boris Zbarsky

unread,
Apr 27, 2011, 8:00:26 AM4/27/11
to
On 4/26/11 5:57 PM, Joe Walker wrote:
> Ace, grew out of the merger of Skywriter (a.k.a Bespin) with the Ace
> editor. We would like to use it for displaying, and editing CSS,
> Javascript, and HTML.

What are the benefits of doing this over using our built-in editor?

-Boris

Kevin Dangoor

unread,
Apr 27, 2011, 9:00:17 AM4/27/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org

Syntax highlighting, proper handling of indentation, keyboard remapping, paren matching, line numbers in the gutter (plus the gutter can handle breakpoints, errors and the like) and Julian Viereck just contributed the main part of a code folding implementation.

Basically, Ace has many of the features one wants out of a code editor rather than a plain text editor.

Kevin

Benjamin Smedberg

unread,
Apr 27, 2011, 9:58:08 AM4/27/11
to Kyle Huey, Joe Walker, dev-pl...@lists.mozilla.org
On 4/26/2011 6:48 PM, Kyle Huey wrote:

I don't think the important question here is "can we use a 3rd-party
project": the license is compatible, we can use it. The question is more
whether this feature is worth the costs, and whether the project meets
all our standards of code in general. Accessibility seems like it would
be a big problem with a canvas-based editor, but we'd also need to
evaluate the testing infrastructure and actual testsuite.

Obviously it's not ideal to end up with two editors in the tree,
although as I understand it the point of the Ace editor is solely
text/code editing, and mozilla's builtin editor is primarily geared
towards WYSIWYG-type editing.

--BDS

Mike Hommey

unread,
Apr 27, 2011, 10:05:44 AM4/27/11
to dev-pl...@lists.mozilla.org, Joe Walker

Which leads to the additional question: why does it need to be in
our tree? a.k.a. why not an extension?

Mike

Joe Walker

unread,
Apr 27, 2011, 10:13:34 AM4/27/11
to dev-pl...@lists.mozilla.org
Take "can we use a 3rd-party project" in the sense of - "here's a proposal,
what questions/objections does anyone have".

As is noted elsewhere, Ace isn't canvas based. This doesn't guarantee that
it is accessible however and we have identified some accessibility work that
needs doing, and obviously we would not want to ship an inaccessible part of
devtools.

Also to add to Kevin's list, performance with very large source pages is
something that Ace was very much designed to handle from the ground up.

Joe.

On Wed, Apr 27, 2011 at 14:58, Benjamin Smedberg <benj...@smedbergs.us>wrote:

> On 4/26/2011 6:48 PM, Kyle Huey wrote:
>
> I don't think the important question here is "can we use a 3rd-party
> project": the license is compatible, we can use it. The question is more
> whether this feature is worth the costs, and whether the project meets all
> our standards of code in general. Accessibility seems like it would be a big
> problem with a canvas-based editor, but we'd also need to evaluate the
> testing infrastructure and actual testsuite.
>
> Obviously it's not ideal to end up with two editors in the tree, although
> as I understand it the point of the Ace editor is solely text/code editing,
> and mozilla's builtin editor is primarily geared towards WYSIWYG-type
> editing.
>

> --BDS

Rob Campbell

unread,
Apr 27, 2011, 10:36:25 AM4/27/11
to Benjamin Smedberg, Kyle Huey, dev-pl...@lists.mozilla.org, Joe Walker

On 2011-04-27, at 10:58 , Benjamin Smedberg wrote:

> On 4/26/2011 6:48 PM, Kyle Huey wrote:
>
> I don't think the important question here is "can we use a 3rd-party project": the license is compatible, we can use it. The question is more whether this feature is worth the costs, and whether the project meets all our standards of code in general. Accessibility seems like it would be a big problem with a canvas-based editor, but we'd also need to evaluate the testing infrastructure and actual testsuite.

Not canvas-based, though there may still be a11y issues, aiui.

> Obviously it's not ideal to end up with two editors in the tree, although as I understand it the point of the Ace editor is solely text/code editing, and mozilla's builtin editor is primarily geared towards WYSIWYG-type editing.

These editors serve two very different purposes. Our in-tree editor is, as you say, geared towards WYSIWYG editing of HTML.

Ace would be used in a number of areas, possibly including but not-limited to:
• View Source
• HTML (source) editing
• CSS editing
• JS editing
• Debugger script view
• Plain text editing

What did I miss?

We have big plans for these features and I think there is a strong case for the amount of re-use we'll see from having a strong, pleasant-to-use text editor in our codebase.

~ rob

Asa Dotzler

unread,
Apr 27, 2011, 12:24:00 PM4/27/11
to
On 4/27/2011 7:36 AM, Rob Campbell wrote:

> We have big plans for these features and I think there is a strong case for the amount of re-use we'll see from having a strong, pleasant-to-use text editor in our codebase.

Can this "rich" editor be exposed to the Web? Might be nice to let sites
use it in place of the simple text editor they get from browsers today.

- A

Benjamin Smedberg

unread,
Apr 27, 2011, 12:31:14 PM4/27/11
to Asa Dotzler, dev-pl...@lists.mozilla.org
This editor is written entirely using web technologies, so it basically
already is exposed.

--BDS

Shawn Wilsher

unread,
Apr 27, 2011, 12:40:39 PM4/27/11
to dev-pl...@lists.mozilla.org
On 4/27/2011 9:24 AM, Asa Dotzler wrote:
> Can this "rich" editor be exposed to the Web? Might be nice to let sites
> use it in place of the simple text editor they get from browsers today.
Please, let's not diverge this thread and keep the discussion limited to
what issues would prevent us from taking this library. Thanks!

Cheers,

Shawn

david bolter

unread,
Apr 27, 2011, 2:17:09 PM4/27/11
to Rob Campbell, Kyle Huey, Benjamin Smedberg, dev-pl...@lists.mozilla.org, Joe Walker
Since we're gathering concerns...

I'm concerned about the accessibility work involved. The last time I tested
the Ace editor it seemed to have an off-screen text input/area where the
keyboard focus really sat, while divs and spans where mutated in the visible
'editor' on the page. The text area was just a place to collect/buffer
keyboard events (I think). This feels a bit hacky. I think we can probably
get half-way accessibility without too much trouble via aria-*, but I'm less
sure about caret navigation and events, as well as exposure of accessible
text and selection interfaces. Could be a lot of work. It might be that the
off-screen text area becomes the source for exposure of caret and accessible
text, but investigating how feasible that is hasn't happened yet I don't
think.

Note: the text entry caret that gets blinked in the visible part of the
'editor' is just a span or something if I recall correctly.

Cheers,
David

> We have big plans for these features and I think there is a strong case for
> the amount of re-use we'll see from having a strong, pleasant-to-use text
> editor in our codebase.
>

> ~ rob

Kevin Dangoor

unread,
Apr 27, 2011, 2:43:17 PM4/27/11
to david bolter, Kyle Huey, Benjamin Smedberg, dev-pl...@lists.mozilla.org, Joe Walker, Rob Campbell
On Wed, Apr 27, 2011 at 2:17 PM, david bolter <david....@gmail.com>wrote:

> Since we're gathering concerns...
>
> I'm concerned about the accessibility work involved.


I can see a couple possible ways to deal with accessibility that avoid the
hard issues you cite.

1. offer textarea as an option

Anywhere that Ace appears could just have a textarea instead. This should
work, but is not optimal because you'd lose nice features like the saner
indentation handling

2. offer Eclipse Orion as an option via an add-on

The Orion editor just came out last month. As I understand it, but we could
use your help in verifying this, Orion is based on content editable which
should take care of cursor position, selection and such. I believe that
accessibility is one of IBM's explicit goals in backing Orion within the
Eclipse organization. Orion does not have quite as many features as Ace, I
don't think it's quite as fast and the code has to deal with complexity
around content editable, but it is still a viable code editor and nicer than
a textarea.

http://www.eclipse.org/orion/

Kevin

--
Kevin Dangoor

work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com

Justin Wood (Callek)

unread,
Apr 27, 2011, 10:06:45 PM4/27/11
to
On 4/27/2011 2:43 PM, Kevin Dangoor wrote:
> 2. offer Eclipse Orion as an option via an add-on

IMO, we should NOT require an addon to make a11y support usable. At
least not for built in features/windows/etc.

Why should we expect a disabled user to install an addon (that is much
harder to discover) because he wants to be able to use View Source
correctly/at-all?

--
~Justin Wood (Callek)

Shawn Wilsher

unread,
Apr 28, 2011, 2:34:26 AM4/28/11
to dev-pl...@lists.mozilla.org
On 4/27/2011 7:06 PM, Justin Wood (Callek) wrote:
> Why should we expect a disabled user to install an addon (that is much
> harder to discover) because he wants to be able to use View Source
> correctly/at-all?
Just to be clear, this isn't about View Source.

Cheers,

Shawn

Joe Walker

unread,
Apr 28, 2011, 3:36:21 AM4/28/11
to dev-pl...@lists.mozilla.org
So - we have a clear need to ensure that Ace is accessible (and localized,
with unit tests, etc). This is something that we've known about and been
talking about for some time - and will get fixed, properly, before we ship.

The point of this thread really is to avoid surprises when we finally ask
for review for inclusion into central. I don't want to be in a position of
discovering, too late, that we can't use Ace as an editor, or that we can't
use the command line component in the web console - for some currently
unforeseen reason.

We've explored things like code size, licensing, similarity with existing
code, etc, and we have some obvious work to do. It seems now that we need to
get on with that work.

Joe.

Jean-Marc Desperrier

unread,
Apr 28, 2011, 10:07:36 AM4/28/11
to
Rob Campbell wrote:
>> mozilla's builtin editor is primarily geared towards WYSIWYG-type editing.
> These editors serve two very different purposes. Our in-tree editor
> is, as you say, geared towards WYSIWYG editing of HTML.

In my opinion, the best choice by far could be that it'd replace the
existing in-tree editor, on the long term.

Currently https://wiki.mozilla.org/Modules/Core says the Core::Editor
component has no owner.
I believe that correctly reflects it's current state.

In it's use within Thunderbird, they are awful bugs that haven't been
solved for years.
Actually, Thunderbird's Message Compose Window component has no owner
either.

Benjamin Smedberg

unread,
Apr 28, 2011, 10:27:29 AM4/28/11
to Jean-Marc Desperrier, dev-pl...@lists.mozilla.org
On 4/28/2011 10:07 AM, Jean-Marc Desperrier wrote:
> Rob Campbell wrote:
>>> mozilla's builtin editor is primarily geared towards WYSIWYG-type
>>> editing.
>> These editors serve two very different purposes. Our in-tree editor
>> is, as you say, geared towards WYSIWYG editing of HTML.
>
> In my opinion, the best choice by far could be that it'd replace the
> existing in-tree editor, on the long term.
That's very off-topic, and not at all practical: the imported editor is
a plaintext editor, not a WYSIWYG editor, and is not at all suitable as
a replacement for an HTML editor.

> Currently https://wiki.mozilla.org/Modules/Core says the Core::Editor
> component has no owner.
> I believe that correctly reflects it's current state.

Ehsan recently has been patching and maintaining that code, and probably
ought to be nominated to own it.

--BDS

Rob Campbell

unread,
Apr 28, 2011, 1:14:03 PM4/28/11
to Benjamin Smedberg, Jean-Marc Desperrier, dev-pl...@lists.mozilla.org

On 2011-04-28, at 11:27 , Benjamin Smedberg wrote:

> On 4/28/2011 10:07 AM, Jean-Marc Desperrier wrote:

>> Rob Campbell wrote:
>>>> mozilla's builtin editor is primarily geared towards WYSIWYG-type editing.
>>> These editors serve two very different purposes. Our in-tree editor
>>> is, as you say, geared towards WYSIWYG editing of HTML.
>>
>> In my opinion, the best choice by far could be that it'd replace the existing in-tree editor, on the long term.

> That's very off-topic, and not at all practical: the imported editor is a plaintext editor, not a WYSIWYG editor, and is not at all suitable as a replacement for an HTML editor.

Yep. I was going to reply to that effect but Benjamin beat me to it.

>> Currently https://wiki.mozilla.org/Modules/Core says the Core::Editor component has no owner.
>> I believe that correctly reflects it's current state.

> Ehsan recently has been patching and maintaining that code, and probably ought to be nominated to own it.

Seconded. He's done some great work during his editor bug rampage of 2010. I think he'd be a fantastic owner if he's interested.

~ rob

Ehsan Akhgari

unread,
Apr 28, 2011, 1:28:43 PM4/28/11
to Kevin Dangoor, Boris Zbarsky, dev-pl...@lists.mozilla.org
On 11-04-27 9:00 AM, Kevin Dangoor wrote:
> On Wednesday, April 27, 2011 at 8:00 AM, Boris Zbarsky wrote:
> Syntax highlighting, proper handling of indentation, keyboard remapping, paren matching, line numbers in the gutter (plus the gutter can handle breakpoints, errors and the like) and Julian Viereck just contributed the main part of a code folding implementation.
>
> Basically, Ace has many of the features one wants out of a code editor rather than a plain text editor.

Let's not forget that it doesn't have many of the features that we
should expect from any text editor. From a quick (<1 min) test that I
did on its demo page, here is a list of stuff that it doesn't support:

* Bidirectional text handling
* Handling of ligatures and compound forms
* Correct caret navigation

And I'm sure that I could find more stuff like these. I don't think
that going through this route is necessarily what we want to do, because
that means that we should reimplement a lot of stuff that Gecko already
supports. I can't see why any of the features you quotes could not be
implemented on top of the Gecko HTML editor.

Cheers,
Ehsan

Ehsan Akhgari

unread,
Apr 28, 2011, 1:49:56 PM4/28/11
to Joe Walker, dev-pl...@lists.mozilla.org
On 11-04-28 3:36 AM, Joe Walker wrote:
> So - we have a clear need to ensure that Ace is accessible (and localized,
> with unit tests, etc). This is something that we've known about and been
> talking about for some time - and will get fixed, properly, before we ship.

These are _not_ the only issues that we need to solve. I strongly
object for us to include any code in mozilla-central which only
addresses the needs of some of our users and not the others. I'm
specifically worried about users speaking some European languages which
use accents and such a lot, and also users speaking right to left
languages. But the accessibility concerns are real and should be
addressed before the code is supposed to be included in a Firefox release.

> The point of this thread really is to avoid surprises when we finally ask
> for review for inclusion into central. I don't want to be in a position of
> discovering, too late, that we can't use Ace as an editor, or that we can't
> use the command line component in the web console - for some currently
> unforeseen reason.

In order to reach this objective, we should first gather a list of
current issues with the ACE editor. Reading this thread, I'm far from
convinced that the people advocating its usage have came up with such a
list.

> We've explored things like code size, licensing, similarity with existing
> code, etc, and we have some obvious work to do. It seems now that we need to
> get on with that work.

As I said above, these are only part of the inclusion requirements.
There are a lot of tough technical challenges to be addressed yet.

Cheers,
Ehsan

Ehsan Akhgari

unread,
Apr 28, 2011, 1:54:42 PM4/28/11
to Rob Campbell, Jean-Marc Desperrier, Benjamin Smedberg, dev-pl...@lists.mozilla.org
On 11-04-28 1:14 PM, Rob Campbell wrote:
>
> On 2011-04-28, at 11:27 , Benjamin Smedberg wrote:
>
>> On 4/28/2011 10:07 AM, Jean-Marc Desperrier wrote:
>>> Rob Campbell wrote:
>>>>> mozilla's builtin editor is primarily geared towards WYSIWYG-type editing.
>>>> These editors serve two very different purposes. Our in-tree editor
>>>> is, as you say, geared towards WYSIWYG editing of HTML.
>>>
>>> In my opinion, the best choice by far could be that it'd replace the existing in-tree editor, on the long term.
>> That's very off-topic, and not at all practical: the imported editor is a plaintext editor, not a WYSIWYG editor, and is not at all suitable as a replacement for an HTML editor.
>
> Yep. I was going to reply to that effect but Benjamin beat me to it.

This is one of the reasons that I don't like the term WYSIWIG (as
opposed to plaintext editor). The Ace editor is definitely not a
plaintext editor. It is an HTML editor, built on top of the DOM APIs.
We do have an implementation of an HTML editor in our tree (which _can_
be used as a WYSIWIG editor, but is not limited to that).

>>> Currently https://wiki.mozilla.org/Modules/Core says the Core::Editor component has no owner.
>>> I believe that correctly reflects it's current state.

>> Ehsan recently has been patching and maintaining that code, and probably ought to be nominated to own it.
>
> Seconded. He's done some great work during his editor bug rampage of 2010. I think he'd be a fantastic owner if he's interested.

I certainly don't object to being the owner of the editor component (I
didn't know if it matters, and how to approach it), but I think this is
off-topic for this thread. The important thing to know is there is
somebody working on this code. :-)

Cheers,
Ehsan

Ehsan Akhgari

unread,
Apr 28, 2011, 2:01:17 PM4/28/11
to david bolter, Kyle Huey, Benjamin Smedberg, dev-pl...@lists.mozilla.org, Joe Walker, Rob Campbell
On 11-04-27 2:17 PM, david bolter wrote:
> Since we're gathering concerns...
>
> I'm concerned about the accessibility work involved. The last time I tested
> the Ace editor it seemed to have an off-screen text input/area where the
> keyboard focus really sat, while divs and spans where mutated in the visible
> 'editor' on the page. The text area was just a place to collect/buffer
> keyboard events (I think). This feels a bit hacky. I think we can probably
> get half-way accessibility without too much trouble via aria-*, but I'm less
> sure about caret navigation and events, as well as exposure of accessible
> text and selection interfaces. Could be a lot of work. It might be that the
> off-screen text area becomes the source for exposure of caret and accessible
> text, but investigating how feasible that is hasn't happened yet I don't
> think.
>
> Note: the text entry caret that gets blinked in the visible part of the
> 'editor' is just a span or something if I recall correctly.

Here is how Ace roughly works. It has a number of overlayed DIVs on top
of each other. The bottom-most is the text layer, which is a DIV
containing DOM nodes which represent the text displayed on the screen,
with highlighted words being wrapped in spans with the correct class name.

It has one layer to show selections using divs with a semi-opaque
background, one layer to show things like bracket matching highlights,
and one layer to show the caret (using a DOM node being moved on the
screen).

For keyboard event handling, it uses an invisible focused textarea which
moves on the screen to always be at the same place as the selection.

This means that things which rely on Gecko provided facilities such as
selection, and caret will not work with Ace. Accessibility is a big
example.

Cheers,
Ehsan

Rob Campbell

unread,
Apr 28, 2011, 3:42:28 PM4/28/11
to dev-pl...@lists.mozilla.org
On 2011-04-28, at 14:54, Ehsan Akhgari wrote:

> On 11-04-28 1:14 PM, Rob Campbell wrote:
>>
>> On 2011-04-28, at 11:27 , Benjamin Smedberg wrote:
>>
>>> On 4/28/2011 10:07 AM, Jean-Marc Desperrier wrote:

>>>> Rob Campbell wrote:
>>>>>> mozilla's builtin editor is primarily geared towards WYSIWYG-type editing.
>>>>> These editors serve two very different purposes. Our in-tree editor
>>>>> is, as you say, geared towards WYSIWYG editing of HTML.
>>>>
>>>> In my opinion, the best choice by far could be that it'd replace the existing in-tree editor, on the long term.

>>> That's very off-topic, and not at all practical: the imported editor is a plaintext editor, not a WYSIWYG editor, and is not at all suitable as a replacement for an HTML editor.
>>
>> Yep. I was going to reply to that effect but Benjamin beat me to it.
>
> This is one of the reasons that I don't like the term WYSIWIG (as
> opposed to plaintext editor). The Ace editor is definitely not a
> plaintext editor. It is an HTML editor, built on top of the DOM APIs.
> We do have an implementation of an HTML editor in our tree (which _can_
> be used as a WYSIWIG editor, but is not limited to that).

Ace isn't "plaintext", it's a code editor. For writing and displaying code. It has features such as line numbering and syntax-highlighting.

Can the in-tree editor show gutters with line-numbers and do syntax highlighting? If not, I'm sure they could be added, but at what cost? How long would it take?

There are other good reasons to include a JS-based editor as well but I'll let Kevin comment to that.

>>> Ehsan recently has been patching and maintaining that code, and probably ought to be nominated to own it.
>>
>> Seconded. He's done some great work during his editor bug rampage of 2010. I think he'd be a fantastic owner if he's interested.
>
> I certainly don't object to being the owner of the editor component (I
> didn't know if it matters, and how to approach it), but I think this is
> off-topic for this thread. The important thing to know is there is
> somebody working on this code. :-)

Yeah, off-topic, and it is indeed good to know that you're working on it. I figured a little buttering-up couldn't hurt our case. ;)

~ rob

Rob Campbell

unread,
Apr 28, 2011, 3:46:35 PM4/28/11
to dev-pl...@lists.mozilla.org
We have an alternate: Eclipse's Orion editor is another project that we could use. Kevin Dangoor mentioned it earlier and suggested it as an add-on. Callek rightly suggested that we shouldn't be offering accessibility as an add-on if at all possible.

Ehsan, I'd be very curious to hear of any concerns you might have about Orion, if you have the time.

http://www.eclipse.org/orion/

~ rob

Ehsan Akhgari

unread,
Apr 28, 2011, 4:07:23 PM4/28/11
to Rob Campbell, dev-pl...@lists.mozilla.org
On 11-04-28 3:46 PM, Rob Campbell wrote:
> We have an alternate: Eclipse's Orion editor is another project that we could use. Kevin Dangoor mentioned it earlier and suggested it as an add-on. Callek rightly suggested that we shouldn't be offering accessibility as an add-on if at all possible.
>
> Ehsan, I'd be very curious to hear of any concerns you might have about Orion, if you have the time.
>
> http://www.eclipse.org/orion/

>From a quick look, Orion is using the Gecko HTML editor under the hood,
which means that a lot of the basic stuff which doesn't work correctly
in Ace works properly in Orion because it's letting Gecko handle stuff
(I haven't tested any accessibility stuff of course).

But I think we're approaching the problem in a strange way. I think
it's best for the devtools team to come up with a set of requirements on
what they want from an editor, and then we can move from there to decide
whether we should just extend the HTML editor in Gecko, use a Javascript
wrapper on top of it (like Orion) or just roll our own from scratch
(like Ace).

What do you think?

Ehsan

Boris Zbarsky

unread,
Apr 28, 2011, 4:18:20 PM4/28/11
to
On 4/28/11 3:46 PM, Rob Campbell wrote:
> We have an alternate: Eclipse's Orion editor is another project that we could use. Kevin Dangoor mentioned it earlier and suggested it as an add-on. Callek rightly suggested that we shouldn't be offering accessibility as an add-on if at all possible.
>
> Ehsan, I'd be very curious to hear of any concerns you might have about Orion, if you have the time.

For what it's worth,
http://lists.w3.org/Archives/Public/public-html/2011Apr/0714.html has
some things that are worth bearing in mind as something to test in any
editor we consider here....

-Boris

Ehsan Akhgari

unread,
Apr 28, 2011, 4:20:47 PM4/28/11
to Rob Campbell, dev-pl...@lists.mozilla.org
On 11-04-28 3:42 PM, Rob Campbell wrote:
> On 2011-04-28, at 14:54, Ehsan Akhgari wrote:
>
>> On 11-04-28 1:14 PM, Rob Campbell wrote:
>>>
>>> On 2011-04-28, at 11:27 , Benjamin Smedberg wrote:
>>>
>>>> On 4/28/2011 10:07 AM, Jean-Marc Desperrier wrote:
>>>>> Rob Campbell wrote:
>>>>>>> mozilla's builtin editor is primarily geared towards WYSIWYG-type editing.
>>>>>> These editors serve two very different purposes. Our in-tree editor
>>>>>> is, as you say, geared towards WYSIWYG editing of HTML.
>>>>>
>>>>> In my opinion, the best choice by far could be that it'd replace the existing in-tree editor, on the long term.
>>>> That's very off-topic, and not at all practical: the imported editor is a plaintext editor, not a WYSIWYG editor, and is not at all suitable as a replacement for an HTML editor.
>>>
>>> Yep. I was going to reply to that effect but Benjamin beat me to it.
>>
>> This is one of the reasons that I don't like the term WYSIWIG (as
>> opposed to plaintext editor). The Ace editor is definitely not a
>> plaintext editor. It is an HTML editor, built on top of the DOM APIs.
>> We do have an implementation of an HTML editor in our tree (which _can_
>> be used as a WYSIWIG editor, but is not limited to that).
>
> Ace isn't "plaintext", it's a code editor. For writing and displaying code. It has features such as line numbering and syntax-highlighting.

For sure, that is what I was asserting. Benjamin said that it's a
plaintext editor and I thought you're implicitly agreeing.

> Can the in-tree editor show gutters with line-numbers and do syntax highlighting? If not, I'm sure they could be added, but at what cost? How long would it take?

The Gecko HTML editor allows the user to edit DOM nodes using mouse and
keyboard events, and also provides a set of APIs for doing some editing
operations. Things like gutters are separate DOM nodes, and they don't
have any relationship with the editor (look at Orion's DOM for example,
it uses a separate <table> for the gutter area).

Syntax highlighting is usually about wrapping stuff in span tags (with
class attributes possibly). The editor doesn't expose any commands to
do that, but that can be worked around either by adding a suitable
command or just using the DOM APIs.

Cheers,
Ehsan

Rob Campbell

unread,
Apr 28, 2011, 4:42:37 PM4/28/11
to dev-pl...@lists.mozilla.org

On 2011-04-28, at 17:07, Ehsan Akhgari wrote:

> On 11-04-28 3:46 PM, Rob Campbell wrote:
>> We have an alternate: Eclipse's Orion editor is another project that we could use. Kevin Dangoor mentioned it earlier and suggested it as an add-on. Callek rightly suggested that we shouldn't be offering accessibility as an add-on if at all possible.
>>
>> Ehsan, I'd be very curious to hear of any concerns you might have about Orion, if you have the time.
>>

>> http://www.eclipse.org/orion/
>
> From a quick look, Orion is using the Gecko HTML editor under the hood,
> which means that a lot of the basic stuff which doesn't work correctly
> in Ace works properly in Orion because it's letting Gecko handle stuff
> (I haven't tested any accessibility stuff of course).

Yeah, my quick assessment as well. Int'l keys (accented characters) seem to work well. It did feel a little clunky when scrolling, so not sure how performant it is.

>
> But I think we're approaching the problem in a strange way. I think
> it's best for the devtools team to come up with a set of requirements on
> what they want from an editor, and then we can move from there to decide
> whether we should just extend the HTML editor in Gecko, use a Javascript
> wrapper on top of it (like Orion) or just roll our own from scratch
> (like Ace).
>
> What do you think?

I think we're approaching the problem from the angle of, "we've got this code over here that we'd like to use that will suit our purposes quite nicely". Not, "let's try to re-invent the wheel all over again".

This discussion's morphed from, "How do we get 3rd party projects" into our code-base to one of discussing feature-requirements and implementation planning. Not really where we wanted to go, but we can have that discussion as well.

~ rob

Rob Campbell

unread,
Apr 28, 2011, 4:45:32 PM4/28/11
to dev-pl...@lists.mozilla.org

That's a good list. Pasting here for reference:

> Mouse placement of the caret has to be reimplemented. + +
> Keyboard movement of the caret has to be reimplemented (possibly across
> lines, for multiline text input). + +
> Scrolling of the text field has to be implemented (horizontally for long
> lines, vertically for multiline input). + +
> Native features such as copy-and-paste have to be reimplemented. + +
> Native features such as spell-checking have to be reimplemented. + +
> Native features such as drag-and-drop have to be reimplemented. + +
> Native features specific to the user, for example custom text + services,
> have to be reimplemented. This is close to impossible + since each user
> might have different services installed, and there + is an unbounded set of
> possible such services. + +
> Bidirectional text editing has to be reimplemented. + +
> Text selection has to be reimplemented. + +
> Dragging of bidirectional text selections has to be reimplemented. + +
> Platform-native keyboard shortcuts have to be reimplemented. + +
> Platform-native input method editors (IMEs) have to be reimplemented. + +
> Undo and redo functionality has to be reimplemented. + +
> Accessibility features such as magnification following the + caret or
> selection have to be reimplemented. + +

~ rob

Ehsan Akhgari

unread,
Apr 28, 2011, 4:49:26 PM4/28/11
to Rob Campbell, dev-pl...@lists.mozilla.org
On 11-04-28 4:45 PM, Rob Campbell wrote:
>
> On 2011-04-28, at 17:18, Boris Zbarsky wrote:
>
> That's a good list. Pasting here for reference:
>
>> Mouse placement of the caret has to be reimplemented. + +
>> Keyboard movement of the caret has to be reimplemented (possibly across
>> lines, for multiline text input). + +
>> Scrolling of the text field has to be implemented (horizontally for long
>> lines, vertically for multiline input). + +
>> Native features such as copy-and-paste have to be reimplemented. + +
>> Native features such as spell-checking have to be reimplemented. + +
>> Native features such as drag-and-drop have to be reimplemented. + +
>> Native features specific to the user, for example custom text + services,
>> have to be reimplemented. This is close to impossible + since each user
>> might have different services installed, and there + is an unbounded set of
>> possible such services. + +
>> Bidirectional text editing has to be reimplemented. + +
>> Text selection has to be reimplemented. + +
>> Dragging of bidirectional text selections has to be reimplemented. + +
>> Platform-native keyboard shortcuts have to be reimplemented. + +
>> Platform-native input method editors (IMEs) have to be reimplemented. + +
>> Undo and redo functionality has to be reimplemented. + +
>> Accessibility features such as magnification following the + caret or
>> selection have to be reimplemented. + +

Another thing which is worth quoting IMHO:

> In general, you should never implement a text editor yourself. It's a
> silly amount of work that the browsers have already done for you.

Cheers,
Ehsan

Rob Campbell

unread,
Apr 28, 2011, 4:52:05 PM4/28/11
to Ehsan Akhgari, dev-pl...@lists.mozilla.org
On 2011-04-28, at 17:20, Ehsan Akhgari wrote:

> On 11-04-28 3:42 PM, Rob Campbell wrote:
>> On 2011-04-28, at 14:54, Ehsan Akhgari wrote:
>>
>>> On 11-04-28 1:14 PM, Rob Campbell wrote:
>>>>
>>>> On 2011-04-28, at 11:27 , Benjamin Smedberg wrote:
>>>>
>>>>> On 4/28/2011 10:07 AM, Jean-Marc Desperrier wrote:

>>>>>> Rob Campbell wrote:
>>>>>>>> mozilla's builtin editor is primarily geared towards WYSIWYG-type editing.
>>>>>>> These editors serve two very different purposes. Our in-tree editor
>>>>>>> is, as you say, geared towards WYSIWYG editing of HTML.
>>>>>>
>>>>>> In my opinion, the best choice by far could be that it'd replace the existing in-tree editor, on the long term.

>>>>> That's very off-topic, and not at all practical: the imported editor is a plaintext editor, not a WYSIWYG editor, and is not at all suitable as a replacement for an HTML editor.
>>>>
>>>> Yep. I was going to reply to that effect but Benjamin beat me to it.
>>>
>>> This is one of the reasons that I don't like the term WYSIWIG (as
>>> opposed to plaintext editor). The Ace editor is definitely not a
>>> plaintext editor. It is an HTML editor, built on top of the DOM APIs.
>>> We do have an implementation of an HTML editor in our tree (which _can_
>>> be used as a WYSIWIG editor, but is not limited to that).
>>
>> Ace isn't "plaintext", it's a code editor. For writing and displaying code. It has features such as line numbering and syntax-highlighting.
>
> For sure, that is what I was asserting. Benjamin said that it's a
> plaintext editor and I thought you're implicitly agreeing.

It's plaintext in the sense that we're editing lines in monotype fonts, we're not doing rich-text editing with styles and document structure.

>> Can the in-tree editor show gutters with line-numbers and do syntax highlighting? If not, I'm sure they could be added, but at what cost? How long would it take?
>
> The Gecko HTML editor allows the user to edit DOM nodes using mouse and
> keyboard events, and also provides a set of APIs for doing some editing
> operations. Things like gutters are separate DOM nodes, and they don't
> have any relationship with the editor (look at Orion's DOM for example,
> it uses a separate <table> for the gutter area).

Yes, I'm familiar with the contenteditable editor and some of its capabilities (and limitations). Those were rhetorical questions.

We'd have to do an analysis of how much work it would be to implement all of the editing features of a code editor like ace or orion using contenteditable.

> Syntax highlighting is usually about wrapping stuff in span tags (with
> class attributes possibly). The editor doesn't expose any commands to
> do that, but that can be worked around either by adding a suitable
> command or just using the DOM APIs.

Yep. It might be possible to lift one of the syntax highlighting engines out of ace (or orion or codemirror or whatever) and apply it to a contenteditable editor, but all of this is missing the point...

We have editors available, can we use one of them?

~ rob

Boris Zbarsky

unread,
Apr 28, 2011, 4:52:34 PM4/28/11
to
On 4/28/11 4:42 PM, Rob Campbell wrote:
> It did feel a little clunky when scrolling, so not sure how performant it is.

https://bugzilla.mozilla.org/show_bug.cgi?id=638452 has some numbers for
that particular operation if you care.

We have upcoming changes to layout code that will help, hopefully in the
next-6-months timeframe.

> I think we're approaching the problem from the angle of, "we've got this code over here that we'd like to use that will suit our purposes quite nicely"

Well, except for the various ways in which it doesn't that Ehsan brought
up. ;)

-Boris

Rob Campbell

unread,
Apr 28, 2011, 4:54:45 PM4/28/11
to dev-pl...@lists.mozilla.org

On 2011-04-28, at 17:49, Ehsan Akhgari wrote:

[...]


>
> Another thing which is worth quoting IMHO:
>
>> In general, you should never implement a text editor yourself. It's a
>> silly amount of work that the browsers have already done for you.

I'm with you there.

~ rob

PS, my last post I said, "we have editors, we'd like to use one of them", it should have been more like, "we have this code, can we use it?" We got kind of side-lined on the editor issue when joe's original comment was asking about 3rd party code/projects. Sorry, Joe!

Ehsan Akhgari

unread,
Apr 28, 2011, 4:58:39 PM4/28/11
to Rob Campbell, dev-pl...@lists.mozilla.org
On 11-04-28 4:42 PM, Rob Campbell wrote:
>
> On 2011-04-28, at 17:07, Ehsan Akhgari wrote:

>
>> On 11-04-28 3:46 PM, Rob Campbell wrote:
>>> We have an alternate: Eclipse's Orion editor is another project that we could use. Kevin Dangoor mentioned it earlier and suggested it as an add-on. Callek rightly suggested that we shouldn't be offering accessibility as an add-on if at all possible.
>>>
>>> Ehsan, I'd be very curious to hear of any concerns you might have about Orion, if you have the time.
>>>
>>> http://www.eclipse.org/orion/
>>
>> From a quick look, Orion is using the Gecko HTML editor under the hood,
>> which means that a lot of the basic stuff which doesn't work correctly
>> in Ace works properly in Orion because it's letting Gecko handle stuff
>> (I haven't tested any accessibility stuff of course).
>
> Yeah, my quick assessment as well. Int'l keys (accented characters) seem to work well. It did feel a little clunky when scrolling, so not sure how performant it is.

I noticed some weird scrolling behavior when cutting/deleting/editing
text...

>> But I think we're approaching the problem in a strange way. I think
>> it's best for the devtools team to come up with a set of requirements on
>> what they want from an editor, and then we can move from there to decide
>> whether we should just extend the HTML editor in Gecko, use a Javascript
>> wrapper on top of it (like Orion) or just roll our own from scratch
>> (like Ace).
>>
>> What do you think?
>
> I think we're approaching the problem from the angle of, "we've got this code over here that we'd like to use that will suit our purposes quite nicely". Not, "let's try to re-invent the wheel all over again".

The way I see it, if we're talking about Ace, this is the current
status: "we've got this code over here which works for the simplest
possible case, and we'd like to use it, but we can't, since it doesn't
address many of our needs at all". For Orion, this is the current
status: "we've got this code over here, which seems to work, but we
still need to investigate whether it addresses all of our needs, before
we decide whether we can use it". And the question that I'm proposing
is: "is it worth for us to invest time in improving a third-party
library, compared to improving our in-tree editor to do what we want",
and in order to answer this, we need to know what we want. At least,
_I_ need to know what we want. :-)

> This discussion's morphed from, "How do we get 3rd party projects" into our code-base to one of discussing feature-requirements and implementation planning. Not really where we wanted to go, but we can have that discussion as well.

I think we should have had this discussion before, but I'm really glad
that we had it now instead of a few months later. I hope I've managed
to explain some of the reasons why Ace is not a useful solution for us,
no matter what its license is, what its size is, and if we contribute to
it or not, and how its testing and release works (which were the points
raised in the original post in this thread).

I think determining whether a library fits the above critera before
determining whether it's good enough from a technical standpoint is the
reverse of the approach we need to have towards adding external
libraries, but maybe that is just me.

Ehsan

Ehsan Akhgari

unread,
Apr 28, 2011, 5:07:51 PM4/28/11
to Rob Campbell, dev-pl...@lists.mozilla.org
On 11-04-28 4:52 PM, Rob Campbell wrote:
> On 2011-04-28, at 17:20, Ehsan Akhgari wrote:
>
>> On 11-04-28 3:42 PM, Rob Campbell wrote:
>>> On 2011-04-28, at 14:54, Ehsan Akhgari wrote:
>>>
>>>> On 11-04-28 1:14 PM, Rob Campbell wrote:
>>>>>
>>>>> On 2011-04-28, at 11:27 , Benjamin Smedberg wrote:
>>>>>
>>>>>> On 4/28/2011 10:07 AM, Jean-Marc Desperrier wrote:
>>>>>>> Rob Campbell wrote:
>>>>>>>>> mozilla's builtin editor is primarily geared towards WYSIWYG-type editing.
>>>>>>>> These editors serve two very different purposes. Our in-tree editor
>>>>>>>> is, as you say, geared towards WYSIWYG editing of HTML.
>>>>>>>
>>>>>>> In my opinion, the best choice by far could be that it'd replace the existing in-tree editor, on the long term.
>>>>>> That's very off-topic, and not at all practical: the imported editor is a plaintext editor, not a WYSIWYG editor, and is not at all suitable as a replacement for an HTML editor.
>>>>>
>>>>> Yep. I was going to reply to that effect but Benjamin beat me to it.
>>>>
>>>> This is one of the reasons that I don't like the term WYSIWIG (as
>>>> opposed to plaintext editor). The Ace editor is definitely not a
>>>> plaintext editor. It is an HTML editor, built on top of the DOM APIs.
>>>> We do have an implementation of an HTML editor in our tree (which _can_
>>>> be used as a WYSIWIG editor, but is not limited to that).
>>>
>>> Ace isn't "plaintext", it's a code editor. For writing and displaying code. It has features such as line numbering and syntax-highlighting.
>>
>> For sure, that is what I was asserting. Benjamin said that it's a
>> plaintext editor and I thought you're implicitly agreeing.
>
> It's plaintext in the sense that we're editing lines in monotype fonts, we're not doing rich-text editing with styles and document structure.

Well, we shouldn't let the monotype fonts misguide us. A code editor is
*not* a plaintext editor. Things like syntax highlighting, matching
bracket hightlighting, etc are not available in a plaintext editor.

>>> Can the in-tree editor show gutters with line-numbers and do syntax highlighting? If not, I'm sure they could be added, but at what cost? How long would it take?
>>
>> The Gecko HTML editor allows the user to edit DOM nodes using mouse and
>> keyboard events, and also provides a set of APIs for doing some editing
>> operations. Things like gutters are separate DOM nodes, and they don't
>> have any relationship with the editor (look at Orion's DOM for example,
>> it uses a separate <table> for the gutter area).
>
> Yes, I'm familiar with the contenteditable editor and some of its capabilities (and limitations). Those were rhetorical questions.

In that case, these are my immediate answers in order: yes, and fairly
easy. :-)

> We'd have to do an analysis of how much work it would be to implement all of the editing features of a code editor like ace or orion using contenteditable.

Sure. This is why I asked what the requirements are.

(FWIW, Orion _does_ use contenteditable.)

>> Syntax highlighting is usually about wrapping stuff in span tags (with
>> class attributes possibly). The editor doesn't expose any commands to
>> do that, but that can be worked around either by adding a suitable
>> command or just using the DOM APIs.
>
> Yep. It might be possible to lift one of the syntax highlighting engines out of ace (or orion or codemirror or whatever) and apply it to a contenteditable editor, but all of this is missing the point...
>
> We have editors available, can we use one of them?

I'm not sure how you're asserting that we have editors available, when
none of them has been tested against a checklist of things that need to
be supported. Ace is definitely not acceptable in its current form.
Orion, maybe. But somebody needs to investigate that. I haven't tested
CodeMirror at all.

There are also integration issues to think about. Last time I installed
Orion, it came with a server side component. I'm not sure how easy it
is to rip out just the editor part.

Ehsan

Justin Wood (Callek)

unread,
Apr 28, 2011, 5:23:26 PM4/28/11
to

I [thought I] read a part of this thread saying that it was for the View
Source window (among other things), I will happily stand corrected on
that if I was remembering wrong. But my points on a11y still stand.

--
~Justin Wood (Callek)

John J Barton

unread,
Apr 28, 2011, 5:32:36 PM4/28/11
to
Ehsan Akhgari wrote:
> There are also integration issues to think about. Last time I installed
> Orion, it came with a server side component. I'm not sure how easy it
> is to rip out just the editor part.

I showed a little prototype integration of Orion with Firebug at a
recent Orion planning meeting and gave the Orion team some feedback
which they are using to make improvements. I as able to implement live
edits of CSS without really learning much about their code, a
significant plus for adopting a technology.

The core edit component is simply a straight forward JavaScript program.
I think it would be a fine embedded component. The next layer out where
the toolbars are added uses dojo, which you may greet with enthusiasm or
dismay. But the editor is lightly coupled to the server, I don't think
that is significant issue. Update/merge much more significant issue as
all of these editors will be rapid development over the next year and
receive important changes for some time after that.

jjb

Justin Dolske

unread,
Apr 28, 2011, 5:42:13 PM4/28/11
to
On 4/28/11 10:14 AM, Rob Campbell wrote:

> Seconded. He's done some great work during his editor bug rampage of 2010. I think he'd be a fantastic owner if he's interested.

You say that as if he has a choice in the matter. ;-)

Justin

Robert O'Callahan

unread,
Apr 28, 2011, 10:23:58 PM4/28/11
to Ehsan Akhgari, Jean-Marc Desperrier, Benjamin Smedberg, dev-pl...@lists.mozilla.org, Rob Campbell
On Fri, Apr 29, 2011 at 5:54 AM, Ehsan Akhgari <ehsan....@gmail.com>wrote:

> On 11-04-28 1:14 PM, Rob Campbell wrote:
> > On 2011-04-28, at 11:27 , Benjamin Smedberg wrote:
> >> On 4/28/2011 10:07 AM, Jean-Marc Desperrier wrote:
>

>>> Currently https://wiki.mozilla.org/Modules/Core says the Core::Editor
> component has no owner.
> >>> I believe that correctly reflects it's current state.

> >> Ehsan recently has been patching and maintaining that code, and probably
> ought to be nominated to own it.
> >

> > Seconded. He's done some great work during his editor bug rampage of
> 2010. I think he'd be a fantastic owner if he's interested.
>

> I certainly don't object to being the owner of the editor component (I
> didn't know if it matters, and how to approach it),
>

Ehsan certainly is the editor owner. Ms2ger helpfully updated the module
owners page to reflect reality :-).

I agree that we should be building on the browser's built-in text editing. I
think the main reason code editor authors don't want to do that is because
building and rendering a huge DOM is slow. We need to find ways to improve
that, but some of that may just be using better JS implementation tricks
(e.g. lazily building the DOM for lines as they become visible. which I know
some editors already do).

Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]

Kevin Dangoor

unread,
Apr 29, 2011, 12:26:05 AM4/29/11
to Justin Wood (Callek), dev-pl...@lists.mozilla.org

I don't really want to send this thread spiraling off in this other
direction just yet, but View Source (at least in browser) is involved, and I
appreciate your points on a11y. How this intersects with View Source can
best be explained by some wireframes that I don't have yet, which is why I'd
rather not head in that direction yet.

Kevin

--
Kevin Dangoor

work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com

Jean-Marc Desperrier

unread,
Apr 29, 2011, 5:26:20 AM4/29/11
to
Ehsan Akhgari wrote:
> [...] - about Ace, this is the current

> status: "we've got this code over here which works for the simplest
> possible case, and we'd like to use it, but we can't, since it doesn't
> address many of our needs at all".
> [...] - Orion, this is the current

> status: "we've got this code over here, which seems to work, but we
> still need to investigate whether it addresses all of our needs, before
> we decide whether we can use it".
> [...] - the question that I'm proposing

> is: "is it worth for us to invest time in improving a third-party
> library, compared to improving our in-tree editor to do what we want",
> [...] in order to answer this, we need to know what we want. At least,

> _I_ need to know what we want. :-)

Hi, Ehsan (and first thanks for having taken over the abandoned built-in
editor).

I think this all is very good point, that the best would be starting
from that to have an in-depth discussion about the built-in editor, what
it's problem are, and why those problems make alternative solutions
tempting (the fact is, it's *hard* to develop anything in the built-in
editor and that it's a strong deterrent to both bug fixing and extending
it to add new features).

But I've been already accused of going off-topic above.

So why not go to the dedicated mozilla.dev.tech.editor group to discuss
that, where any question and remark about the editor will be in-topic ?

Henri Sivonen

unread,
Apr 29, 2011, 7:51:18 AM4/29/11
to dev-pl...@lists.mozilla.org
On Thu, 2011-04-28 at 16:58 -0400, Ehsan Akhgari wrote:
> The way I see it, if we're talking about Ace, this is the current

> status: "we've got this code over here which works for the simplest
> possible case, and we'd like to use it, but we can't, since it doesn't
> address many of our needs at all". For Orion, this is the current

> status: "we've got this code over here, which seems to work, but we
> still need to investigate whether it addresses all of our needs,
> before
> we decide whether we can use it". And the question that I'm proposing

> is: "is it worth for us to invest time in improving a third-party
> library, compared to improving our in-tree editor to do what we want",
> and in order to answer this, we need to know what we want. At least,

> _I_ need to know what we want. :-)

What I'd like to know the answer to is: "How can we fix the
interoperable Web platform to support syntax-highlighed editing so that
people don't need to use off-screen textareas or <canvas>?" (Scope creep
over "our in-tree editor"!)

I find it rather worrying if even browser vendors themselves go the
hacky route instead of improving the platform, though I can see how
improving the platform may look like a multi-year rathole that a
subproject that needs to ship has to steer clear of. The spec situation
for contenteditable is unsatisfactory but it's actively being worked on.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

glazou

unread,
Apr 29, 2011, 11:15:47 AM4/29/11
to
On 27 avr, 14:00, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 4/26/11 5:57 PM, Joe Walker wrote:
>
> > Ace, grew out of the merger of Skywriter (a.k.a Bespin) with the Ace
> > editor. We would like to use it for displaying, and editing CSS,
> > Javascript, and HTML.
>
> What are the benefits of doing this over using our built-in editor?
>
> -Boris

The builtin plaintext editor suffers from a lot of small diseases. Its
main problem is not the lack of editor team, its main problem is the
lack of supervision of the selection and caret codes, what Mike Judge
used to do in the oooold days. I can't count the number of small pains
I hit with the plaintext editor in Thunderbird, all related not to the
editor itself but to the caret code.

I know and use Ace. It now seats inside BlueGriffon for its source
view. It's fast and reliable, its code is much cleaner and easier to
understand than Bespin/Skywriter. But there are a few bad points:

- no doc at all for the time being ; clearly a weak point
- problems with non latin fonts in particular with asian scripts (yes,
this is a big issue if you want japanese people to edit HTML source
code of a home-made doc)
- fast but still waaaaay slower than nsPlaintextEditor to render a
15,000+ lines file
- slow release process, small team
- it is not managed directly by Moz, and that means that
incompatibilities with XUL UI and Gecko (JS chrome level) remain below
the radar ; I remind you that jQuery was originally compatible with
XUL, dropped compat with XUL looooong ago just for a few innerHTML
calls. Fortunately, we now have CSS transitions and animations, but in
the meantime animating XUL elements for UI effects was _really_ a
pain.

Gecko still needs the builtin editor anyway for the html5 and XUL
controls, and the XUL authoring community needs a (much) more powerful
solution than the builtin editor. Ace _could_ be a compromise if and
only if:

1. we have tests showing that integration inside XUL works (I can
write them)
2. Ace is documented and uses simple, easy, learnable extensibility
mechanisms (diving into Bespin's code was _really_ complex, debugging
it was scary)
3. we have excellent IME and accessibility tests
4. we do care about non-latin scripts

</Daniel>

Ehsan Akhgari

unread,
Apr 29, 2011, 1:42:01 PM4/29/11
to Henri Sivonen, dev-pl...@lists.mozilla.org
On 11-04-29 7:51 AM, Henri Sivonen wrote:
> On Thu, 2011-04-28 at 16:58 -0400, Ehsan Akhgari wrote:
>> The way I see it, if we're talking about Ace, this is the current
>> status: "we've got this code over here which works for the simplest
>> possible case, and we'd like to use it, but we can't, since it doesn't
>> address many of our needs at all". For Orion, this is the current
>> status: "we've got this code over here, which seems to work, but we
>> still need to investigate whether it addresses all of our needs,
>> before
>> we decide whether we can use it". And the question that I'm proposing
>> is: "is it worth for us to invest time in improving a third-party
>> library, compared to improving our in-tree editor to do what we want",
>> and in order to answer this, we need to know what we want. At least,
>> _I_ need to know what we want. :-)
>
> What I'd like to know the answer to is: "How can we fix the
> interoperable Web platform to support syntax-highlighed editing so that
> people don't need to use off-screen textareas or <canvas>?" (Scope creep
> over "our in-tree editor"!)

I agree. But I think the amount of work that we need to do in order to
have this working on the Web platform might not be as huge as one would
imagine.

> I find it rather worrying if even browser vendors themselves go the
> hacky route instead of improving the platform, though I can see how
> improving the platform may look like a multi-year rathole that a
> subproject that needs to ship has to steer clear of. The spec situation
> for contenteditable is unsatisfactory but it's actively being worked on.

I really want to make sure that we don't move towards a hacky solution
in this regard. I think we need more communication in this area.

Cheers,
Ehsan

Ehsan Akhgari

unread,
Apr 29, 2011, 1:46:24 PM4/29/11
to Jean-Marc Desperrier, dev-pl...@lists.mozilla.org
On 11-04-29 5:26 AM, Jean-Marc Desperrier wrote:
> Hi, Ehsan (and first thanks for having taken over the abandoned built-in
> editor).
>
> I think this all is very good point, that the best would be starting
> from that to have an in-depth discussion about the built-in editor, what
> it's problem are, and why those problems make alternative solutions
> tempting (the fact is, it's *hard* to develop anything in the built-in
> editor and that it's a strong deterrent to both bug fixing and extending
> it to add new features).

I don't really think that is a useful direction to move for this case.
As I've said before, I think we should approach this discussion from
another angle: "What are the requirements for the code editor that the
devtools team needs, and how can we address those requirements using the
web editor APIs."

Discussion about the limitations of the Gecko editor implementation also
need to happen, but I think they maybe orthogonal to the issue at hand...

> But I've been already accused of going off-topic above.
>
> So why not go to the dedicated mozilla.dev.tech.editor group to discuss
> that, where any question and remark about the editor will be in-topic ?

I'd prefer to keep the discussion on dev.platform. dev.tech.editor is a
dead group, really. This reminds me that I should probably file a bug
to get it merged to dev.platform. ;-)

Cheers,
Ehsan

Ehsan Akhgari

unread,
Apr 29, 2011, 2:16:57 PM4/29/11
to glazou, dev-pl...@lists.mozilla.org
On 11-04-29 11:15 AM, glazou wrote:
> The builtin plaintext editor suffers from a lot of small diseases. Its
> main problem is not the lack of editor team, its main problem is the
> lack of supervision of the selection and caret codes, what Mike Judge
> used to do in the oooold days. I can't count the number of small pains
> I hit with the plaintext editor in Thunderbird, all related not to the
> editor itself but to the caret code.

Have you filed bugs about them? I have also worked a lot on our caret
code, and it's already been improved a lot in Gecko 2.0. If you know of
pain points, you should file a bug and CC me on it.

> - no doc at all for the time being ; clearly a weak point
> - problems with non latin fonts in particular with asian scripts (yes,
> this is a big issue if you want japanese people to edit HTML source
> code of a home-made doc)

Of course, this is something that we need to support.

> - fast but still waaaaay slower than nsPlaintextEditor to render a
> 15,000+ lines file
> - slow release process, small team
> - it is not managed directly by Moz, and that means that
> incompatibilities with XUL UI and Gecko (JS chrome level) remain below
> the radar ; I remind you that jQuery was originally compatible with
> XUL, dropped compat with XUL looooong ago just for a few innerHTML
> calls. Fortunately, we now have CSS transitions and animations, but in
> the meantime animating XUL elements for UI effects was _really_ a
> pain.

I don't think that XUL interaction is really an issue. We could always
build XUL components which encapsulate Ace (or whatever other library)
if we need to. The problems lie elsewhere, please read on.

> Gecko still needs the builtin editor anyway for the html5 and XUL
> controls, and the XUL authoring community needs a (much) more powerful
> solution than the builtin editor. Ace _could_ be a compromise if and
> only if:
>
> 1. we have tests showing that integration inside XUL works (I can
> write them)

This is a small technical problem.

> 2. Ace is documented and uses simple, easy, learnable extensibility
> mechanisms (diving into Bespin's code was _really_ complex, debugging
> it was scary)
> 3. we have excellent IME and accessibility tests
> 4. we do care about non-latin scripts

This point kind of throws me off. Are you saying that we should be wary
of using Ace *only* if we care about non-latin users? Well, of course
we do care about those users. They are not second-class citizens on the
web, and their needs should be considered just as much as the needs of
users speaking Latin-based languages.

I don't even know why we're having this discussion at this point. Let
me put things into perspective. Would you even consider discussing an
editing library which can't cope with Latin scripts? Of course not.
The situation with non-Latin scripts is no different!

Cheers,
Ehsan

glazou

unread,
Apr 29, 2011, 3:32:36 PM4/29/11
to
On 29 avr, 20:16, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:

> This point kind of throws me off.  Are you saying that we should be wary
> of using Ace *only* if we care about non-latin users?  Well, of course
> we do care about those users.  They are not second-class citizens on the
> web, and their needs should be considered just as much as the needs of
> users speaking Latin-based languages.
>
> I don't even know why we're having this discussion at this point.  Let
> me put things into perspective.  Would you even consider discussing an
> editing library which can't cope with Latin scripts?  Of course not.
> The situation with non-Latin scripts is no different!

No need to be agressive, Ehsan. Most of us are latin1 script native
users.
Most of us don't know/can't use other scripts on a daily basis. I
suspect
you can, and that's good for you. But I am a too old monkey in this
business
to ignore how things are, in software or in standardization. If you
take the
major scrolling problem I recently reported in the Ace mailing-list
about
asian scripts, it exists BECAUSE implem and tests are done with ascii/
latin1 files.
Bugs based on other scripts come in the loop at a later time.

I never said or even thought non-latin script users are 2nd-class
users
and I am the first one who pushed for deeper internalization of CSS
inside
the CSS WG extending list style types to most of the world's numbering
systems. I also write documents in yiddish, using a rtl non-latin
script.
I'm eating my own dogfood here. FWIW, I am also the first one in the
world
who implemented non-latin scripts in a mail user agent.

So no need to give me a lesson here, thanks, I was already working on
I18N at a time you were probably in diapers.

I am only saying that at this time, Ace has big issues with asian
scripts
and that caring about such bugs AFTER latin1 is ok is probably not the
way to deal optimally with such issues if Ace becomes a more
integrated
Mozilla framework. The whole thing is probably related to the size of
the
Ace team, and the limited available resources at this time.

</Daniel>

Gervase Markham

unread,
Apr 30, 2011, 3:49:14 AM4/30/11
to
On 27/04/11 19:43, Kevin Dangoor wrote:
> 2. offer Eclipse Orion as an option via an add-on
>
> The Orion editor just came out last month.

The original question of this thread was "Can we use ACE?". The legal
answer to that question is "Yes". (Of course, there are lots of other
answers, as we are seeing!) But for Orion, the answer is "Not sure;
quite possibly not". There may be either legal or policy restrictions on
taking EPL code into the tree. Whether there are legal ones is a case of
looking at the licences; but we also have a policy that all code
shipping in Firefox has to be MPL-or-simpler in its licensing terms, so
we can say to people "Happy with the MPL? You can ship our stuff."

So if Orion does emerge as something we want to consider, please file a
licensing bug early in the process so we can look at it. But it's > 50%
likely it'll be a No.

Gerv

johnjbarton

unread,
Apr 30, 2011, 12:12:37 PM4/30/11
to
On 4/30/2011 12:49 AM, Gervase Markham wrote:
> On 27/04/11 19:43, Kevin Dangoor wrote:
>> 2. offer Eclipse Orion as an option via an add-on
>>
>> The Orion editor just came out last month.
>
> The original question of this thread was "Can we use ACE?". The legal
> answer to that question is "Yes". (Of course, there are lots of other
> answers, as we are seeing!) But for Orion, the answer is "Not sure;
> quite possibly not". There may be either legal or policy restrictions on
> taking EPL code into the tree.

The Orion editor is licensed under BSD,
http://wiki.eclipse.org/Orion/Coding_conventions
jjb

Jonathan Kew

unread,
Apr 30, 2011, 1:40:44 PM4/30/11
to johnjbarton, dev-pl...@lists.mozilla.org
On 30 Apr 2011, at 17:12, johnjbarton wrote:

> The Orion editor is licensed under BSD,
> http://wiki.eclipse.org/Orion/Coding_conventions

AFAICS, that page refers to the EPL, and does not mention a BSD license.

JK

johnjbarton

unread,
Apr 30, 2011, 2:03:39 PM4/30/11
to jfkt...@googlemail.com

Bottom of the page:
"The Orion client code (HTML, CSS, JavaScript), is licensed under both
the Eclipse Public License and the Eclipse Distribution License. "

Eclipse Distribution License == EDL == Eclipse speak for new BSD.

http://www.eclipse.org/org/documents/edl-v10.html

jjb

Joe Walker

unread,
Apr 30, 2011, 6:43:52 PM4/30/11
to dev-pl...@lists.mozilla.org
On Sat, Apr 30, 2011 at 08:49, Gervase Markham <ge...@mozilla.org> wrote:

>
> The original question of this thread was "Can we use ACE?".
>


Minor nit: My original motivation was to ask about the command line
component of Ace/Skywriter, specifically as a 3rd party component. For
obvious reasons, it made sense to ask about Ace at the same time.

The command line part does not depend on Ace (actually it's the other way
around), and does not suffer from the same problem of similarity to existing
code that Ace does.

Whatever happens to Ace, I'm not feeling the same push-back against the
command line component, so I'm taking this as permission to proceed taking
it to the point where it is worthy to be considered for inclusion. Please
tell me if you disagree with this course of action.

Thanks,

Joe.

Dao

unread,
May 1, 2011, 1:40:48 PM5/1/11
to
On 01.05.2011 00:43, Joe Walker wrote:
> Minor nit: My original motivation was to ask about the command line
> component of Ace/Skywriter, [...]

> Whatever happens to Ace, I'm not feeling the same push-back against the
> command line component, so I'm taking this as permission to proceed taking
> it to the point where it is worthy to be considered for inclusion. Please
> tell me if you disagree with this course of action.

Your original posting doesn't seem to make it very clear that it was
primarily about the command line component, so drawing the conclusion
that this is fine to include seems a bit hasty. I think I've read the
whole thread with decent attention, but I honestly don't know anything
about this component, except that it's somehow related to Ace.

Ehsan Akhgari

unread,
May 1, 2011, 3:52:48 PM5/1/11
to Dao, dev-pl...@lists.mozilla.org

Can you please give some more information on what this command line
component does?

Ehsan

Blair McBride

unread,
May 1, 2011, 8:32:10 PM5/1/11
to dev-pl...@lists.mozilla.org
On 29/04/11 09:07, Ehsan Akhgari wrote:
> I haven't tested CodeMirror at all.

My experience with CodeMirror is a bit dated, but when it was used in
Ubiquity, we found that CodeMirror had major performance issues - it
couldn't cope well with anything but small snippets.

- Blair

Axel Hecht

unread,
May 2, 2011, 10:17:23 AM5/2/11
to
Regarding the command line:

I'd like to see a document similar to the editing component feature page
for the command line.

The reason for that is, ubiquity lost most of its glory the moment we
started to think about how to turn that into a global feature for Firefox.

I'm confident that the command line you have in mind is different, but
we'll need to be very clear in how, and if the result renders the
command line to be a good feature for Firefox on a global scale.

At this point, I can't make an educated comment on the CLI, as I don't
understand its scope and its interaction with a global web, and global
addons.

Axel

PS: Thanks to Ehsan for making all the comments about ACE I failed to
put into words.

Rob Campbell

unread,
May 2, 2011, 11:40:42 AM5/2/11
to Axel Hecht, dev-pl...@lists.mozilla.org

On 2011-05-02, at 11:17 , Axel Hecht wrote:

> Regarding the command line:
>
> I'd like to see a document similar to the editing component feature page for the command line.

Feature page is here:

https://wiki.mozilla.org/DevTools/Features/GCLI

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Axel Hecht

unread,
May 2, 2011, 12:02:02 PM5/2/11
to
On 02.05.11 17:40, Rob Campbell wrote:
>
> On 2011-05-02, at 11:17 , Axel Hecht wrote:
>
>> Regarding the command line:
>>
>> I'd like to see a document similar to the editing component feature page for the command line.
>
> Feature page is here:
>
> https://wiki.mozilla.org/DevTools/Features/GCLI

Which doesn't answer the questions below. I've seen it before, and
nothing that I've seen (product page, bugs, posts) has given the detail
necessary to make a constructive comment.

Axel

Joe Walker

unread,
May 3, 2011, 12:44:18 PM5/3/11
to dev-pl...@lists.mozilla.org
The question I guess you're referring to is "I don't understand its scope

and its interaction with a global web, and global addons"

The scope of the command line component is the same as the current web
console. Effectively it takes the existing JavaScript command line and makes
it easier to use by adding meta-data to the commands in a similar way to
what bash/zsh do, but using HTML5 as display mechanism rather than a 2d
character array.

The command line component doesn't really interact with the global web. It's
a tool for developers only. The 'console' object will continue to exist, but
I'm not proposing to change it at all.

Addons will be able to JavaScript functions and the meta-data to make them
useful.

The details of some of this are still being worked out, but I hope that
helps.

Joe.

0 new messages