Orion editor landed, but turned off. What's next?
Kevin Dangoor
However, Orion and the Scratchpad integration have been preffed off, due to concerns Ehsan has about the current implementation:
https://bugzilla.mozilla.org/show_bug.cgi?id=660784#c17
I wanted to open this up for wider discussion and to be certain we have quantified exactly what needs to be done to put this functionality in the hands of developers.
IBM has committed two full time staff members to work on Orion's code editor, and longer term I am hoping that Orion can be changed to leverage more of what Gecko can natively provide as it evolves:
https://wiki.mozilla.org/Features/Desktop/EditorAPI
However, I want to be sure that we don't lose too much time trying to make things "perfect". Hence, my desire to get some agreement on what is minimally needed for Orion to be turned on (and whether others agree that it should even be off at this point).
Thanks to Mihai, Rob C., Ehsan and Gavin for all of the work in landing this significant improvement!
Kevin
--
Kevin Dangoor
product manager, developer tools
work: http://mozilla.com/
blog: http://blueskyonmars.com/
@dangoor
Ehsan Akhgari
> I wanted to open this up for wider discussion and to be certain we have quantified exactly what needs to be done to put this functionality in the hands of developers.
In order to start the discussion, here is a detailed list of the things
that Orion currently does which IMO should be fixed before we can turn
it on for all of our users:
* Orion handles caret/selection internally, which can cause the caret to
behave incorrectly (for example when dealing with bidirectional text) or
get out of sync with the internal caret/selection representation. This
also includes the code responsible for caret navigation.
* Orion handles hit-testing internally, which can cause problems if the
result of the hit-testing would not be the same as what the browser
would do on its own.
* Orion handles mouse-based scrolling internally, which can cause
inconsistencies with the way that scrolling works (for example, for
things like high-precision scrolling). Additionally, it handles
keyboard scrolling itself too, which seems to be providing a different
scrolling logic to the one built in Gecko, and fails to scroll properly
in some cases.
* Orion handles character deletion using backspace/delete internally,
and its handling is buggy for international text.
* Orion handles a bunch of other things such as IME, touch events, etc
on its own too, which I have not looked deeply into yet.
The TLDR version of this post is, Orion handles a lot of stuff
internally and gets them wrong (even if we would be fine with the code
duplication). I think a good strategy towards fixing the problems
mentioned above is to rewrite those parts to use the built-in facilities
that the browser provides, and expose new necessary APIs where needed.
Cheers,
Ehsan
Johnathan Nightingale
> On 11-08-15 10:32 AM, Kevin Dangoor wrote:
>> I wanted to open this up for wider discussion and to be certain we have quantified exactly what needs to be done to put this functionality in the hands of developers.
>
> In order to start the discussion, here is a detailed list of the things that Orion currently does which IMO should be fixed before we can turn it on for all of our users:
You say "before we can turn it on for all of our users" and I want to be clear here:
- Are all of these things barriers to turning it on for the specific case of scratchpad, which only a certain kind of user will ever visit?
- Would it be reasonable to put this change behind a UI flag like [ ] Syntax Highlighting and let people decide to turn that on (and deal with these bugs as "Problems in syntax highlighting mode") or are these show stoppers to anything more than about:config level visibility
J
---
Johnathan Nightingale
Director of Firefox Engineering
joh...@mozilla.com
Ehsan Akhgari
> On 2011-08-15, at 11:35 AM, Ehsan Akhgari wrote:
>
>> On 11-08-15 10:32 AM, Kevin Dangoor wrote:
>>> I wanted to open this up for wider discussion and to be certain we have quantified exactly what needs to be done to put this functionality in the hands of developers.
>>
>> In order to start the discussion, here is a detailed list of the things that Orion currently does which IMO should be fixed before we can turn it on for all of our users:
>
> You say "before we can turn it on for all of our users" and I want to be clear here:
>
> - Are all of these things barriers to turning it on for the specific case of scratchpad, which only a certain kind of user will ever visit?
The severity of these issues vary. The worst that I know of right now
is the possibility to get the invalid Unicode characters when dealing
with data containing Unicode surrogates. There are also some of these
items which can potentially affect all of the users, such as keyboard
navigation failing to scroll.
> - Would it be reasonable to put this change behind a UI flag like [ ] Syntax Highlighting and let people decide to turn that on (and deal with these bugs as "Problems in syntax highlighting mode") or are these show stoppers to anything more than about:config level visibility
I think we need a bit more testing before we can safely judge if any of
the issues listed here are show-stoppers or not, and I do hope that we
can fix as many of them as possible in the meantime. But in the current
status of the code, I don't find it as robust as the rest of the code in
Firefox and Gecko. Also, it definitely lacks the amount of coverage
that we have in core Gecko for basic interactions such as caret navigation.
Cheers,
Ehsan
Johnathan Nightingale
>> - Would it be reasonable to put this change behind a UI flag like [ ] Syntax Highlighting and let people decide to turn that on (and deal with these bugs as "Problems in syntax highlighting mode") or are these show stoppers to anything more than about:config level visibility
>
> I think we need a bit more testing before we can safely judge if any of the issues listed here are show-stoppers or not, and I do hope that we can fix as many of them as possible in the meantime. But in the current status of the code, I don't find it as robust as the rest of the code in Firefox and Gecko. Also, it definitely lacks the amount of coverage that we have in core Gecko for basic interactions such as caret navigation.
Should we turn it on on trunk after the Aurora migration tomorrow, to get more of that testing?
Mike Shaver
<joh...@mozilla.com> wrote:
> Should we turn it on on trunk after the Aurora migration tomorrow, to get more of that testing?
Also: do we have tests for the Gecko editor which we can repurpose to
point at the Orion editor, and see what the results are there?
Mike
Ehsan Akhgari
> On 2011-08-15, at 12:54 PM, Ehsan Akhgari wrote:
>>> - Would it be reasonable to put this change behind a UI flag like [ ] Syntax Highlighting and let people decide to turn that on (and deal with these bugs as "Problems in syntax highlighting mode") or are these show stoppers to anything more than about:config level visibility
>>
>> I think we need a bit more testing before we can safely judge if any of the issues listed here are show-stoppers or not, and I do hope that we can fix as many of them as possible in the meantime. But in the current status of the code, I don't find it as robust as the rest of the code in Firefox and Gecko. Also, it definitely lacks the amount of coverage that we have in core Gecko for basic interactions such as caret navigation.
>
>
That would be fine by me.
Ehsan
Ehsan Akhgari
> On Mon, Aug 15, 2011 at 5:21 PM, Johnathan Nightingale
> <joh...@mozilla.com> wrote:
>> Should we turn it on on trunk after the Aurora migration tomorrow, to get more of that testing?
>
> point at the Orion editor, and see what the results are there?
Yes, that could be possible, but by just reading the Orion's code, one
can determine that some of them would fail. It would be interesting to
see what other tests would fail though.
Ehsan
Rob Campbell
On 2011-08-15, at 18:21, Johnathan Nightingale wrote:
> On 2011-08-15, at 12:54 PM, Ehsan Akhgari wrote:
>>> - Would it be reasonable to put this change behind a UI flag like [ ] Syntax Highlighting and let people decide to turn that on (and deal with these bugs as "Problems in syntax highlighting mode") or are these show stoppers to anything more than about:config level visibility
>>
>> I think we need a bit more testing before we can safely judge if any of the issues listed here are show-stoppers or not, and I do hope that we can fix as many of them as possible in the meantime. But in the current status of the code, I don't find it as robust as the rest of the code in Firefox and Gecko. Also, it definitely lacks the amount of coverage that we have in core Gecko for basic interactions such as caret navigation.
>
>
> Should we turn it on on trunk after the Aurora migration tomorrow, to get more of that testing?
Filed bug 679475 to do this.
https://bugzilla.mozilla.org/show_bug.cgi?id=679475
~ rob
Kevin Dangoor
> On 11-08-15 10:32 AM, Kevin Dangoor wrote:
>> I wanted to open this up for wider discussion and to be certain we have quantified exactly what needs to be done to put this functionality in the hands of developers.
>
> In order to start the discussion, here is a detailed list of the things that Orion currently does which IMO should be fixed before we can turn it on for all of our users:
>
> * Orion handles caret/selection internally, which can cause the caret to behave incorrectly (for example when dealing with bidirectional text) or get out of sync with the internal caret/selection representation. This also includes the code responsible for caret navigation.
>
> * Orion handles hit-testing internally, which can cause problems if the result of the hit-testing would not be the same as what the browser would do on its own.
>
> * Orion handles mouse-based scrolling internally, which can cause inconsistencies with the way that scrolling works (for example, for things like high-precision scrolling). Additionally, it handles keyboard scrolling itself too, which seems to be providing a different scrolling logic to the one built in Gecko, and fails to scroll properly in some cases.
>
> * Orion handles character deletion using backspace/delete internally, and its handling is buggy for international text.
>
> * Orion handles a bunch of other things such as IME, touch events, etc on its own too, which I have not looked deeply into yet.
I spoke a bit with Mihai about these yesterday. Mihai pointed out that even if we manage to expose Gecko functionality that handles these things (which I think is going to take a good deal of work to get right), the Orion project still needs for their editor to work in other browsers.
Could you file bugs (in our bugzilla) with specific problem examples? We can use those bugs to track the status of our feature plus they would give us the specifics to pass along to Orion's bugzilla.
Thanks,
Ehsan Akhgari
> On Aug 15, 2011, at 2:35 PM, Ehsan Akhgari wrote:
>
>> On 11-08-15 10:32 AM, Kevin Dangoor wrote:
>>> I wanted to open this up for wider discussion and to be certain we have quantified exactly what needs to be done to put this functionality in the hands of developers.
>>
>> In order to start the discussion, here is a detailed list of the things that Orion currently does which IMO should be fixed before we can turn it on for all of our users:
>>
>> * Orion handles caret/selection internally, which can cause the caret to behave incorrectly (for example when dealing with bidirectional text) or get out of sync with the internal caret/selection representation. This also includes the code responsible for caret navigation.
>>
>> * Orion handles hit-testing internally, which can cause problems if the result of the hit-testing would not be the same as what the browser would do on its own.
>>
>> * Orion handles mouse-based scrolling internally, which can cause inconsistencies with the way that scrolling works (for example, for things like high-precision scrolling). Additionally, it handles keyboard scrolling itself too, which seems to be providing a different scrolling logic to the one built in Gecko, and fails to scroll properly in some cases.
>>
>> * Orion handles character deletion using backspace/delete internally, and its handling is buggy for international text.
>>
>> * Orion handles a bunch of other things such as IME, touch events, etc on its own too, which I have not looked deeply into yet.
>
>
> I spoke a bit with Mihai about these yesterday. Mihai pointed out that even if we manage to expose Gecko functionality that handles these things (which I think is going to take a good deal of work to get right), the Orion project still needs for their editor to work in other browsers.
But what prevents us from having a Gecko specific implementation?
> Could you file bugs (in our bugzilla) with specific problem examples? We can use those bugs to track the status of our feature plus they would give us the specifics to pass along to Orion's bugzilla.
I will be happy to, but first let's decide on how we're going to address
them in general. :-)
Cheers,
Ehsan
Fabien Cazenave
> On 11-08-17 10:09 AM, Kevin Dangoor wrote:
>> I spoke a bit with Mihai about these yesterday. Mihai pointed out that
>> even if we manage to expose Gecko functionality that handles these
>> things (which I think is going to take a good deal of work to get
>> right), the Orion project still needs for their editor to work in
>> other browsers.
>
> But what prevents us from having a Gecko specific implementation?
+1
I'd love to have a code editor that is based on our Gecko editor as much
as possible: accessibility, UX consistency, maintainability.
Corollary: what could we do on the Core/Editor side to avoid a few
Mozilla-specific hacks in the Orion codebase?
In the longer term (= when we feel our Orion editor is ready), can we
hope that such an editor would be exposed as a toolkit component so it
can be reused for other cases?
:kazé
Ehsan Akhgari
I was mostly talking about Gecko providing APIs which enable Orion to
implement a code editor using the available platform features (like
selection/caret management, input handling, text layout, etc.) For
example, if Orion needs a specific selection API in order to implement a
functionality, we can export it from Gecko.
I don't necessarily want a new type of editor being exposed by Gecko,
but I think that if we get the underlying APIs right, smart people can
build awesome web-based code editors on top of them.
Cheers,
Ehsan