Move assignment and constructors for ns[C]String

[Nika Layzell]

Hello everyone!

Bug 1377351 landed on central recently, and adds move assignment operators
and constructors to ns[C]String. These operators attempt to re-use
allocations when possible and can reduce the cost of copying strings around.

This could be used in some situations to improve assignment to nsString
fields in structs, for example, this call will avoid allocating & using
reference counts in more situations than the equivalent code using `const
nsAString&`:

void
SetFoo(nsAString&& aFoo)
{
  mFoo.Assign(Move(aFoo));
}

In addition, this can be used to save some work when returning using an
outparameter:

void
GetFoo(nsAString& aOut)
{
  // Somehow get a string value we want to return
  nsString returnValue = ...;
  aOut.Assign(Move(returnValue));
}

After using one of these move assignment operators, the original string
will be truncated. This functionality is also exposed to rust code through
the `take_from` method.

Consider moving ns[C]String values in the future when assigning to avoid
unnecessary work.

Nika
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please use nsGlobalWindow{Inner,Outer}

[Nika Layzell]

Bug 1416384 (https://bugzilla.mozilla.org/show_bug.cgi?id=1416384) has
landed on central now, and it completely removes nsGlobalWindow in favour
of the new nsGlobalWindow{Inner,Outer} classes.

There is still plenty of code cleanup to do, but the type split itself is
now complete. If you need help rebasing your patches after this change let
me know.

Use of the AsInner() and AsOuter() methods should now be unnecessary, as
nsPIDOMWindow{Inner,Outer} and mozIDOMWindow{,Proxy} are now proper base
classes and can be implicitly cast to. They remain in the code as most
callers have not been changed yet.

Thanks,
Nika

On Nov 10, 2017 11:41 AM, "Nika Layzell" <n...@thelayzells.com> wrote:

> Hey,
>
> Bug 1414974 (https://bugzilla.mozilla.org/show_bug.cgi?id=1414974) is in
> mozilla-central, and it introduces the nsGlobalWindowInner and
> nsGlobalWindowOuter types. These represent inner and outer nsGlobalWindow
> objects, and can be cast from the nsPIDOMWindowInner/Outer objects using
> nsGlobalWindowInner/Outer::Cast.
>
> Please avoid introducing new code which uses nsGlobalWindow directly,
> instead using the specific types, as it is going away soon™.
>
> Thanks!
> Nika
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Please use nsGlobalWindow{Inner,Outer}

[Nika Layzell]

Hey,

Bug 1414974 (https://bugzilla.mozilla.org/show_bug.cgi?id=1414974) is in
mozilla-central, and it introduces the nsGlobalWindowInner and
nsGlobalWindowOuter types. These represent inner and outer nsGlobalWindow
objects, and can be cast from the nsPIDOMWindowInner/Outer objects using
nsGlobalWindowInner/Outer::Cast.

Please avoid introducing new code which uses nsGlobalWindow directly,
instead using the specific types, as it is going away soon™.

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

Intent to implement: Async Clipboard API

[Nika Layzell]

In about a week, my intern will be starting. As an initial project, I
intend for her to implement the Async Clipboard API.

Summary: The Async Clipboard API provides a more modern and performant
interface to the user's clipboard. This API is intended to replace many
consumers of the existing `document.execCommand("copy"/"cut")`.

Example Usage:
  navigator.clipboard.writeText("text").then(...)

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1461465

Link to standard: https://w3c.github.io/clipboard-apis/#async-clipboard-api

Platform coverage: All

Estimated or target release: Firefox 63 (estimated)

Preference behind which this will be implemented:
'dom.events.asyncClipboard'
  The full `write`/`read` APIs will be exposed to the web behind an
additional
  preference of 'dom.events.asyncClipboard.dataTransfer', so we can ship
  the text APIs separately.

DevTools bug: N/A

Do other browser engines implement this?
  Chrome: Shipped (since version 66)
  Edge, Safari: Public Support (according to
https://www.chromestatus.com/features/5861289330999296)

web-platform-tests: A test for this API has already been created by the
chrome team (
https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/testing/web-platform/tests/clipboard-apis/async-navigator-clipboard-basics.https.html
)

Secure Contexts Only: Yes, this API will only be exposed to secure contexts.

Security & Privacy Concerns: This API exposes no new capabilities to the
web platform. Instead, it provides a more performant and ergonomic API to
replace most users of `execCommand("copy"/"cut")`. -- We do not intend to
expose the ability to read from the clipboard (the Clipboard.read and
Clipboard.readText APIs) to the web at this time. These APIs will only be
usable by extensions which have requested the appropriate permissions. --
Exposing `Clipboard.write` (the full DataTransfer API) to the web will also
occur behind a separate preference.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Async Clipboard API

[Nika Layzell]

Unfortunately, we can't get rid of the Gtk+/Clipboard hacks yet. There is
still a synchronous API for reading the clipboard
(document.execCommand("paste")) which is exposed to webextensions.

Beyond that, we'd need to read the clipboard asynchronously for ctrl-V
paste events. For now, I don't intend to get my intern to actually modify
the platform code to make it async, but rather to expose the new API to web
content.

On Tue, May 15, 2018 at 4:03 AM, Martin Stransky <stran...@redhat.com>
wrote:

> That would be really awesome to get rid of all Gtk+/Clipboard hacks we
> have there to transfer async clipboard on Linux to sync at Geckoso does
> it mean we can provide async clipboard only on toolkit/widget code level?
>
> ma.
>
>
> On 05/14/2018 11:05 PM, Nika Layzell wrote:
>
>> In about a week, my intern will be starting. As an initial project, I
>> intend for her to implement the Async Clipboard API.
>>
>> Summary: The Async Clipboard API provides a more modern and performant
>> interface to the user's clipboard. This API is intended to replace many
>> consumers of the existing `document.execCommand("copy"/"cut")`.
>>
>> Example Usage:
>>navigator.clipboard.writeText("text").then(...)
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1461465
>>
>> Link to standard: https://w3c.github.io/clipboar
>> d-apis/#async-clipboard-api
>>
>> Platform coverage: All
>>
>> Estimated or target release: Firefox 63 (estimated)
>>
>> Preference behind which this will be implemented:
>> 'dom.events.asyncClipboard'
>>The full `write`/`read` APIs will be exposed to the web behind an
>> additional
>>preference of 'dom.events.asyncClipboard.dataTransfer', so we can ship
>>the text APIs separately.
>>
>> DevTools bug: N/A
>>
>> Do other browser engines implement this?
>>Chrome: Shipped (since version 66)
>>Edge, Safari: Public Support (according to
>> https://www.chromestatus.com/features/5861289330999296)
>>
>> web-platform-tests: A test for this API has already been created by the
>> chrome team (
>> https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47b
>> e7a70d99753653d8eb5afc/testing/web-platform/tests/clipboard-apis/async-
>> navigator-clipboard-basics.https.html
>> )
>>
>> Secure Contexts Only: Yes, this API will only be exposed to secure
>> contexts.
>>
>> Security & Privacy Concerns: This API exposes no new capabilities to the
>> web platform. Instead, it provides a more performant and ergonomic API to
>> replace most users of `execCommand("copy"/"cut")`. -- We do not intend to
>> expose the ability to read from the clipboard (the Clipboard.read and
>> Clipboard.readText APIs) to the web at this time. These APIs will only be
>> usable by extensions which have requested the appropriate permissions. --
>> Exposing `Clipboard.write` (the full DataTransfer API) to the web will
>> also
>> occur behind a separate preference.
>> ___
>> 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

Re: XPIDL trajectory

[Nika Layzell]

Measuring the size of the xpt files is no longer as relevant. Since mccr8
and I rewrote xptinfo, they're only used during the build step, and are not
bundled. They're combined into a single .cpp file (xptdata.cpp) which
generates shared static pages (mostly) without relocations :-).

Perhaps measuring the size of xptdata.o could be more useful?

- Nika

On Tue, Jun 26, 2018, 12:31 AM Nicholas Nethercote 
wrote:

> Hi,
>
> After Firefox 57 removed support for legacy extensions, I decided to
> (roughly) track how much XPIDL code we have. Here are some measurements:
>
> Fri, Aug 4, 2017: m-i 372493:72873c109b1b
> .idl files: 1167
> .idl lines: 110240 total
> .xpt bytes: 417621 total
>
> Thu, Aug 17, 2017: m-i 375206:7a794cd2aee1
> .idl files: 1150
> .idl lines: 108854 total
> .xpt bytes: 412984 total
>
> Tue, Sep 26, 2017: m-i 382849:42a6a1c9c4cf
> .idl files: 1122
> .idl lines: 107963 total
> .xpt bytes: 411283 total
>
> Tue, Nov 14, 2017: m-i 391533:479f3105ad3b
> .idl files: 1087
> .idl lines: 106809 total
> .xpt bytes: 409510 total
>
> Thu, Feb 01, 2018: m-i 401956:8ebdf597ade8
> .idl files: 1027
> .idl lines: 103800 total
> .xpt bytes: 398695 total
>
> Tue, Jun 26, 2018: m-i 423583:4a20ed6e2fee
> .idl files: 905
> .idl lines: 97278 total
> .xpt bytes: 3717958 total
>
> The trend is clearly down, except for the large increase in .xpt size for
> the most recent measurement -- note the extra digit! It appears that .xpt
> files used to be binary, and now they are JSON. This might be related to
> mccr8's recent XPT overhaul (bug 1438688)?
>
> The script I use for this is below, for those who are interested.
>
> Nick
>
>
> #! /bin/sh
> #
> # Measures various XPIDL things in ./ and o64/. (It assumes o64/ is the
> # objdir.) I put the results in ~/moz/txt/xpidl.txt.
>
> if [ ! -d o64 ] ; then
> echo "o64/ doesn't exist"
> return 1
> fi
>
> # Count number of .idl files, excluding ones in objdirs, testing ones, and
> # mortar ones.
> echo -n ".idl files: "
> find . -name '*.idl' | \
> grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | \
> wc --lines
>
> # Count number of lines in those .idl files.
> echo -n ".idl lines: "
> find . -name '*.idl' | \
> grep -v "64[a-z]*\/dist" | grep -v "testing\/" | grep -v "mortar\/" | \
> xargs wc --lines | tail -1
>
> # Count number of bytes in .xpt files.
> cd o64
> echo -n ".xpt bytes: "
> find . -name '*.xpt' | xargs wc --bytes | tail -1
> cd ..
> ___
> 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

nsTArray types now supported in XPIDL

[Nika Layzell]

As of bug 1474369 (https://bugzilla.mozilla.org/show_bug.cgi?id=1474369),
xpidl files now support `Array` in type position. These types are
reflected into C++ as '[const] nsTArray&' and into JS as native JS Array
objects.

Array has a few changes compared to [array, size_is(...)]:
 1. Exposed to C++ as `nsTArray` rather than a raw pointer
 2. Supports complex data types:
 a) AString and DOMString as nsString
 b) ACString and AUTF8String as nsCString
 c) jsval as JS::Value (caller-rooted)
 d) nested Array as nsTArray
 3. Stores 'interface' and 'webidl' types in RefPtr

Do note, that unlike [array], Array does not currently support raw
pointer types (e.g. 'string', 'wstring', and 'nsIDPtr'). Adding support for
passing Array is on the roadmap, but I'm not working on it at the
moment.

Please use Array instead of [array] for future xpidl interfaces, and
look into converting existing interfaces to the new type. I'd like to
eliminate [size_is(..)] strings and [array] in the near future to reduce
XPConnect complexity and improve ergonomics.

- nika
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Stopgap for Commit Series in Phabricator

[Nika Layzell]

While our services team is working on making a reliable & maintained tool
for handling commit series with Phabricator, I threw together something
small to use as a stop-gap for pushing large commit series to Phabricator
and updating them.

It currently works as a wrapper around Arcanist, and *only supports git*
(as I don't know how hg works enough to get it to work reliably), but
should allow pushing a range of commits as revisions without touching the
working tree, automatic dependency relationships, bug number filling, and
reviewer field population.

I called it 'phlay' (splinter => flay; flay + phabricator => phlay).

GitHub: https://github.com/mystor/phlay
Tweet w/ short demo clip:
https://twitter.com/kneecaw/status/1021434807325163523

I've used it to push pretty-much all of my recent patch series to
Phabricator, and it's saved me a good amount of time, so I figured I'd let
people know. Feel free to poke me on IRC if you have questions.

- nika
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Phlay (Git/Phabricator Commit Series tool) - Now without a PHP/Arcanist Dependency~

[Nika Layzell]

Previously I sent an email to this list (
https://groups.google.com/forum/#!topic/mozilla.dev.platform/o9f2S0vO47k)
about my |phlay| tool for pushing commit series to phabricator without
touching the working directory. (https://github.com/mystor/phlay)

I've since rewritten it to avoid the PHP and arcanist dependencies, and it
no longer modifies your commit messages beyond adding the revision link.
Instead, phlay directly talks to conduit APIs. It still has a dependency on
|git|, although |hg| users can use the official moz-phab tool.

Please let me know if you decide to use phlay and run into issues with it!

- nika

P.S. If you still want to use the older version of phlay, it is on the
|legacy| branch (https://github.com/mystor/phlay/tree/legacy)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: cbindgen will be required to build in the near future.

[Nika Layzell]

That would be nice to do :-) - moving these larger generic build-time
dependencies to being downloaded with bootstrap could really help improve
build times!

That being said, IIRC there is some interest in building pre-export/export
build capability for other more-mozilla-specific/unstable tooling.

On Fri, Aug 17, 2018, 5:53 AM Xidorn Quan  wrote:

> On Fri, Aug 17, 2018, at 10:19 PM, Emilio Cobos Álvarez wrote:
> > Adding support for general crates.io crates to be built this way and
> > appear somewhere on the objdir seemed way more build system hackery than
> > what I could do in a reasonable timeframe with my limited knowledge of
> > the build system. So requiring the binary to be there was the easiest
> > way I got it to work.
> >
> > That being said, if some build system peer is able to make something
> > like that work, it'd be easy to switch to it if wanted.
>
> No, don't do that. Running stuff before export is blocking almost
> everything in the build process, and building anything nontrivial there
> would simply make the build slower with no parallelism at all.
>
> I'm actually thinking about pulling bindgen out from build-dependency and
> make it use binary as well. bindgen was made a build-dependency and build
> in the process because at that time, bindgen wasn't stable enough, and we
> usually need to fix it for stylo to work. But these days we no longer do
> that a lot, so it should be fine to just use prebuilt binary.
>
> - Xidorn
> ___
> 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

IPDL Changes: Refcounted Types

[Nika Layzell]

Earlier this week, bug 1443954
 landed, which
improved support in IPDL for reference counted types, making it safer and
more ergonomic to directly use reference counted types (such as nsIURI,
nsIPrincipal, nsIInputStream, etc.) in IPDL protocols.

To declare a dependency on a refcounted type in IPDL, use the `using
refcounted` statement, for example:

PContent.ipdl:

using refcounted class nsIInputStream from "mozilla/ipc/IPCStreamUtils.h";

The type can then be referenced by their name. These types are passed by
raw pointer when used as an input, and passed by reference-to-RefPtr when
used as an output.

To implement ParamTraits (or IPDLParamTraits
)
for a refcounted type, specialize on the bare type:

PermissionMessageUtils.h:

template<>
struct ParamTraits
{
  static void Write(Message* aMsg, nsIPrincipal* aParam);
  static bool Read(const Message* aMsg, PickleIterator* aIter,
RefPtr* aResult);
};

These types may also be used within IPDL unions and IPDL structs. Please
prefer using these refcounted types directly over wrapper types like
`IPC::Principal` when possible.

- Nika
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Using WebIDL objects in XPIDL

[Nika Layzell]

Yesterday, bug 1444991
 landed on inbound,
which adds support for using WebIDL defined objects directly inside of
XPIDL definition files.

This allows us to avoid using nsISupports to pass WebIDL objects which
don't have corresponding XPIDL interfaces through XPIDL defined methods.

WebIDL objects must be forward declared, like XPIDL types, in the .idl file
which uses them:

  // C++ 'nsFrameLoader', from FrameLoader.webidl
  webidl FrameLoader;

  // C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
  webidl DataTransfer;

These types may then be used like XPIDL types in method and attribute
declarations. These types can be used from both C++ and JS code. They are
exposed into Rust as '*const ::libc::c_void`.

- NIka
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Starting mozilla-build from WSL

[Nika Layzell]

This is a quick and dirty script I threw together which allows you to start
a mozilla-build shell from within WSL. which allows me to do windows builds
from a WSL bash ssh prompt on a remote windows machine.
https://github.com/mystor/mbuild

I'm mostly using this for my own stuff, and I certainly haven't tested it
heavily, but Jeff suggested I should post it here in case anyone else finds
it useful.

- Nika
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: searchfox now indexing Windows Rust/C++ code

[Nika Layzell]

This is fantastic - thanks!

On Mon, Nov 5, 2018 at 11:40 AM Aaron Klotz  wrote:

> \o/ \o/ \o/ \o/ \o/
>
> THANK YOU!
>
> On 11/2/2018 9:32 AM, Kartikaya Gupta wrote:
> > Hello searchfox fans,
> >
> > Those of you working in Windows-only Rust and C++ code will probably
> > be happy to hear that as of today searchfox is indexing the
> > Windows-only bits of our codebase as well.
> >
> > The same caveat as with macOS applies - in cases where there is
> > generated source that conflicts with Linux, the Linux version is used.
> > I hope to do something better about that in the not-too-distant
> > future. Android-only code is still not yet indexed; it will be added
> > as time permits.
> >
> > Happy Friday!
> > ___
> > 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

Re: PSA: New method for registering XPCOM components

[Nika Layzell]

Thanks so much for doing this! Having static XPCOM component manifests will
be awesome both for Fission memory usage, and just general usability of our
codebase into the future.

On Tue, Feb 5, 2019 at 4:12 PM Kris Maglione  wrote:

> As of bug 1478124, the new preferred method for registering XPCOM
> components
> is via static manifest files, as documented here:
>
>
> https://firefox-source-docs.mozilla.org/build/buildsystem/defining-xpcom-components.html
>
> And, as of bug 1524688, it will be the preferred method of defining
> JavaScript components as well as native ones.
>
> The primary motivation for this change is to decrease the amount of memory
> (and, to a lesser extent, startup performance) overhead that component
> registrations consume in content processes, which would not have been
> acceptable in the post-Fission world. It has the side-benefit, though, of
> making most registrations much more straightforward, requiring only a
> single
> entry, in a single place, for each component.
>
>
> Thank you to all of the reviewers who had to review a lot of very large
> patches to make this possible, particularly Nathan Froyd, Eric Rahm, and
> Mike Conley, on whom I dumped most of the biggest chunks.
> ___
> 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

Fission Engineering Newsletter #1

[Nika Layzell]

 networking logic into a
   socket process. (Bug 1322426
   <https://bugzilla.mozilla.org/show_bug.cgi?id=1322426>)
   - …and so much more!

If you want an up-to-date view of Milestone 1, you can see the current
Milestone 1 status
<https://bugzilla.mozilla.org/buglist.cgi?classification=Client%20Software=Developer%20Infrastructure=Components=Server%20Software=Other=cf_fission_milestone_id=14538804=equals_format=advanced=M1_based_on==product%2Ccomponent%2Cassigned_to%2Cshort_desc%2Cbug_status%2Cresolution%2Cstatus_whiteboard>
on Bugzilla.

If have a bug which may be relevant to fission, *please* let us know by
setting
the “Fission Milestone” project flag to ‘?’. We’ll swing by and triage it
into
the correct milestone.

[image: Setting Fission Milestone Project Flag]

If you have any questions, feel free to reach out to one of us, and we’ll
get
you answers, or guide you to someone who can:

   - Ron Manning  (Fission Engineering Project
   Manager)
   - Nika Layzell  (Fission Tech Lead)
   - Neha Kochar  (DOM Fission Engineering Manager)

What’s Changing?

In order to make each component of Firefox successfully adapt to a
post-Fission
world, many of them are going to need changes of varying scale. Covering
all of
the changes which we’re going to need would be impossible within a single
newsletter. Instead, I will focus on the changes to actors, messageManagers,
and document hierarchies.

Today, Firefox has process separation between the UI - run in the
*parentprocess*, and web content - run in *content processes*.
Communication between
these two trees of “Browsing Contexts” is done using the TabParent and
TabChild actors in C++ code, and Message Managers in JS code. These systems
communicate directly between the “embedder”, which in this case is the
 element, and the root of the embedded tree, which in this case
would be the toplevel DocShell in the tab.

However, in a post-Fission world, this layer for communication is no longer
sufficient. It will be possible for multiple processes to render distinct
subframes, meaning that each tab has multiple connected processes.

Components will need to adapt their IPC code to work in this new world,
both by
updating their use of existing APIs, and by adapting to use new Actors and
APIs
which are being added as part of the Fission project.
Per-Window Global Actors

For many components, the full tree of Browsing Contexts is not important,
rather communication is needed between the parent process and any specific
document. For these cases, a new actor has been added which is exposed both
in
C++ code and JS code called [PWindowGlobal].

Unlike other actors in gecko, such as Tab{Parent,Child}, this actor exists
for all window globals, including those loaded within the parent process.
This
is handled using a new PInProcess manager actor, which supports sending main
thread to main thread IPDL messages.

JS code running within a FrameScript may not be able to inspect every frame
at
once, and won’t be able to handle events from out of process iframes.
Instead,
it will need to use our new [JS Window Actor] APIs, which we are targeting
to
land in Milestone 1. These actors are “managed” by the WindowGlobal actors,
and are implemented as JS classes instantiated when requested for any
particular window. They support sending async messages, and will be present
for
both in-process and out-of-process windows.

C++ logic which walks the frame tree from the TabChild may stop working.
Instead, C++ code may choose to use the PWindowGlobal actor to send
messages in
a manner similar to JS code.
BrowsingContext objects

C++ code may also maintain shared state on the BrowsingContext object. We
are
targeting landing the field syncing infrastructure in Milestone 1, and it
will
provide a place to store data which should be readable by all processes
with a
view of the structure.

The parent process holds a special subclass of the BrowsingContext object:
CanonicalBrowsingContext. This object has extra fields which can be used in
the parent to keep track of the current status of all frames in one place.
TabParent, TabChild and IFrames

The Tab{Parent,Child} actors will continue to exist, and will always bridge
from the parent process to a content process. However, in addition to these
actors being present for toplevel documents, they will also be present for
out-of-process subtrees.

As an example, consider the following tree of nested browsing contexts:

 +-- 1 --+
 | a.com |
 +---+
  / \
+-- 2 --+ +-- 4 --+
| a.com | | b.com |
+---+ +---+
| |
+-- 3 --+ +-- 5 --+
| b.com | | b.com |
+---+ +---+

Under e10s, we have a single Tab{Parent,Child} pair for the entire tab,
which
would connect to 1, and FrameScripts would run with content being the 1‘s
global.

After Fission, there will still be a Tab{Parent,Child} actor for the root of
the tree, at 1. However, there will also be two additional Tab{Paren

Incoming IPC Lifecycle Changes

[Nika Layzell]

Now that central is on Fx69, I will be landing a series of patches making
changes to IPC actor lifecycles which aim to make actors more predictable &
easier to work with.

Here's a short summary of the changes coming down the pipe:

   1.
*mIPCOpen is no longer necessary (bug 1540731
   ) *Actors now
   directly provide two methods: *CanSend()* and *CanRecv()*, which can be
   used to check whether the actor is able to send/receive messages. Most uses
   of a manual *mIPCOpen* member should no longer be necessary, and can be
   replaced.
   Currently, these methods usually return the same value, but future IPC
   features for async actor destruction may allow them to diverge.
   2. *Messages sent to dead actors are discarded (bug 1547085
   )*
   Previously, if a message was sent over a managed actor which itself was
   sending a *__delete__* message in the other direction, a crash would
   occur, due to the message's target actor being dead when the message is
   delivered. This will no longer cause a crash, and instead the message will
   be discarded, and a warning will be logged in DEBUG mode. This brings the
   behaviour more in line with toplevel actors, which may discard messages
   during shutdown.
   3. *Calling Send*() on a !CanSend() actor no longer crashes (bug 1548717
   )*
   The send method will now return a `false` value to indicate failure, and
   the message will not be sent.
   4.
*"Well Behaved" actors will be kept alive during Recv* callbacks (bug
   1540731 ) *A "Well
   Behaved" actor here is one which allows IPC to control its lifecycle by not
   being destroyed before the corresponding *Dealloc* method is called.
   This should include most actors, although there are some poorly behaved
   actors which will need to be modified in follow-up bugs. In general, if
   there's no way your actor's allocation will be freed before
   *DeallocPMyActor* is called on its manager, it is a "Well Behaved" actor.
   If a *Recv** callback is on the stack, IPC will delay calling
   *DeallocPMyActor* until after that method has returned. In addition, IPC
   will attempt to keep an actor's *Manager()* alive using the same
   mechanism until after the actor itself no longer has any references from
   within IPC.
   Unfortunately, the *Manager()* method may still return a dangling
   pointer after IPC no longer holds a reference to it, although I hope to
   improve this situation in the future.
   5. *ParamTraits<> specializations for refcounted types have been
   simplified (bug 1547218
   )*

We plan to continue to improve IPC, adding ergonomics features such as a
special *refcounted* attribute for protocols, which will allow IPDL to
implement "Well Behaved" lifecycle management correctly and automatically.
Feel free to reach out if you encounter additional pain-points with IPDL or
IPC in general. Not all problems necessarily have (simple) solutions, but
it's always good to keep them in mind!

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

Native actor refcounting support in IPDL

[Nika Layzell]

Bug 1550560 (https://bugzilla.mozilla.org/show_bug.cgi?id=1550560) landed
recently, adding native support for declaring actors as *refcounted*. This
change improves the ergonomics for declaring and using IPDL actors, and
opens avenues for future improvements to the IPC core. *refcounted* is the
recommended way to define the lifecycle for an actor, and may become the
default in the future. The syntax currently looks as-follows:

async *refcounted* protocol PBrowserBridge {
https://searchfox.org/mozilla-central/rev/b38e3beb658b80e1ed03e0fdf64d225bd4a40327/dom/ipc/PBrowserBridge.ipdl#33

Adding this attribute has the following impacts:

   1. Generated actor classes have pure-virtual *AddRef* and *Release*
   methods to be overridden by the implementation.
   2. *AllocPFoo* methods return *already_AddRefed* instead of *PFoo**
   .
   3. No *DeallocPFoo* methods will be generated or called on the manager
   class.
   4. IPDL will automatically obtain a single reference to the actor when
   its underlying connection is established, and will release it when the
   actor is no longer in use by IPC.
   5. The "helper constructor" is no longer generated, so *AllocPFoo*
   methods on the constructor sender side, which are often implemented as
   *MOZ_ASSERT_UNREACHABLE()*, may be removed. This may require consumers
   of the helper constructor to slightly modify their code.

I have converted 16 actors to use this new annotation in bug 1570369 (
https://bugzilla.mozilla.org/show_bug.cgi?id=1570369). Patches on this bug,
such as https://phabricator.services.mozilla.com/D40263, can be used as a
reference when converting your actor.

Please reach out to me (:nika) on IRC or Slack if you have questions or
encounter bugs when converting your actor.

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

Re: Native actor refcounting support in IPDL

[Nika Layzell]

On Thu, Aug 1, 2019 at 3:45 PM Boris Zbarsky  wrote:

> On 8/1/19 3:11 PM, Nika Layzell wrote:
> > Bug 1550560 (https://bugzilla.mozilla.org/show_bug.cgi?id=1550560)
> landed
> > recently, adding native support for declaring actors as *refcounted*.
>
> Would that allow us to add MOZ_CAN_RUN_SCRIPT bits to the generated code
> for those cases?
>

Yep, that should be possible. IPC still works with raw pointers internally
in many cases, and doesn't directly hold a RefPtr on the stack, so
it'll probably need to be a MOZ_CAN_RUN_SCRIPT_BOUNDARY.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fission Newsletter #2

[Nika Layzell]

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://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=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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fission Newsletter #2

[Nika Layzell]

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
> <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=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.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fission Newsletter #2

[Nika Layzell]

On Fri, Aug 9, 2019 at 1:55 PM Alexis Beingessner 
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.


>
> 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
>> > <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 a

WebIDL Reviewers Group

[Nika Layzell]

As of yesterday, a phabricator reviewers group for WebIDL has been created.
If your patch needs review for WebIDL changes, you can tag this group using
'*r=#webidl*'.

Once specific DOM peer(s) are working with you on a web standard, you
should continue to reach out to them for reviews as the standard evolves.

We're testing this out, and hope this will more evenly spread review load
and make it easier to find a peer :-)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fission Newsletter #3

[Nika Layzell]

Hey All!

Over the last two months, we've made some excellent progress towards
improving the stability and feature support of Fission-enabled Firefox!

Are We Fission Yet?

The team has been hard at work, pushing down the number of failing Fission
Mochitests dramatically over the past few months! We've managed to get the
current count down to 324 total skipped and failing tests. Fission
Mochitests are now running on tier1 and need your help to get them all to a
passing state. Huge thanks to the M-fis team, and everyone who has worked
with us to help make this happen!

Thanks to the amazing work of :bgrins, :ahal, :gbrown and :kmag, we now
have a site for visualizing our current progress on Fission mochitests (and
hopefully more in the future)! In classic Mozillian fashion, you can find
it at https://arewefissionyet.com/! :kmag also maintains a canonical list
†
of failing tests, who's working on them, and their current status, if
you're looking to pick up some work and get involved!

†: mozilla-internal document, public read-only mirror

also available.


We have had tremendous progress during the ongoing M4 milestone with over
145 fixed bugs
.
We would like to thank everyone who’s helped us get this far.

The Omniscient Browser Toolbox

The Devtools team has made excellent strides updating the toolbox to add
out-of-process frame support! As part of this effort, a super-experimental
updated Omniscient Toolbox has been created which allows for the Inspector,
Console and Debugger tabs to be used to debug not just the parent process,
but content processes too!


Support for debugging out-of-process Fission content frames is also being
added, meaning that this could soon become an amazing and important piece
of the browser developer's toolbox! To try this, one can enable “omniscient
browser toolbox” in browser toolbox settings panel and restart the toolbox.
Huge thanks to the whole team.

(Previously Newsletter #1
,
Newsletter #2

)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing browser remoteness

[Nika Layzell]

Replied with comments inline :-)

On Tue, Oct 6, 2020 at 11:15 PM Geoff Lankow  wrote:

> I've borrowed this code from Firefox
> <
> https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser.js#1832-1851>
>
> and that works perfectly (well, after I fix a few other things that
> aren't relevant here). I can put that in a wrapper function to decide
> which remote type to use, do the switch if necessary, and load the page.
> If I switch to a non-remote browser then load a message, that works too.
>

The code path you ended up copying from tabbrowser is one of our older
codepaths, which we are still keeping around for portability, but we may be
removing it in the future. The C++ async API you're trying to use is the
more modern one, and should generally be used instead. Unlike the JS
`changeRemoteness` API, it is async and doesn't block the parent process
while waiting for a new content process to spawn.

It will be fine for now, but these APIs are unfortunately in a decent
amount of flux with the active work on Fission, so don't be too surprised
if they end up changing a bit.


> This works, the browser changes remoteness. Now I need a docShell for
> the next piece of the process, and this is where I'm stuck.
>
> I'm not sure I've got the arguments to ChangeRemoteness right. I made up
> the second as a non-zero value is required, I think I understand the
> third but browsingContext is discarded regardless, and I don't know
> anything about the fourth.
>

In general, the ChangeRemoteness method is intended to be used by
DocumentLoadListener, which will trigger a process switch in response to a
navigation. This is the most common form of process switching in Firefox,
so it's generally what the API is designed around. I unfortunately don't
know a ton about how Thunderbird works internally, so I don't know whether
loading a message occurs as a document navigation, but I'm going to
continue assuming it doesn't and you need to do this manually. (if you can
get away with using the same codepath as Firefox by doing a navigation,
your life might be easier, though)

The reason why you're seeing a discarded BrowsingContext is because the
third argument (aReplaceBrowsingContext) only forces that the BC is
replaced, and can't guarantee it isn't. For certain loads we always replace
the BrowsingContext even if that parameter is false. Those cases are
enumerated here:
https://searchfox.org/mozilla-central/rev/165e8d8f80c02605c2f3e89c5de462abfce91c32/dom/base/nsFrameLoaderOwner.cpp#60-85.
Specifically, we always replace the BrowsingContext when switching from a
content process to the parent process (as content should ideally never have
a reference to a document loaded in the parent process), as well as if the
`fission.preserve_browsing_contexts` pref is `false`, though we're likely
going to remove that pref in the near future.

Fortunately, as you're in the parent process, you don't need to worry about
the BrowsingContext not being preserved too much. You can get the new
BrowsingContext after the remoteness change in one of two ways:

  // The browser frame element will be the same, so you can fetch the new
BrowsingContext directly from it.
  RefPtr flo = do_QueryObject(el);
  RefPtr browsingContext = flo->GetBrowsingContext();

  // The BrowserID of the new BrowsingContext will be the same, so you can
look it up by the same BrowserId.
  RefPtr browsingContext =
BrowsingContext::GetCurrentTopByBrowserId(browserId);

>From this new BrowsingContext, you can then fetch the nsDocShell with the
`BrowsingContext::GetDocShell()` method.

   RefPtr frame =
>mozilla::dom::XULFrameElement::FromNodeOrNull(el);
>
>uint64_t browserId = frame->BrowserId();
>RefPtr browsingContext =
>CanonicalBrowsingContext::Cast(
>BrowsingContext::GetCurrentTopByBrowserId(browserId));
>

FWIW, you can do this a bit more simply by fetching the BC from the
nsFrameLoaderOwner (leaving out null checks etc.):

  RefPtr el = ...;
  RefPtr flo = do_QueryObject(el);
  RefPtr bc =
flo->GetBrowsingContext()->Canonical();

   browsingContext->ChangeRemoteness(NOT_REMOTE_TYPE, 1, false, 0)
>

You ideally don't want to pass `1` as the pending load ID. This ID is a
number which is used by `DocumentLoadListener` to pair up existing channels
with the nsDocShell in the new process after a process switch has
completed, so passing a dummy value can potentially cause you issues down
the line.

For print preview, we're passing in a `0` value as "this isn't due to an
in-progress load" (
https://searchfox.org/mozilla-central/rev/165e8d8f80c02605c2f3e89c5de462abfce91c32/dom/ipc/ContentParent.cpp#3641),
which is probably what you want to do here as well. Unfortunately, we
explicitly check that it's non-zero for toplevel loads, as we currently
have no uses for this type of process switch in Firefox (

Announcing Fission Dogfooding

[Nika Layzell]

*TL;DR* We're looking for brave individuals to enable "Fission", Mozilla's
site-isolation project, to help us test this new browser architecture!

Since the project started, we've been hard at work improving Firefox's core
architecture, making it possible for us to isolate and run each site within
its own process. This work has required us to change the way we load
documents, how the browser UI interacts with web content, update and
improve our tests, and much more.

We've finished many of these changes, and are now at the point where we're
looking for volunteers to test Fission, helping us find bugs, and improve
stability. There's still lots left for Fission, but we can't find and fix
everything without your help!

For the most up-to-date, information on the state of Fission, check the
wiki at https://wiki.mozilla.org/Project_Fission. We'll do our best to keep
it up to date as Fission improves.

*Enabling Fission*
wiki: https://wiki.mozilla.org/Project_Fission#Enabling_Fission
Fission is still in development, so it can only be enabled in Firefox
Nightly <https://mozilla.org/firefox/nightly/>. To enable it, change the
'fission.autostart' pref in about:config to 'true', and restart the
browser. It isn't necessary to change any other fission preferences.

You can confirm that fission has been enabled in your browser by loading a
website, and hovering over the active tab. If the tooltip contains a `[F
]`, it means Fission is enabled.
[image: fission_tab_tooltip.png]

If you encounter an issue while using Fission, it is possible to open a
non-fission window within the same browsing session using the "New
Non-Fission Window" item in the hamburger menu. This can be useful to
determine if issues are Fission-specific, or to work around
fission-specific breakage.
[image: new_non_fission_window3.png]


*Known Issues*
wiki: https://wiki.mozilla.org/Project_Fission#Known_Issues
We're keeping a list of known issues on the Project Fission wiki page, and
will try to keep it up to date as we discover and fix new issues.

*Reporting Bugs*
If you encounter issues while using Fission, please file bugs on bugzilla
<https://bugzilla.mozilla.org>, including "Fission" in the bug summary.
We'll catch them during our regular triage, and fix them as soon as
possible!

*What's Next?*
We've got a lot planned for Fission in the coming months, including
fleshing out the remaining unimplemented features, and continual resource
usage and stability improvements.

Before we put our heads down & get back to work, I want to give *massive*
congratulations to the entire Fission team, and everyone who has helped
contribute to us reaching this milestone. We couldn't have done it without
your hard work.

*Thank you for testing Fission!*
- Nika Layzell
[image: bitmap2.png]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Large-Allocation header

[Nika Layzell]

We intend to unship the Large-Allocation header. It was never implemented
by other browsers, nor was it standardized. It was primarily useful to get
a document in a new process on 32-bit systems so it would have sufficient
memory for certain WebAssembly or asm.js applications.


A partner we know to have used the header has indicated they no longer rely
on it.


Websites can adopt the Cross-Origin-Opener-Policy and
Cross-Origin-Embedder-Policy headers to achieve much the same effect
through the cross-origin isolated primitive.


Bug to remove: https://bugzilla.mozilla.org/show_bug.cgi?id=1598759
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform