Re: Fission Engineering Newsletter #1

[Neha Kochar]

>> Are you including bugs that are about reducing our memory usage
>> with more processes? What about doing better sandboxing of the content
>> process (e.g. ensuring a compromised process can't request information
>> from the parent that isn't relevant to it)?
> This is https://bugzilla.mozilla.org/show_bug.cgi?id=1505832
> Its major sub-bug that pertains specifically to IPC is
> https://bugzilla.mozilla.org/show_bug.cgi?id=fission-ipc

Yes, fission-origin-sandbox, fission-ipc and memshrink-content are all
important parts of Fission and we need to triage the associated sub-bugs
into appropriate Fission milestones. I'll reach out to you on a separate
thread.

Thanks,
Neha.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fission Newsletter #2

[Neha Kochar]

Fission functionality is not platform-restricted as of right now for all
desktop platforms (mobile not there yet). As Bobby said, WebRender
dependency is solely for the memory reduction goal.

-Neha.

On Fri, Aug 9, 2019 at 2:37 PM Bobby Holley  wrote:

> On Fri, Aug 9, 2019 at 11:11 AM Nika Layzell  wrote:
>
> > On Fri, Aug 9, 2019 at 1:55 PM Alexis Beingessner <
> a.beingess...@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
> memory targets.
>
>
> >
> >
> > >
> > > On Fri, Aug 9, 2019 at 1:43 PM Nika Layzell 
> > wrote:
> > >
> > >> Looks like gmail chewed up the formatting :-S
> > >>
> > >> Published gdocs link:
> > >>
> > >>
> >
> https://docs.google.com/document/d/e/2PACX-1vTuGpZNthNxk0OYRyBjiHpaKnyKdmb9AompceuncvFmjeXB0bfk-L_LSlQmRaqiqx8vKif-LzdnE2F8/pub
> > >>
> > >>
> > >> On Fri, Aug 9, 2019 at 1:33 PM Nika Layzell 
> > wrote:
> > >>
> > >> > 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
> > >> > .
> > >> >
> > >> > 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://

Fission Newsletter #8

[Neha Kochar]

Hi All,

It’s been about a month since our last newsletter so here we are with more
exciting updates.

Fission Experiments

To meet our goal of starting Fission experiments, we finished resolving all
highest priority Nightly blockers on July 31st, thereby completing our
Fission milestone M6a. We resolved 121 issues in M6a
.
A huge thank you to the Fission team and everyone who contributed to this
success!

Our next milestone is M6b to fix issues blocking us from starting a small
percentage of Fission experiments in Nightly on Windows and Mac desktop
versions. We are looking to start our Nightly experiment in Fx83,
therefore, our M6b Nightly blockers must be fixed in Fx82 with the soft
freeze date of September 17th. Here is a list of open M6b bugs
.
Please prioritize your component’s issues from this list for a successful
M6b milestone.

We are also tentatively aiming to kick-off a small percentage of Fission
experiments on Beta in Fx85 and Fission M7 milestone is tracking all
blockers for this. Here is a list of open M7 bugs

.

We have also re-defined the related M6c milestone as issues that are
desired to be fixed for  Nightly experiments but will not block enabling
the Nightly experiments. Thesee need to be fixed some time between now and
M7, therefore have a target timeline of Fx82-Fx84. Here is a list of open
M6c bugs

.


Testing with Fission

Fission milestones M4 and M4.1 fixed a majority of Mochitests that were
broken with Fission, but there were some tests that were previously pushed
out to be fixed later because of their dependencies on some unfinished
Fission infrastructure pieces. In addition, :tkhan (Fission contractor
whose last day at Mozilla was Aug 7th) added a cross-origin mode for
Mochitests that runs the tests in a cross origin iframe (thanks Tahia!).
Fission cross-origin mochitests are now running on tier2. All annotated
tests that need to be fixed for Fission are tracked in this spreadsheet

.

Call to Action:

We need the help of component owners to review the test failures

and find out if the failure is due to the feature not working correctly
(i.e. M6b Nightly blocking), or due to the test needing fixes (i.e. M7 for
Beta blocking or M-Future for later). The wiki has some useful pointers
 to
help with that.


Devtools Updates

There is a lot of work to be done in Devtools to make all of it
Fission-compatible and the team continues to make progress. Here’s some
cool new features.

   -

   In the Browser Toolbox, when inspecting XUL documents, you now get the
   same highlighters as in web pages. You can now see the selector and element
   size (bug ).

From:

To:



   -

   Fission support in DevTools is now turned on by default. You no longer
   need to toggle “devtools.contenttoolbox.fission” preference.
   -

   In the Inspector, the markup view (where you see the DOM element in a
   tree) now correctly updates when an out-of-process iframe navigates (bug
   ).



What about:processes?

A nice visual for all the processes that Firefox uses when Fission is
enabled (fission.autostart=true) can be seen with about:processes which has
recently been added by :yoric. It lists the PID, the URL loaded in that
process and the resident memory used by that process, which can come in as
a handy reference for a quick Fission view. We are continuing to make
improvements to it so be on the lookout for a more finished look soon. Here
is an example of how it currently looks.


Another

Fission Newsletter #9

[Neha Kochar]

Greetings Everyone,

A lot has been accomplished since our last newsletter so we are back with
more Fission news in our Newsletter #9.

Experimenting with Fission in Nightly

With the completion of Fission milestone M6b, Fission Nightly experiment
was launched for 5% of Nightly on October 13. We observed surprisingly good
results in the first three weeks and decided to increase the experiment
percentage to 10% of Nightly on November 3. We continue to monitor the
results and the experiment data

is looking very good. One of the notable impressive ones is lower
checkerboarding severity with Fission enabled (read here

if you’re interested in finding out what does checkerboarding represent).


Other performance and memory probes are also showing Fission results within
the noise level when compared to the non-Fission measurements, which is
great!. Below are some examples of this.




Arriving at the Finish Line

We are very glad to report the completion of Frontend migration of all
framescripts to JSActors. Also, equally happy to report that printing of
out-of-process iframes is now working and complete. If you still see any
issues, please report them for the `Core::Printing:Output` component
blocking the meta printing-fission
 bug.

Fission Performance

Visual metrics performance dashboards have been added for Fission at
https://arewefastyet.com
 for
Linux64. Some of the sites are showing performance regressions for Fission
and we are looking into debugging and adding optimizations to improve those.

Session Storage Moved to the Parent Process

One of the major themes with Fission has been the move from content
processes to parent process. Continuing with that theme, Session Storage
has also been moved to the parent process in Bug 1654080
.

See your processes

Fission added a new about:processes page to show users more information
about the different processes Firefox uses and the corresponding origins
loaded in them. It groups the same sites from different tabs and frames
together for better readability and shows corresponding CPU and memory
usage. Double-clicking on any row representing a tab in about:processes
will take you to that tab. Also, the last column in about:processes allows
the user to kill a tab or a process by clicking on the ‘x’. Bug 1674084
 enabled
about:processes to ride the trains starting with Firefox 84.


Help Firefox get Fission-ready

You can help us test Fission on Firefox Nightly by enabling Fission in
about:preferences#experimental followed by restarting Firefox for it to
take effect.


For any follow-ups or comments or questions, you can find us at #fission in
Slack and Matrix/Element.

-The Fission Team.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Non-native theme turned on for Linux Nightlies

[Neha Kochar]

This is awesome! Thanks heycam, emilio, spohl and everyone else who’s
helped with this. It has been a lot of work to get it this far.

The Fission team is eagerly waiting for non-native theming. :)

