Living in a Go Faster, post-XUL world

[David Rajchenbach-Teller]

So, we have reached a stage at which we basically agree that we should
get rid of XUL. We also want to support Go Faster-style piecewise
updates of Firefox. We want Firefox to start fast. We want the UI to
remain responsive. We want to keep supporting add-ons. Oh, and we want
contributors, too. And we don't want to lose internationalization.
Mmmh... and perhaps we don't want to restart Firefox from bare Gecko.

All of the above are worthy objectives, but getting them all will
require some careful thought.

So I'd like to put together a list of all our requirements, against
which we could evaluate potential solutions, re-architectures, etc. for
the front-end:


** High-level
* Get rid of the deprecated (XUL) bits of Gecko in a finite time.
* Don't break Firefox [1].


** User-oriented goals.
* Firefox should start fast.
* The UI should not suffer from jank.
* The UI should not cause jank.
* Look and feel like a native app, even with add-ons.
* Keep supporting internationalization.
* Keep supporting lightweight themes.


** Contributor/dev-oriented goals.
* Use technologies that the world understands.
* Use technologies that are useful to add-on authors.
* Support piece-wise, restart-less front-end updates.
* Provide an add-ons API that won't break.
* Code the front-end with the add-ons API.

[1] I have heard this claim contested. Some apparently suggest that we
should actually break Firefox and base all our XUL-less, Go Faster
initiatives on a clean slate from e.g. Browser.html or Servo. If you
wish to defend this, please step forward :)


Does this sound like a correct list for all of you?

Cheers,
David

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Gijs Kruitbosch]

On 13 July 2015 at 14:13, David Rajchenbach-Teller <dte...@mozilla.com> wrote:

* Code the front-end with the add-ons API.

If add-ons are sandboxed in some meaningful way, not all browser functionality will be writable with the add-ons API. That is still besides the obvious bootstrapping problem of providing the add-ons API... by using the add-ons API? :-)

I understand and support the idea that we wish to deliver parts of the browser front-end out-of-band. I don't know that we should therefore assume that the entire front-end is coded on the add-ons API (especially if such an API were usably high-level).

~ Gijs

[David Rajchenbach-Teller]

Well, I don't think sandboxing is an issue. But fair enough, let's make this

* Code as much as possible of the front-end with the add-ons API.

On 13/07/15 15:22, Gijs Kruitbosch wrote:
> On 13 July 2015 at 14:13, David Rajchenbach-Teller <dte...@mozilla.com

[Ian Bicking]

On Mon, Jul 13, 2015 at 9:13 AM, David Rajchenbach-Teller <dte...@mozilla.com> wrote:

** High-level
* Get rid of the deprecated (XUL) bits of Gecko in a finite time.
* Don't break Firefox [1].

I think this is a huge challenge. If we deprecate XUL (meaning we implement new things in HTML, try to make the amount of Firefox using XUL smaller over time) then we are increasing the complexity of development, as the period of transition will be significantly more complex than the status quo.  An unfinished transition plan will itself significantly add to complexity, as everyone will constantly have to ask: what is the right way to do something *today*.  The only win for complexity is when XUL is actually eliminated, and it might be years *after* XUL is eliminated before we see a net gain on that investment given the cost of the transition.

If we want to reduce complexity, while simultaneously working on everything else we want to do in Firefox, my hunch is that we should have a plan in place that eliminates XUL all at once, rather than deprecate it over time.  That's not easy, but I think we would save time and effort by investing hundreds, even a thousand or more person-hours into coming up with a definitive approach – an approach that doesn't add a tax to all ongoing work, and an approach that reaches a conclusion.

Speculating a bit what that might look like: that kind of approach would require that the bulk of the work happen as tooling entirely separate from mozilla-central.  It wouldn't attempt to re-implement all the logic embodied in XUL, but it would reimagine that logic in a different context.  That might be something like React Native where the markup is turned into native controls.  Or it might be something like Web Components where XUL becomes a set of components built on HTML.  Ideally most code could be converted automatically.  Things that couldn't be converted should at least be detected, and ideally could be converted by hand in mozilla-central to a XUL pattern that was more amenable to automatic conversion.  The team might land linters so that problematic constructs didn't get reintroduced.  Ideally tests that worked pre-conversion would work post-conversion (and getting those tests passing would be a target), though I would expect that test fragility would be a serious problem.

Obviously a very hard problem, and I honestly don't have any guess on the best way to execute any of the many details, but this is my sense of a process by which we could come to a positive conclusion.

--

Ian Bicking | Engineering Manager | Firefox Group | Mozilla

[David Rajchenbach-Teller]

Interesting point, but I don't think that your suggested approach would
solve the problem of the transition period. I fear that this would leave
us with:
- something very, very hard to land;
- broken add-ons;
- front-end & add-ons developers who don't know how to code in the new
style;
- few developers with a huge burden of maintaining all of the front-end,
plus the compatibility tool, until they can form replacements.

P.S.: I'm starting to feel that there is no solution that passes all
criteria.

Cheers,
David

[Eric Shepherd]

David Rajchenbach-Teller wrote:

Well, I don't think sandboxing is an issue. But fair enough, let's make this

I think you can come up with a phased sandboxing solution; that is, you can use a permissions-based mechanism by which code that is signed and authenticated can access core Gecko stuff in ways that other code cannot. You could even potentially have something like

• "Add-ons" which are signed by Firefox-Core (or whoever builds and signs the application for distribution) and bundled into the app at build time can touch anything they want to; the trade-off, however, is that these cannot be updated out of band; the application requires a full update (since the entire package including these add-ons are signed together).
• Add-ons which are signed by Firefox-Feature (or whatever you want to call it) are not part of the core application like the ones above, but by virtue of how they're signed and the permissions granted to that key have access to a vast swath of internals that typical add-ons don't need access to.
• Add-ons which have been signed and have gone through AMO certification have access to the next tier of internals. They can access a lot of stuff that the serious add-ons need to be able to get at, but not the really deep internals of Firefox that they should avoid. This layer of access might include APIs that grant partial access to deeper levels of Firefox in a controlled manner.
• All other add-ons have no access to Firefox internals of any kind, and only function in DOM space and whatever areas of Firefox's UX are deemed "safe".
• You might have one more tier of signed add-ons which have limited access, or even types of signing and permissions which allow them to be restricted in various ways. Some of this depends on what we're willing to invest both in Firefox and AMO.

If we're going to do this massive a change to how Firefox works, I applaud any efforts we make to do it right; better to take our time and do a good job of it than turn it into a disaster. :)

I'd also love to encourage y'all to ping the Developer Relations and MDN teams any time you have thoughts that might benefit from being bounced off people who arguably spend the most time directly interacting with add-on developers. Not to mention that we're the ones that will have to explain whatever you decide to the community. :)

--

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability

[David Rajchenbach-Teller]

On 15/07/15 04:51, Eric Shepherd wrote:
> If we're going to do this massive a change to how Firefox works, I
> applaud any efforts we make to do it right; better to take our time and
> do a good job of it than turn it into a disaster. :)

As a side-note, the magnitude of efforts to do it right is juuuuust a
little bit daunting.

> I'd also love to encourage y'all to ping the Developer Relations and MDN
> teams any time you have thoughts that might benefit from being bounced
> off people who arguably spend the most time directly interacting with
> add-on developers. Not to mention that we're the ones that will have to
> explain whatever you decide to the community. :)

Well-noted.

Cheers,
David

[Quicksaver]

On 15-07-2015 03:51, Eric Shepherd wrote:
> I think you can come up with a phased sandboxing solution; that is,
> you can use a permissions-based mechanism by which code that is signed
> and authenticated can access core Gecko stuff in ways that other code
> cannot.

Shouldn't this discrimination be made by the AMO reviewer team as is
done already, by rejecting add-ons that do things they aren't supposed
to? I fail to see how adding more layers of add-on quality control to
the core application itself would help at all on the post-XUL world, not
to mention it would require further man-hours into maintaining some sort
of platform to accept/reject/include/review said "higher priviledged"
add-ons.

Also, and most importantly, I don't understand why this would even be
necessary. As an outsider looking in on the process and assuming parity
between the current XUL-based UI and the future HTML-based UI, the basic
differences between those would be the node names and types - yes,
that's an extremelly gross over-simplification, but I think it's valid
from the point of view of an add-on aiming to modify the UI (these would
be the add-ons most affected by this change?). Whatever an add-on can do
now in XUL should also be able to do in HTML, no?

As an add-on developer, I was enjoying this whole "drop XUL" discussion
up until this point. This was a bit scary, it sounds like there would be
further restrictions of what an add-on can do - unnecessarily. Unless
this is more of a tangent to the main post-XUL discussion (i.e. add more
privileges/abilities to add-ons)? Although it sure doesn't read like that...

(PS. I'm not discriminating between XUL/Overlay-based, bootstrapped and
JetPack/SDK add-ons. Are you? If so that really should be made more clear.)

Luís Miguel

[David Rajchenbach-Teller]

I believe that the idea is that an addon with few/no privileges can be
reviewed quickly – possibly automatically, or possibly by someone with
less experience in the internals of the platform. At the moment, every
addon runs with full privileges, which contributes to making AMO
unresponsive (that and the fact that AMO is sorely understaffed).

All this is related to the post-XUL discussion insofar as we would like
the front-end of Firefox to be written with add-ons. To achieve this
goal, we need add-ons to be able to reach to the depths of Firefox, as
they currently do.

Cheers,
David

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[Eric Shepherd]

David Rajchenbach-Teller wrote:

I believe that the idea is that an addon with few/no privileges can be
reviewed quickly – possibly automatically, or possibly by someone with
less experience in the internals of the platform. At the moment, every
addon runs with full privileges, which contributes to making AMO
unresponsive (that and the fact that AMO is sorely understaffed).

Yeah, exactly. I was proposing levels of access to internals based on permissions and the like because the more of the Firefox internals an add-on wants to touch, the more time and effort AMO team will have to invest in reviewing each update of the add-on. Add-on developers that want to minimize this time will try to keep the permissions level as low as they can.

[Robert Kaiser]

David Rajchenbach-Teller schrieb:

> * Get rid of the deprecated (XUL) bits of Gecko in a finite time.

I don't know why we even state that as a goal in the first place. Also,
you know, even 100 years is "finite", so that word never makes sense to
me by itself. And I don't think anything short- or even mid-term is
realistic. This is a multi-year goal in my eyes and not something to
fully plan out right now.

If it was up to me, I'd rather state goals like
* Replace chrome-only ("XUL") Gecko features with web standards ("HTML")
in controlled steps where an equivalent exists and fix Gecko to make
them perform as well as the "XUL" versions.
* Investigate and develop features that can be made web standards for
anything in "XUL" that doesn't have equivalents yet.

The investigation into the box model that Enn did is IMHO a really good
step into that direction and I hope we do more similar efforts (and fix
performance in this case so we can follow it through).

As always, this is just a personal opinion and my "old guard" view point
may not always be the best one, but it draws on a lot of experience.

KaiRo

[Robert Kaiser]

Gijs Kruitbosch schrieb:
> On 13 July 2015 at 14:13, David Rajchenbach-Teller <dteller-4eJtQOn...@public.gmane.org>

> wrote:
>
>> * Code the front-end with the add-ons API.
>>
>
>
> If add-ons are sandboxed in some meaningful way, not all browser
> functionality will be writable with the add-ons API.

I don't think we can just sandbox all add-ons. I think we probably will
need to end up with two kinds of add-ons: One that is sandboxed and has
only access to a limited API but can go by with very limited review and
signing, if any at all, and another kind that basically is what we have
right now, not sandboxed, with full access to everything, but needing
detailed reviews and string signing.
That said, I also think more than two or three kinds are too much and
get complicated fast (see what we did with web apps on FxOS, the
standard+fully-open / privileged+reviewed / certified+preinstalled-only
groups are a pretty decent model but the latter should be something that
can be eliminated).

KaiRo

[David Rajchenbach-Teller]

What you're doing is suggesting a subset of a specific plan. That's
great, but that was not my objective with this thread.

My objective is to put together a list of things that we want to ensure.
If they all seem self-speaking to you, all the better.

Cheers,
David

P.S.: I can clarify "finite" as "finished long, long before we switch to
Servo", if you prefer.

[Eric Shepherd]

David Rajchenbach-Teller wrote:

P.S.: I can clarify "finite" as "finished long, long before we switch to
Servo", if you prefer.

That helps... a little. :)

I think it's clear (I *hope* it is, anyway) that we need to find ways to do this iteratively, instead of it having to be a single huge, monolithic project that will essentially never be finished.

Figuring out what those iterations are is the trick.

[Gijs Kruitbosch]

Converting our in-content pages, converting our web-facing XBL (video controls come to mind), investigating more or less orthogonal perf improvements for startup (potentially by replacing some bits of XUL with HTML in the main window, but maybe through other means), improving "new" CSS flexbox performance, making an inventory of "XUL things" that we rely on right now that don't have HTML equivalents (XUL persistence, window attributes that get reflected to native code, certain -moz-appearance values, layout for panels/popups where the bounds are determined by the page instead of the bounds being determined for the page, maybe other stuff...) and figuring out paths to replace those, expanding exposed APIs (like e.g. CustomizableUI) to accommodate other things that add-ons currently do with XUL overlays (e.g. "load script X in every browser window", "add menu Y in the Tools menu", "add fancy toolbaritem (not a button) <whatever>" to the set of customizable toolbar items... etc.

All of these can be worked on more or less in parallel. There's probably other things that I've forgotten about.

~ Gijs

[Eric Shepherd (Sheppy)]

Absolutely. There are lots of things that can be parallelized here. Some of the work is obvious, as you point out: redoing basic presentations from XUL to HTML. Figuring out where HTML5 isn't up to the task can be done alongside that work, and we can propose new standards to add the stuff we need to take those next steps.

Sheppy

_____________________________
From: Gijs Kruitbosch <gijskru...@gmail.com>
Sent: Thursday, July 16, 2015 5:18 PM
Subject: Re: Living in a Go Faster, post-XUL world
To: Eric Shepherd <eshe...@mozilla.com>
Cc: Firefox Dev <firef...@mozilla.org>

Converting our in-content pages, converting our web-facing XBL (video controls come to mind), investigating more or less orthogonal perf improvements for startup (potentially by replacing some bits of XUL with HTML in the main window, but maybe through other means), improving "new" CSS flexbox performance, making an inventory of "XUL things" that we rely on right now that don't have HTML equivalents (XUL persistence, window attributes that get reflected to native code, certain -moz-appearance values, layout for panels/popups where the bounds are determined by the page instead of the bounds being determined for the page, maybe other stuff...) and figuring out paths to replace those, expanding exposed APIs (like e.g. CustomizableUI) to accommodate other things that add-ons currently do with XUL overlays (e.g. "load script X in every browser window", "add menu Y in the Tools menu", "add fancy toolbaritem (not a button) <whatever>" to the set of customizable toolbar items... etc.

All of these can be worked on more or less in parallel. There's probably other things that I've forgotten about.

~ Gijs

On 16 July 2015 at 22:07, Eric Shepherd <eshe...@mozilla.com> wrote:

David Rajchenbach-Teller wrote:

P.S.: I can clarify "finite" as "finished long, long before we switch toServo", if you prefer.

That helps... a little. :)

I think it's clear (I *hope* it is, anyway) that we need to find ways to do this iteratively, instead of it having to be a single huge, monolithic project that will essentially never be finished.

Figuring out what those iterations are is the trick.

--

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability

[Russ Thomas]

On 16 July 2015 at 21:44, Eric Shepherd (Sheppy) <eshe...@mozilla.com> wrote:

Absolutely. There are lots of things that can be parallelized here. Some of the work is obvious,

Like this? https://bugzilla.mozilla.org/show_bug.cgi?id=967096

I sincerely hope so - that "platform bug" (as it's been described to me) destroys the firefox-tools UX for me on an hourly basis, day-by-day and it's clear it aint ever gonna get fixed.  Maybe this work (when it gains traction) will make it simply disappear.

Sorry if this is seen as "spamming the thread" but... 

Actually, no, I'm not sorry ;)

Thanks

Russ