Move assignment and constructors for ns[C]String

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

Please use nsGlobalWindow{Inner,Outer}

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 nsGlobalWi

Re: Please use nsGlobalWindow{Inner,Outer}

changed yet. Thanks, Nika On Nov 10, 2017 11:41 AM, "Nika Layzell" 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

IPDL Changes: Refcounted Types

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

Using WebIDL objects in XPIDL

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 inte

Intent to implement: Async Clipboard API

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 `docum

Re: Intent to implement: Async Clipboard API

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

Re: XPIDL trajectory

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 measur

Stopgap for Commit Series in Phabricator

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

nsTArray types now supported in XPIDL

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+

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

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.

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

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

Starting mozilla-build from WSL

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 h

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

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

Fission Engineering Newsletter #1

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’

Re: PSA: New method for registering XPCOM components

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 XPCO

Incoming IPC Lifecycle Changes

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

Native actor refcounting support in IPDL

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 rec

Re: Native actor refcounting support in IPDL

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 t

Fission Newsletter #2

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

Re: Fission Newsletter #2

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 w

Re: Fission Newsletter #2

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

WebIDL Reviewers Group

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 stand

Fission Newsletter #3

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! W

Announcing Fission Dogfooding

tions 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

Re: Changing browser remoteness

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

Intent to unship: Large-Allocation header

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 t