-Neha.


On Sat, Jan 30, 2021 at 3:13 PM Emilio Cobos Álvarez 
wrote:

> (+firefox-dev for visibility, but please reply to dev-platform),
>
> Hey,
>
> Just a PSA that the themed form controls on Linux Nightly are going to
> change soonish (when bug 1689359[1] is merged to central).
>
> This is controlled by the widget.disable-native-theme-for-content pref.
> You can turn it on on other platforms if you want to test them too, the
> idea is that this will become the default for all platforms in the
> future, so testing and bug reports would be greatly appreciated!
>
> It should fix some compat issues (GTK has usually huge default form
> controls) and will pave the way to remove unconditional X11 connections
> from content processes, which is a requirement for Fission.
>
> The controls should be nicer / more consistent generally, but if you
> find something odd, or broken, please do reach out. You can file bugs
> against:
>
>   * Bug 1411425 [2] for Linux-specific stuff (only scrollbars are
> Linux-specific).
>
>   * Bug 1535761 [3] for OS-independent stuff.
>
> Feel free to ni? me for improved turnaround times :-)
>
> This is not just my work. Huge thanks to spohl, heycam and mstange, who
> did most of the work (my memory sucks, so sorry if I missed someone!).
>
> Huge thanks to all the people that tested this early and filed bugs too
> (gcp / Itiel / evilpies / julienw come to mind as I'm writing this, but
> I'm sure I'm missing lots of others!).
>
> Cheers,
>
>   -- Emilio
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1689359
> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1411425
> [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1535761
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads up: small Fission experiment starting in 88 Beta

[Neha Kochar]

Yes, barring any serious issues that the Fx88 Beta experiment uncovers, we
expect to run this through all of Fx88 beta cycle and then either keep at
the same %age for Fx89 or start a new experiment for Fx89 with higher %age
(maybe 50%?).

Thanks,
Neha.

On Fri, Mar 19, 2021 at 9:22 AM Jeff Muizelaar 
wrote:

> To confirm, this experiment will continue running in 88 late beta as well?
>
> -Jeff
>
> On Fri, Mar 19, 2021 at 1:00 AM Chris Peterson 
> wrote:
> >
> > The Fission team plans to start a small Fission experiment in 88 Beta,
> > which will likely run through 89 Beta. The experiment will be just 10%
> > (5% Fission + 5% control).
> >
> > I know 89 is the Proton MR1 release. I've confirmed with the Proton PMs
> > that they do not mind Fission running an experiment during 89 Beta, as
> > long as we are just continuing the same experiment we started in 88 Beta
> > and we keep the experiment at 10%.
> >
> > Our Fission Nightly experiment has been running for months without any
> > major stability or perf issues. We just increased our Fission Nightly
> > experiment to 100% (50% Fission + 50% control) during 88 Nightly.
> >
> > If you have questions or concerns, please email me or drop by the
> > #fission channel in Matrix or Slack.
> >
> > chris
> >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform