Code editor in Firefox 9
Kevin Dangoor
survey results are in... and, frankly, not super exciting. I had 7
responses, which I doubt represents a large enough audience to tell us much.
Here are a few tidbits about the survey results, such as they were:
* 3 of the 7 actually do put non-English code or code comments in their
files
* None of the respondents had trouble with the code editor
* Only one was using an RTL language (Hebrew). Other languages tested:
Russian, Serbian, Portuguese, Danish and Armenian
I spoke, independently, with Johnathan and David Bolter about the feature
last week. We know that the feature is not 100% perfect from both i18n and
a10y perspectives, but it is a big boost in usability for Scratchpad and the
forthcoming Style Editor.
We believe that we should turn on the editor by default in Firefox 9, which
is how it's presently set in Nightly and start gathering feedback from more
users and real world use. Any users who *do* encounter a problem will still
be able to switch back to a plain text area by setting a pref. We'll work on
fixing those problems that do crop up, but at least most people will get to
enjoy a better editing experience along the way.
Kevin
--
Kevin Dangoor
work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com
Ehsan Akhgari
> We believe that we should turn on the editor by default in Firefox 9, which
> is how it's presently set in Nightly and start gathering feedback from more
> users and real world use. Any users who *do* encounter a problem will still
> be able to switch back to a plain text area by setting a pref. We'll work
> on
> fixing those problems that do crop up, but at least most people will get to
> enjoy a better editing experience along the way.
>
I spent a few minutes when I read this email today and played with
scratchpad. I found at least five bugs that I could reproduce reliably and
I filed all of them. Have we done a QA run on it to determine the most
notable bugs, and decide which ones we're fine shipping with, and which ones
we need to fix before enabling it by default?
Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
Johnathan Nightingale
> On Mon, Sep 19, 2011 at 1:24 PM, Kevin Dangoor <kdan...@mozilla.com> wrote:
>
>> We believe that we should turn on the editor by default in Firefox 9, which
>> is how it's presently set in Nightly and start gathering feedback from more
>> users and real world use.
> I found at least five bugs that I could reproduce reliably and
> I filed all of them. Have we done a QA run on it to determine the most
> notable bugs, and decide which ones we're fine shipping with, and which ones
> we need to fix before enabling it by default?
I think Kevin's point in the original note is that we would rather not make the list of "bugs that need to be fixed before enabling it" because we're not getting great bug input with it disabled. I think Kevin's arguing for "enable it, and see if that uncovers reasons to reverse that decision." Do you believe that is a mistake?
(I'd ask these questions of anyone, I think, but am particularly keen to hear your thoughts, since you think about editors more than most).
J
---
Johnathan Nightingale
Director of Firefox Engineering
joh...@mozilla.com
Dao
> On 2011-09-19, at 3:16 PM, Ehsan Akhgari wrote:
>> On Mon, Sep 19, 2011 at 1:24 PM, Kevin Dangoor<kdan...@mozilla.com> wrote:
>>
>>> We believe that we should turn on the editor by default in Firefox 9, which
>>> is how it's presently set in Nightly and start gathering feedback from more
>>> users and real world use.
>
>> Do we have a sense of what would block having this enabled by default?
>
> In a generic sense: "bugs which make the scratchpad with Orion enabled net-worse than the scratchpad with Orion disabled."
net-worse.
>> I found at least five bugs that I could reproduce reliably and
>> I filed all of them. Have we done a QA run on it to determine the most
>> notable bugs, and decide which ones we're fine shipping with, and which ones
>> we need to fix before enabling it by default?
>
> Thank you for filing the bugs! Is it your sense that those things make it a less-good editor than shipping with orion disabled?
>
> I think Kevin's point in the original note is that we would rather not make the list of "bugs that need to be fixed before enabling it" because we're not getting great bug input with it disabled. I think Kevin's arguing for "enable it, and see if that uncovers reasons to reverse that decision." Do you believe that is a mistake?
Panos Astithas
need to get it into Aurora at least, or Beta, if we are to reach a
substantial amount of users.
Cheers,
Panos
Mihai Sucan
<ehsan....@gmail.com> a écrit:
> I spent a few minutes when I read this email today and played with
> I filed all of them.
Dao
>>> I think Kevin's point in the original note is that we would rather not
>>> make the list of "bugs that need to be fixed before enabling it" because
>>> we're not getting great bug input with it disabled. I think Kevin's arguing
>>> for "enable it, and see if that uncovers reasons to reverse that decision."
>>> Do you believe that is a mistake?
>>>
>>
>> It's already enabled in nightlies.
>
>
> That's right, and this is the amount of feedback that we've got so far. We
> need to get it into Aurora at least, or Beta, if we are to reach a
> substantial amount of users.
Ehsan is you best source here.
Rob Campbell
From a quick survey of current Scratchpad bugs, I have these from Ehsan:
687565 Scratchpad doesn't highlight the JS 'let' keyword
687568 Extending the selection causes Scratchpad to scroll without making the selection visible
687573 Scratchpad does not maintain X offset when navigating vertically
687580 Scratchpad doesn't support drag and drop
669011 [RTL] Scratchpad doesn't allow ctrl-shift-x to switch text direction
Of these, I'd say 687568 is the only real "blocker" level bug. Possibly 669011 as well, which I'm going to unassign to myself if anyone wants to give it a shot.
Any other critical bugs you can think of, Ehsan?
687565 will require a modification to the syntax highlighting engine. Mihai may have some ideas about that, but I wouldn't call it a show-stopper.
~ rob
Dao
> Regardless of where or who we're getting the bugs from, Ehsan's short-list of bugs is a good start.
>
> From a quick survey of current Scratchpad bugs, I have these from Ehsan:
>
> 687565 Scratchpad doesn't highlight the JS 'let' keyword
> 687568 Extending the selection causes Scratchpad to scroll without making the selection visible
> 687573 Scratchpad does not maintain X offset when navigating vertically
> 687580 Scratchpad doesn't support drag and drop
> 669011 [RTL] Scratchpad doesn't allow ctrl-shift-x to switch text direction
>
> Of these, I'd say 687568 is the only real "blocker" level bug. Possibly 669011 as well, which I'm going to unassign to myself if anyone wants to give it a shot.
frequently people would run into it.
687580 too. Copy+paste is a workaround, but it's still an annoyance if
you expect drag+drop to work.
I'm skeptical that aurora will help you assess the severity of these
issues, as I suspect it doesn't yet have the serious scratchpad users
that the scratchpad is made for.
Rob Campbell
On 2011-09-20, at 10:02 , Dao wrote:
> On 20.09.2011 14:37, Rob Campbell wrote:
>> Regardless of where or who we're getting the bugs from, Ehsan's short-list of bugs is a good start.
>>
>> From a quick survey of current Scratchpad bugs, I have these from Ehsan:
>>
>> 687565 Scratchpad doesn't highlight the JS 'let' keyword
>> 687568 Extending the selection causes Scratchpad to scroll without making the selection visible
>> 687573 Scratchpad does not maintain X offset when navigating vertically
>> 687580 Scratchpad doesn't support drag and drop
>> 669011 [RTL] Scratchpad doesn't allow ctrl-shift-x to switch text direction
>>
>> Of these, I'd say 687568 is the only real "blocker" level bug. Possibly 669011 as well, which I'm going to unassign to myself if anyone wants to give it a shot.
>
> 687573 sounds pretty annoying if you run into it. I'm not sure how frequently people would run into it.
> 687580 too. Copy+paste is a workaround, but it's still an annoyance if you expect drag+drop to work.
Agreed on both counts. Probably not going to be highly visible bugs, but they'll be annoying when you encounter them. Vertical offset while scrolling is something Firebug did strangely and I always found that very jarring.
We'll probably see that bug become more critical when we start using Orion for things like Debugger source view.
> I'm skeptical that aurora will help you assess the severity of these issues, as I suspect it doesn't yet have the serious scratchpad users that the scratchpad is made for.
Maybe not, though there are probably a few bleeding-edge webdevs out there who might discover it. Every little layer helps. :)
~ rob
Kevin Dangoor
> 687565 Scratchpad doesn't highlight the JS 'let' keyword
> 687568 Extending the selection causes Scratchpad to scroll without making
> the selection visible
> 687573 Scratchpad does not maintain X offset when navigating vertically
> 687580 Scratchpad doesn't support drag and drop
> 669011 [RTL] Scratchpad doesn't allow ctrl-shift-x to switch text direction
>
> Of these, I'd say 687568 is the only real "blocker" level bug. Possibly
> 669011 as well, which I'm going to unassign to myself if anyone wants to
> give it a shot.
>
>
* Orion is fast, particularly on large files
* better tab handling
* syntax highlighting
* line numbers in the gutter
For editing code, it's just a much better UX, modulo the bugs.
One other note: we should file bugs against Orion where it makes sense to do
so. IBM has told me they have 2 full time people working on the text editor
for the Orion project.
I'll volunteer to do this. Speak up if any of these problems live in our
code rather than Orion's.
Bill Barry
>> I'm skeptical that aurora will help you assess the severity of these issues, as I suspect it doesn't yet have the serious scratchpad users that the scratchpad is made for.
Ehsan Akhgari
<joh...@mozilla.com>wrote:
> On 2011-09-19, at 3:16 PM, Ehsan Akhgari wrote:
> > On Mon, Sep 19, 2011 at 1:24 PM, Kevin Dangoor <kdan...@mozilla.com>
> wrote:
> >
> >> We believe that we should turn on the editor by default in Firefox 9,
> which
> >> is how it's presently set in Nightly and start gathering feedback from
> more
> >> users and real world use.
>
> > Do we have a sense of what would block having this enabled by default?
>
> In a generic sense: "bugs which make the scratchpad with Orion enabled
> net-worse than the scratchpad with Orion disabled."
>
> > I found at least five bugs that I could reproduce reliably and
> > I filed all of them. Have we done a QA run on it to determine the most
> > notable bugs, and decide which ones we're fine shipping with, and which
> ones
> > we need to fix before enabling it by default?
>
> Thank you for filing the bugs! Is it your sense that those things make it a
> less-good editor than shipping with orion disabled?
>
> I think Kevin's point in the original note is that we would rather not make
> the list of "bugs that need to be fixed before enabling it" because we're
> not getting great bug input with it disabled. I think Kevin's arguing for
> "enable it, and see if that uncovers reasons to reverse that decision." Do
> you believe that is a mistake?
>
Maybe. I think we should strive to achieve high quality in the code that we
ship, where possible. I don't think that it's a good idea for us to push
something to the release channel in the hope that we would know if it's bad
when the users on that channel complain.
Here are three specific points to Orion which make me worried.
1. We _know_ that there are problems in the code that we imported from
Orion. I have listed those code problems in the review comments I made, and
I found out about those problems by just reading the code.
2. We don't have test coverage on the editing interactions in Orion. I've
brought this up before, but let me repeat myself: shipping code which we're
not testing at all makes me terribly worried.
3. I found the bugs that I reported yesterday by just using Scratchpad for
10-15 minutes (and these were only the bugs that I could reproduce, I didn't
file the ones which I didn't know how to reproduce). My motivation was to
convince myself that maybe Orion is in a shippable state in practice. Now,
we all know that software has bugs, but I expect the code that we ship on
the stable channel to resist to break when somebody without any QA skills
tries to break it in a short amount of time. :-)
There is another point about Scratchpad which makes getting feedback harder
than usual (it was mentioned elsewhere in this thread too). Scratchpad is a
new tool, so it's quite possible that it's just not part of the workflow of
a lot of web developers. Enabling Scratchpad on aurora/beta/release and not
getting much negative feedback from it does _not_ mean that it's high
quality. I think that we should resort to internal QA, code inspection, and
increasing the test coverage on this as some preliminary techniques in order
to make the code more robust before shipping it on the release channel.
Now, while I don't think that Orion in its current form is in a shippable
state, I won't object to enabling it on Aurora and Beta if the DevTools team
wants to do that. But because of the above reason, I think we should not
rely on the feedback from those channels as a significant quality measure at
this point.
Mike Shaver
> Also keep in mind that we need to balance the good with the bad. The good:
>
> * Orion is fast, particularly on large files
> * better tab handling
> * syntax highlighting
> * line numbers in the gutter
>
> For editing code, it's just a much better UX, modulo the bugs.
in completely on the bugs, since we're all engineering types.
Are those benefits very important for the scratchpad? I can see line
numbers for error reporting, syntax highlighting being a bonus, and
large files not being that big a deal.
Tabs are unclean, so no opinion there.
Mike
Ehsan Akhgari
> On Tue, Sep 20, 2011 at 8:37 AM, Rob Campbell <rcam...@mozilla.com>
> wrote:
>
> > 687565 Scratchpad doesn't highlight the JS 'let' keyword
> > 687568 Extending the selection causes Scratchpad to scroll without making
> > the selection visible
> > 687573 Scratchpad does not maintain X offset when navigating vertically
> > 687580 Scratchpad doesn't support drag and drop
> > 669011 [RTL] Scratchpad doesn't allow ctrl-shift-x to switch text
> direction
>
Just filed a few new ones:
*687850* <https://bugzilla.mozilla.org/show_bug.cgi?id=687850> - Scratchpad
fails to paste the text content completely
*687855* <https://bugzilla.mozilla.org/show_bug.cgi?id=687855> - Scratchpad
fails to update the syntax highlighting correctly with modifications to the
DOM
*687860* <https://bugzilla.mozilla.org/show_bug.cgi?id=687860> - Pasting
fails in scratchpad after editing large buffers
*687861* <https://bugzilla.mozilla.org/show_bug.cgi?id=687861> - Horizontal
scrolling in scratchpad with very long lines is slow
*687865* <https://bugzilla.mozilla.org/show_bug.cgi?id=687865> - Line
insertion in scratchpad with very long lines is slow
> Also keep in mind that we need to balance the good with the bad.
Of course!
> The good:
>
> * Orion is fast, particularly on large files
>
As I understand it, that is only an advantage on files with extremely long
lines, right? When I did a bit of perf testing, I also saw some downsides
(see 687861 and 687865).
> * better tab handling
>
Compared to a plain textarea, for sure. But that's just because a plain
textarea is not designed to be a code editor, and doesn't have special tab
handling. I don't find that a fair advantage point over the alternative!
> * syntax highlighting
> * line numbers in the gutter
>
Yep, these two are definitely advantages.
> For editing code, it's just a much better UX, modulo the bugs.
>
I would argue that depending on which bugs you hit, it might be better or
worse UX. But I agree that in general, Orion-based scratchpad definitely
looks better.
> One other note: we should file bugs against Orion where it makes sense to
> do
> so. IBM has told me they have 2 full time people working on the text editor
> for the Orion project.
>
> I'll volunteer to do this. Speak up if any of these problems live in our
> code rather than Orion's.
>
I think most of these bugs that I've filed are Orion bugs, so please feel
free to upstream them. The perf ones we might need to fix on the Gecko
side, but there might be stuff which Orion can do better in order to feel
faster.
--
Ehsan
<http://ehsanakhgari.org/>
Mihai Sucan
écrit:
> One other note: we should file bugs against Orion where it makes sense
> to do
> so. IBM has told me they have 2 full time people working on the text
> editor
> for the Orion project.
>
> I'll volunteer to do this. Speak up if any of these problems live in our
> code rather than Orion's.
The majority of bugs reported by Ehsan are indeed upstream bugs that need
to be fixed in Orion.
Mihai Sucan
<ehsan....@gmail.com> a écrit:
> *687861* <https://bugzilla.mozilla.org/show_bug.cgi?id=687861> -
> Horizontal
> scrolling in scratchpad with very long lines is slow
> *687865* <https://bugzilla.mozilla.org/show_bug.cgi?id=687865> - Line
> insertion in scratchpad with very long lines is slow
very long lines. I believe it's the same problem in Gecko affecting
Orion's and textarea's performance.
Boris Zbarsky
> Le Tue, 20 Sep 2011 18:53:22 +0300, Ehsan Akhgari
> <ehsan....@gmail.com> a écrit:
>
>> *687861* <https://bugzilla.mozilla.org/show_bug.cgi?id=687861> -
>> Horizontal
>> scrolling in scratchpad with very long lines is slow
>> *687865* <https://bugzilla.mozilla.org/show_bug.cgi?id=687865> - Line
>> insertion in scratchpad with very long lines is slow
>
> Afaik, the <textarea> editor is also very slow with a lot of content,
> with very long lines.
performance to that of a textarea and noting that he Orion performance
is much much worse right there in the steps to reproduce.
> I believe it's the same problem in Gecko affecting
> Orion's and textarea's performance.
-Boris
Rob Campbell
On 2011-09-20, at 12:10 , Bill Barry wrote:
> On 9/20/2011 7:16 AM, Rob Campbell wrote:
> I am an Aurora user looking forward to it. I'd presume that I am not alone.
Thanks,
Rob
Cedric Vivier
> On 9/20/11 12:23 PM, Mihai Sucan wrote:
>>
>> Le Tue, 20 Sep 2011 18:53:22 +0300, Ehsan Akhgari
>> <ehsan....@gmail.com> a écrit:
>>> insertion in scratchpad with very long lines is slow
>>
>> Afaik, the <textarea> editor is also very slow with a lot of content,
>> with very long lines.
>
> If you actually read the bugs Ehsan filed, he in fact has comparing the
> performance to that of a textarea and noting that he Orion performance is
> much much worse right there in the steps to reproduce.
However inserting text within a pre-existing very long line seems
quite artificial use case imho compared to just displaying/resizing
text with long lines.
The textarea is slow with the latter, Orion is not.
Not many users edit directly inside minified code.
Mike Shaver
> However inserting text within a pre-existing very long line seems
> quite artificial use case imho compared to just displaying/resizing
> text with long lines.
>
> The textarea is slow with the latter, Orion is not.
> Not many users edit directly inside minified code.
lot of web hacking lately). There's often a string or number in there
that I want to change, and it's findable for my editing. If I had a
scratchpad I would do it more often, either in situ editing or adding
stuff afterwards.
Which users are you tracking/surveying to find out that they don't
edit that way? A lot of the JS on the web is minified these days!
Mike
Cedric Vivier
> I do all the time (by which I mean weekly, I guess, but I don't do a
> lot of web hacking lately). There's often a string or number in there
> that I want to change, and it's findable for my editing.
> edit that way? A lot of the JS on the web is minified these days!
If you copy-paste code from elsewhere, why would you use a minified version?
If editing minified code is a frequent use case, we should rather prettify it
automatically... (which makes the problem moot)
Kevin Dangoor
>
> There is another point about Scratchpad which makes getting feedback harder
> than usual (it was mentioned elsewhere in this thread too). Scratchpad is a
> new tool, so it's quite possible that it's just not part of the workflow of
> a lot of web developers. Enabling Scratchpad on aurora/beta/release and not
> getting much negative feedback from it does _not_ mean that it's high
> quality. I think that we should resort to internal QA, code inspection, and
> increasing the test coverage on this as some preliminary techniques in order
> to make the code more robust before shipping it on the release channel.
>
>
week is bound to get a lot more use and is getting close to landing. We'll
definitely get some real feedback there.
> Now, while I don't think that Orion in its current form is in a shippable
> state, I won't object to enabling it on Aurora and Beta if the DevTools team
> wants to do that. But because of the above reason, I think we should not
> rely on the feedback from those channels as a significant quality measure at
> this point.
>
>
carefully, and I appreciate all of your input.
Boris Zbarsky
> *687861*<https://bugzilla.mozilla.org/show_bug.cgi?id=687861> - Horizontal
> scrolling in scratchpad with very long lines is slow
off in the weeds doing style modification and then layout flushes, which
means that on every scroll all the text has to be laid out all over
again. I have no idea why they're doing that for horizontal scrolls...
I don't even quite know why they do it for vertical scrolls, past the
minimum needed to hide the lines scrolled out of view and show the ones
scrolled into view.
> *687865*<https://bugzilla.mozilla.org/show_bug.cgi?id=687865> - Line
> insertion in scratchpad with very long lines is slow
around layout engine optimizations."
-Boris
Ehsan Akhgari
> On Tue, Sep 20, 2011 at 11:17 AM, Ehsan Akhgari <ehsan....@gmail.com>wrote:
>
>>
>> There is another point about Scratchpad which makes getting feedback
>> harder than usual (it was mentioned elsewhere in this thread too).
>> Scratchpad is a new tool, so it's quite possible that it's just not part of
>> the workflow of a lot of web developers. Enabling Scratchpad on
>> aurora/beta/release and not getting much negative feedback from it does
>> _not_ mean that it's high quality. I think that we should resort to
>> internal QA, code inspection, and increasing the test coverage on this as
>> some preliminary techniques in order to make the code more robust before
>> shipping it on the release channel.
>>
>>
> Yes, this is all true. However, the Style Editor which everyone saw last
> week is bound to get a lot more use and is getting close to landing. We'll
> definitely get some real feedback there.
>
curious to see it. :-)
--
Ehsan
<http://ehsanakhgari.org/>
Kevin Dangoor
> Agreed, and thanks for calling out the benefits -- it's easy to narrow
> in completely on the bugs, since we're all engineering types.
>
> Are those benefits very important for the scratchpad? I can see line
> numbers for error reporting, syntax highlighting being a bonus, and
> large files not being that big a deal.
>
referring to files with many lines... Cedric had found a great test case in
the form of the GitHub stylesheet (the Style Editor has a feature where it
automatically expands what it detects as minified files). I think it was
about 21,000 lines. Hopefully that's not the common case for css editing
though!
> Tabs are unclean, so no opinion there.
>
>
all of the friendly behavior around pressing tab and getting four spaces,
pressing delete once to get rid of those four spaces, indenting the next
line to the level of the previous, etc.
I personally get most annoyed at text areas for lacking those behaviors.
IIRC, we did add "tab to insert four spaces" behavior to Scratchpad's
textarea.
Kevin Dangoor
> Everybody has _not_ seen the Style Editor. I definitely haven't, and I'm
> curious to see it. :-)
>
>
http://neonux.com/StyleEditor/builds/
Run the latest (0.3.0) version on Nightly.
Boris Zbarsky
> I'm also thinking in terms of the Style Editor. By "large files", I was
> referring to files with many lines... Cedric had found a great test case in
> the form of the GitHub stylesheet (the Style Editor has a feature where it
> automatically expands what it detects as minified files). I think it was
> about 21,000 lines. Hopefully that's not the common case for css editing
> though!
"average" CSS.
Now the real pain comes from O(N^2) algorithms, so "several thousand"
and "21,000" is a big difference. But when dealing with real-world
sites we should be expecting thousands of lines, or very long lines or
both depending on prettyprinting settings.
-Boris
Ehsan Akhgari
> On 9/20/11 11:53 AM, Ehsan Akhgari wrote:
>
>> scrolling in scratchpad with very long lines is slow
>>
>
> This is an Orion bug, pure and simple. On every scroll event it goes off
> in the weeds doing style modification and then layout flushes, which means
> that on every scroll all the text has to be laid out all over again. I have
> no idea why they're doing that for horizontal scrolls... I don't even quite
> know why they do it for vertical scrolls, past the minimum needed to hide
> the lines scrolled out of view and show the ones scrolled into view.
>
http://mxr.mozilla.org/mozilla-central/source/browser/devtools/sourceeditor/orion/orion.js#3155>.
What Orion does is pretty bad here, it basically handles scrolling all by
itself, and sets scrollTop/scrollLeft properties every time, which basically
means one flush per scrolling event.
Reading their code, it seems like they handle scrolling themselves in order
to be able to do line-based vertical scrolling, but not on Mac, so as a Mac
user, I end up paying for pixel-based scrolling, which the browser can
handle more efficiently.
>
> *687865*<https://bugzilla.**mozilla.org/show_bug.cgi?id=**687865<https://bugzilla.mozilla.org/show_bug.cgi?id=687865>>
>> insertion in scratchpad with very long lines is slow
>>
>
> My summary of this one is "It's like a textbook example of how to work
> around layout engine optimizations.
library, which probably needs to handle crazy stuff in multiple engines.
That might hurt performance in Gecko if we have to pay for the thing they're
doing to work around other engines.
--
Ehsan
<http://ehsanakhgari.org/>
Ehsan Akhgari
> Le Tue, 20 Sep 2011 18:53:22 +0300, Ehsan Akhgari <ehsan....@gmail.com>
> a écrit:
>
>>
>> scrolling in scratchpad with very long lines is slow
>>
>> insertion in scratchpad with very long lines is slow
>>
>
> and textarea's performance
In order to fix the incorrect assumption, the parts of Gecko which handle
textareas and the parts of it which handle Orion are quite different, and we
have the stuff that Orion does on top it, so any comparison between Orion
and plain textareas without measurements will be comparing apples and
oranges. :-)
Boris Zbarsky
> I actually investigated this. Orion implements its own scrolling<
> http://mxr.mozilla.org/mozilla-central/source/browser/devtools/sourceeditor/orion/orion.js#3155>.
> What Orion does is pretty bad here, it basically handles scrolling all by
> itself, and sets scrollTop/scrollLeft properties every time, which basically
> means one flush per scrolling event.
Just setting scroll* would not flush on its own, and doesn't involve
any style changes.
Also, the code you link to is what handles wheel events; I was profiling
using the scroll arrows directly. I expect both end up in the same
place eventually, though tracing through all the indirection in the
event dispatch is a bit of a pain.
> Reading their code, it seems like they handle scrolling themselves in order
> to be able to do line-based vertical scrolling, but not on Mac, so as a Mac
> user, I end up paying for pixel-based scrolling, which the browser can
> handle more efficiently.
happening at all.
>> My summary of this one is "It's like a textbook example of how to work
>> around layout engine optimizations.
>
> Yep, indeed. One of the things with Orion is that it's a cross-browser
> library, which probably needs to handle crazy stuff in multiple engines.
> That might hurt performance in Gecko if we have to pay for the thing they're
> doing to work around other engines.
similarly defeating.
The real issues here are:
1) Lack of APIs to ask for information _without_ recomputing it.
2) Intermixing of querying layout info and changing things (a
well-known performance no-no).
3) Some performance issues on our part due to them being create/destroy
happy with the DOM (see analysis in bug 638452).
4) Reimplementing parts of browser functionality. This part may be
due to the cross-browser bit....
-Boris
Ehsan Akhgari
> Reading their code, it seems like they handle scrolling themselves in
>> order
>> to be able to do line-based vertical scrolling, but not on Mac, so as a
>> Mac
>> user, I end up paying for pixel-based scrolling, which the browser can
>> handle more efficiently.
>>
>
> Yep. And in any case, for _horizontal_ scrolling all this should not be
> happening at all.
>
Right.
My summary of this one is "It's like a textbook example of how to work
>>> around layout engine optimizations.
>>>
>>
>> Yep, indeed. One of the things with Orion is that it's a cross-browser
>> library, which probably needs to handle crazy stuff in multiple engines.
>> That might hurt performance in Gecko if we have to pay for the thing
>> they're
>> doing to work around other engines.
>>
>
> Other engines actually have similar optimizations which Orion is similarly
> defeating.
>
> The real issues here are:
>
> 1) Lack of APIs to ask for information _without_ recomputing it.
>
That's something that might be fixed in some of the cases.
> 2) Intermixing of querying layout info and changing things (a
> well-known performance no-no).
>
That can be fixed in Orion.
> 3) Some performance issues on our part due to them being create/destroy
> happy with the DOM (see analysis in bug 638452).
>
Yeah, we can fix those on our side without Orion doing anything.
> 4) Reimplementing parts of browser functionality. This part may be
> due to the cross-browser bit....
Yes. Which brings me back to my original review comment, saying "we should
rewrite their TextView class".
--
Ehsan
<http://ehsanakhgari.org/>
Kevin Dangoor
I filed a handful of bugs upstream and sent email to IBM's project leader
for Orion.
The copy and paste bugs in particular are ones that I think will bother a
great many users of the Scratchpad and Style Editor, and I agree with
Ehsan's point that Orion is not ready to turn on yet.
Everyone I've spoken to seems to agree on the long term solution here: make
better content-accessible APIs so that people can create great editors in JS
and get accessibility and internationalization for free or at least cheap.
Ehsan recently wrote about improving the editor APIs [1].
I'll talk with Ehsan, Mihai and the Orion people to figure out what the
right short-term solution is, get the feature page updated and report back
here.
Kevin
[1]: http://ehsanakhgari.org/blog/2011-08-31/future-editing-web
On Tue, Sep 20, 2011 at 3:09 PM, Ehsan Akhgari <ehsan....@gmail.com>wrote:
> On Tue, Sep 20, 2011 at 2:30 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>
> > Reading their code, it seems like they handle scrolling themselves in
> >> order
> >> to be able to do line-based vertical scrolling, but not on Mac, so as a
> >> Mac
> >> user, I end up paying for pixel-based scrolling, which the browser can
> >> handle more efficiently.
> >>
> >
> > Yep. And in any case, for _horizontal_ scrolling all this should not be
> > happening at all.
> >
>
> Right.
>
> My summary of this one is "It's like a textbook example of how to work
> >>> around layout engine optimizations.
> >>>
> >>
> >> Yep, indeed. One of the things with Orion is that it's a cross-browser
> >> library, which probably needs to handle crazy stuff in multiple engines.
> >> That might hurt performance in Gecko if we have to pay for the thing
> >> they're
> >> doing to work around other engines.
> >>
> >
> > Other engines actually have similar optimizations which Orion is
> similarly
> > defeating.
> >
> > The real issues here are:
> >
> > 1) Lack of APIs to ask for information _without_ recomputing it.
> >
>
> That's something that might be fixed in some of the cases.
>
>
> > 2) Intermixing of querying layout info and changing things (a
> > well-known performance no-no).
> >
>
> That can be fixed in Orion.
>
>
> > 3) Some performance issues on our part due to them being create/destroy
> > happy with the DOM (see analysis in bug 638452).
> >
>
> Yeah, we can fix those on our side without Orion doing anything.
>
>
> > 4) Reimplementing parts of browser functionality. This part may be
> > due to the cross-browser bit....
>
>
> Yes. Which brings me back to my original review comment, saying "we should
> rewrite their TextView class".
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox