Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Fission Newsletter #2
453 views
Skip to first unread message
Nika Layzell
Aug 9, 2019, 1:33:57 PM8/9/19
to dev-platform
Hey all!
It's been a while (7 months!) since the first Fission newsletter, but we've
made some exciting progress we'd love to tell you about!
Enabling Fission on Nightly
It's now possible to turn on Fission in nightly builds of Firefox by
setting fission.autostart pref to true. Fission can also be enabled for
running tests using mach test … --enable-fission.
When Fission is enabled, each cross-site iframe is loaded in a different
content process, meaning lots of different processes participate in drawing
a single tab. The hover tooltip for a Fission-enabled tab is annotated with
a "[F …]" containing a series of process IDs, as shown in the image below,
serving as a visual verification of an active Fission-enabled session.
We currently do not recommend trying to use Fission for day-to-day
browsing, as there are still known stability issues. However, if you do try
it out, please file bugs/issues blocking fission-dogfooding
<https://bugzilla.mozilla.org/show_bug.cgi?id=fission-dogfooding>.
Fission Mochitests on mozilla-central
Fission Mochitests were recently enabled as tier-2 jobs on mozilla-central.
This will allow us to run tests with Fission enabled on infrastructure, and
prevent landing new features or code which don't support Fission. Tests
which do not currently successfully pass are marked as fail-if =
Fission or skip-if
= Fission.
We'd love your help migrating tests to run with Fission enabled! Here are a
couple of handy tips for making your test Fission-compatible:
1.
Use SpecialPowers.spawn(target, [args…], async (args…) => { … }), to run
code in potentially cross-origin iframes, as they may be in a different
process. This API is similar to the ContentTask.spawn API used by
browser-chrome mochitests.
2.
Wait for document loads to complete before trying to run code inside the
target window, as a process switch may occur after the frame or browser is
created. For frames in content, this usually means waiting for the load
event.
These tests may also be run on the tryserver, however they are currently
excluded from the default set. They are called M-fis, and can be found
in ./mach
try fuzzy --full.
Fixing these Mochitests is a goal of our next major milestone, M4! There's
a ton of awesome stuff happening in M4, which you can read about on the
wiki (https://wiki.mozilla.org/Project_Fission#M4_goals).
Fission Talk and Demo
At the 2019 Whistler All-Hands, Nika gave a talk & demo about the Fission
architecture. This talk is publicly available on Air Mozilla.
You can watch the talk here:
https://onlinexperiences.com/Launch/Event.htm?ShowKey=44908&DisplayItem=E334923
The slides are here:
https://docs.google.com/presentation/d/1equyaJTujM4xF-ucoMZiLE-lo0lbHKFMliUfPE4_1B8/edit?usp=sharing
And… So Much More!
A ton has happened in Fission over those 7 months, and it would be
impossible to cover all of the awesome work everyone has been contributing
to make Fission happen. We just want to say a massive thank you to everyone
who has helped with Fission - writing patches, doing reviews, planning, and
more! We hope to do brief update newsletters like this one with a better
cadence, so hopefully there'll be another one of these in your inbox soon.
Let's keep fission-on!
- The Fission Team.
It's been a while (7 months!) since the first Fission newsletter, but we've
made some exciting progress we'd love to tell you about!
Enabling Fission on Nightly
It's now possible to turn on Fission in nightly builds of Firefox by
setting fission.autostart pref to true. Fission can also be enabled for
running tests using mach test … --enable-fission.
When Fission is enabled, each cross-site iframe is loaded in a different
content process, meaning lots of different processes participate in drawing
a single tab. The hover tooltip for a Fission-enabled tab is annotated with
a "[F …]" containing a series of process IDs, as shown in the image below,
serving as a visual verification of an active Fission-enabled session.
We currently do not recommend trying to use Fission for day-to-day
browsing, as there are still known stability issues. However, if you do try
it out, please file bugs/issues blocking fission-dogfooding
<https://bugzilla.mozilla.org/show_bug.cgi?id=fission-dogfooding>.
Fission Mochitests on mozilla-central
Fission Mochitests were recently enabled as tier-2 jobs on mozilla-central.
This will allow us to run tests with Fission enabled on infrastructure, and
prevent landing new features or code which don't support Fission. Tests
which do not currently successfully pass are marked as fail-if =
Fission or skip-if
= Fission.
We'd love your help migrating tests to run with Fission enabled! Here are a
couple of handy tips for making your test Fission-compatible:
1.
Use SpecialPowers.spawn(target, [args…], async (args…) => { … }), to run
code in potentially cross-origin iframes, as they may be in a different
process. This API is similar to the ContentTask.spawn API used by
browser-chrome mochitests.
2.
Wait for document loads to complete before trying to run code inside the
target window, as a process switch may occur after the frame or browser is
created. For frames in content, this usually means waiting for the load
event.
These tests may also be run on the tryserver, however they are currently
excluded from the default set. They are called M-fis, and can be found
in ./mach
try fuzzy --full.
Fixing these Mochitests is a goal of our next major milestone, M4! There's
a ton of awesome stuff happening in M4, which you can read about on the
wiki (https://wiki.mozilla.org/Project_Fission#M4_goals).
Fission Talk and Demo
At the 2019 Whistler All-Hands, Nika gave a talk & demo about the Fission
architecture. This talk is publicly available on Air Mozilla.
You can watch the talk here:
https://onlinexperiences.com/Launch/Event.htm?ShowKey=44908&DisplayItem=E334923
The slides are here:
https://docs.google.com/presentation/d/1equyaJTujM4xF-ucoMZiLE-lo0lbHKFMliUfPE4_1B8/edit?usp=sharing
And… So Much More!
A ton has happened in Fission over those 7 months, and it would be
impossible to cover all of the awesome work everyone has been contributing
to make Fission happen. We just want to say a massive thank you to everyone
who has helped with Fission - writing patches, doing reviews, planning, and
more! We hope to do brief update newsletters like this one with a better
cadence, so hopefully there'll be another one of these in your inbox soon.
Let's keep fission-on!
- The Fission Team.
Nika Layzell
Aug 9, 2019, 1:43:14 PM8/9/19
to dev-platform
Looks like gmail chewed up the formatting :-S
Published gdocs link:
https://docs.google.com/document/d/e/2PACX-1vTuGpZNthNxk0OYRyBjiHpaKnyKdmb9AompceuncvFmjeXB0bfk-L_LSlQmRaqiqx8vKif-LzdnE2F8/pub
Published gdocs link:
https://docs.google.com/document/d/e/2PACX-1vTuGpZNthNxk0OYRyBjiHpaKnyKdmb9AompceuncvFmjeXB0bfk-L_LSlQmRaqiqx8vKif-LzdnE2F8/pub
Alexis Beingessner
Aug 9, 2019, 1:55:17 PM8/9/19
to Nika Layzell, dev-platform
Is dogfoodability at all platform-specific for fission? i.e. is windows the
only platform that is really actively developed/maintained? (as would make
sense at this stage)
More concretely, I was under the impression that fission had webrender as a
dependency, is that mandatory? Is it actually enforced by the fission pref?
(webrender's support of different platforms has varying levels of quality,
although it is generally dogfoodable on all major platforms)
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
only platform that is really actively developed/maintained? (as would make
sense at this stage)
More concretely, I was under the impression that fission had webrender as a
dependency, is that mandatory? Is it actually enforced by the fission pref?
(webrender's support of different platforms has varying levels of quality,
although it is generally dogfoodable on all major platforms)
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Nika Layzell
Aug 9, 2019, 2:11:13 PM8/9/19
to Alexis Beingessner, dev-platform
On Fri, Aug 9, 2019 at 1:55 PM Alexis Beingessner <a.bein...@gmail.com>
wrote:
> Is dogfoodability at all platform-specific for fission? i.e. is windows
> the only platform that is really actively developed/maintained? (as would
> make sense at this stage)
>
The platform shouldn't have much impact, as we're generally working on
non-platform-specific functionality at this point. The most testing has
been done on Linux at this stage, though we're still very-much in early
days. I wouldn't recommend using fission for day-to-day browsing, as sites
with many cross-site iframes can be very slow to load and quite unstable.
> More concretely, I was under the impression that fission had webrender as
> a dependency, is that mandatory? Is it actually enforced by the fission
> pref? (webrender's support of different platforms has varying levels of
> quality, although it is generally dogfoodable on all major platforms)
>
We don't have a hard webrender dependency, and the browser should work
mostly-the-same on all platforms. Some edge cases with mouse event
targeting may work better with webrender enabled.
wrote:
> Is dogfoodability at all platform-specific for fission? i.e. is windows
> the only platform that is really actively developed/maintained? (as would
> make sense at this stage)
>
non-platform-specific functionality at this point. The most testing has
been done on Linux at this stage, though we're still very-much in early
days. I wouldn't recommend using fission for day-to-day browsing, as sites
with many cross-site iframes can be very slow to load and quite unstable.
> More concretely, I was under the impression that fission had webrender as
> a dependency, is that mandatory? Is it actually enforced by the fission
> pref? (webrender's support of different platforms has varying levels of
> quality, although it is generally dogfoodable on all major platforms)
>
mostly-the-same on all platforms. Some edge cases with mouse event
targeting may work better with webrender enabled.
Bobby Holley
Aug 9, 2019, 2:37:32 PM8/9/19
to Nika Layzell, Alexis Beingessner, dev-platform
On Fri, Aug 9, 2019 at 11:11 AM Nika Layzell <ni...@thelayzells.com> wrote:
> On Fri, Aug 9, 2019 at 1:55 PM Alexis Beingessner <a.bein...@gmail.com
> >
> wrote:
>
> > Is dogfoodability at all platform-specific for fission? i.e. is windows
> > the only platform that is really actively developed/maintained? (as would
> > make sense at this stage)
> >
>
> The platform shouldn't have much impact, as we're generally working on
> non-platform-specific functionality at this point. The most testing has
> been done on Linux at this stage, though we're still very-much in early
> days. I wouldn't recommend using fission for day-to-day browsing, as sites
> with many cross-site iframes can be very slow to load and quite unstable.
>
>
> > More concretely, I was under the impression that fission had webrender as
> > a dependency, is that mandatory? Is it actually enforced by the fission
> > pref? (webrender's support of different platforms has varying levels of
> > quality, although it is generally dogfoodable on all major platforms)
> >
>
> We don't have a hard webrender dependency, and the browser should work
> mostly-the-same on all platforms. Some edge cases with mouse event
> targeting may work better with webrender enabled.
>
I believe the primary issue is that we need WebRender to hit our Fission
> On Fri, Aug 9, 2019 at 1:55 PM Alexis Beingessner <a.bein...@gmail.com
> >
> wrote:
>
> > Is dogfoodability at all platform-specific for fission? i.e. is windows
> > the only platform that is really actively developed/maintained? (as would
> > make sense at this stage)
> >
>
> The platform shouldn't have much impact, as we're generally working on
> non-platform-specific functionality at this point. The most testing has
> been done on Linux at this stage, though we're still very-much in early
> days. I wouldn't recommend using fission for day-to-day browsing, as sites
> with many cross-site iframes can be very slow to load and quite unstable.
>
>
> > More concretely, I was under the impression that fission had webrender as
> > a dependency, is that mandatory? Is it actually enforced by the fission
> > pref? (webrender's support of different platforms has varying levels of
> > quality, although it is generally dogfoodable on all major platforms)
> >
>
> We don't have a hard webrender dependency, and the browser should work
> mostly-the-same on all platforms. Some edge cases with mouse event
> targeting may work better with webrender enabled.
>
memory targets.
Kris Maglione
Aug 9, 2019, 7:57:23 PM8/9/19
to Nika Layzell, dev-platform
On Fri, Aug 09, 2019 at 01:33:31PM -0400, Nika Layzell wrote:
>Tests which do not currently successfully pass are marked as
>fail-if = Fission or skip-if = Fission.
To be slightly pedantic, they're marked as `fail-if = fission` or
>Tests which do not currently successfully pass are marked as
>fail-if = Fission or skip-if = Fission.
`skip-if = fission`. mozinfo expression matching should be case
sensitive, so if you try to use `Fission` instead, it won't work.
Henrik Skupin
Aug 19, 2019, 12:38:46 PM8/19/19
to
Nika Layzell wrote on 09.08.19 19:33:
> Wait for document loads to complete before trying to run code inside the
> target window, as a process switch may occur after the frame or browser is
> created. For frames in content, this usually means waiting for the load
> event.
While working to get the new screenshot API into Marionette I noticed a
couple of problems, which were all related to page load events inside
OOP iframes.
The underlying reason is that the top-browsing context doesn't wait yet,
until all the documents of OOP frames have been finished loading. See
bug 1559841.
Please be aware of that if you run into intermittent failures.
> Wait for document loads to complete before trying to run code inside the
> target window, as a process switch may occur after the frame or browser is
> created. For frames in content, this usually means waiting for the load
> event.
couple of problems, which were all related to page load events inside
OOP iframes.
The underlying reason is that the top-browsing context doesn't wait yet,
until all the documents of OOP frames have been finished loading. See
bug 1559841.
Please be aware of that if you run into intermittent failures.
0 new messages