PSA: Please clear weak reference to cycle collected objects on unlink

Accessing an object after it has been unlinked by the cycle collector is a certain way to cause trouble. Usually, that trouble is just in the form of null pointer crashes, but it can potentially be much worse. And the most common cause of those types of issues comes from accessing a weak

Intent to Unship: in content

in non-chrome documents has been unsupported in production environments for some time. Maintaining support for it in content processes has become increasingly difficult in the light of Fission, to the point that we've decided it is time to fully remove support. Since support is disabled by

Re: How best to do async functions and XPCOM?

On Thu, Dec 12, 2019 at 09:30:06AM -0500, Boris Zbarsky wrote: On 12/10/19 3:31 PM, Kris Maglione wrote: In what way is dom::Promise annoying to use from C++? The one thing I know about that's pretty annoying is if you receive the promise from someone else and want to add reactions

Re: How best to do async functions and XPCOM?

On Sun, Dec 08, 2019 at 11:40:52PM -0500, Joshua Cranmer  wrote: The problem with MozPromise is that it doesn't integrate well if you use XPIDL interfaces, so you have this annoying issue that if you want to use XPIDL integration, you have to use mozilla::dom::Promise, which is annoying to

Re: How best to do async functions and XPCOM?

On Fri, Dec 06, 2019 at 11:20:12AM +1300, Geoff Lankow wrote: Hi all I'm redesigning a bunch of Thunderbird things to be asynchronous. I'd like to use Promises but a lot of the time I'll be far from a JS context so that doesn't really seem like an option. The best alternative I've come up

Re: Consider avoiding allSettled in tests (was: Re: Intent to ship: Promise.allSettled)

On Thu, Oct 31, 2019, 06:02 Jason Orendorff wrote: > Ignoring the awaited value here is like using `catch {}` to squelch all > exceptions, or ignoring the return value of an async function or method, or > any other expression that produces a Promise. Do we have lints for those > pitfalls? I'm

Fission Mochitests moving to tier 1 and must all† pass by October 31st

Fission Milestone 4 is focused on getting all mochitests running and passing with Fission enabled. The deadline for the end of this milestone is October 31st, approximately one month from today, and we still have a significant amount of work to do, with about 350 mochitests skipped and about

Re: Intent to remove: Fennec

, again, that would just not be a good use of resources. -- Kris Maglione UNIX is simple. It just takes a genius to understand its simplicity. --Dennis Ritchie ___ dev-platform mailing list dev-platform@lists.mozilla.org https

Re: Nika Layzell and Kris Maglione are now XPCOM peers

On Wed, Sep 4, 2019, 11:33 Nathan Froyd Kris noticed that Nika was going to become an XPCOM peer and, not > wanting to be left out, volunteered (yes, really). Kris has worked on > modernizing the component manager and various thread-related > improvements. > To be clear, I volunteered because

Re: Must we rebuild all our rust code constantly?

On Tue, Aug 20, 2019 at 02:23:06PM +0900, ISHIKAWA,chiaki wrote: On 2019/08/20 9:11, Dave Townsend wrote: Thanks to a tip I've tracked this down. This seems to only be the case when I have sccache enabled. Disabling it gives me nice quick incremental builds again. Of course that isn't an ideal

Re: Must we rebuild all our rust code constantly?

This is apparently a known bug that no-one seems to be able to track down the cause of. It suddenly started happening to me one night for every build, even if I changed nothing. Then, just as suddenly, stopped happening after a couple of hours. On Mon, Aug 19, 2019 at 05:11:19PM -0700, Dave

Re: PSA: mozilla::Result is about to understand move semantics

Kris Maglione wrote: On Mon, Aug 12, 2019 at 10:14:19PM -0700, Bryce Seager van Dyk wrote: >>But either way, that's going to result in a copy when the >>Result is constructed (unless the compiler is really clever). > >Is it the data being moved into the Result which is incurr

Re: PSA: mozilla::Result is about to understand move semantics

On Mon, Aug 12, 2019 at 10:14:19PM -0700, Bryce Seager van Dyk wrote: But either way, that's going to result in a copy when the Result is constructed (unless the compiler is really clever). Is it the data being moved into the Result which is incurring the copy here, or the actual Result

Re: PSA: mozilla::Result is about to understand move semantics

On Mon, Aug 12, 2019 at 11:16:17PM +0200, Emilio Cobos Álvarez wrote: On 8/12/19 10:38 PM, Bryce Seager van Dyk wrote: On Monday, August 12, 2019 at 8:41:26 AM UTC-7, Emilio Cobos Álvarez wrote: Neat! Thanks for doing this. It should allow for broader use of Result in media code. Are there

Re: Fission Newsletter #2

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 `skip-if = fission`. mozinfo expression matching should be case

Re: Non-header-only headers shared between SpiderMonkey and the rest of Gecko

On Tue, Aug 06, 2019 at 10:56:55AM +0300, Henri Sivonen wrote: Do we have some #ifdef for excluding parts of mfbt/ when mfbt/ is being used in a non-SpiderMonkey/Gecko context? #ifdef MOZ_HAS_MOZGLUE ___ dev-platform mailing list

Re: Native actor refcounting support in IPDL

\o/ This is going to get rid of so much (often buggy, potentially leaky, and slightly varying) boilerplate from most of our IPC code. Thanks! On Thu, Aug 01, 2019 at 03:11:00PM -0400, Nika Layzell wrote: Bug 1550560 (https://bugzilla.mozilla.org/show_bug.cgi?id=1550560) landed recently,

PSA: Fission mochitests will soon run on integration branches

Within the next few days, mochitests will run with Fission enabled (in the M-fis job) on every check-in. The tests will run as Tier 2, so new failures will not cause immediate backout, but will still need to be fixed. In order to get tests running as soon as possible, so that we can spot new

Re: Resolving URLs in c++

On Thu, Jul 11, 2019 at 10:57:05PM -0700, mcace...@mozilla.com wrote: Was looking at how WebKit implements the WebShare API, and they have this nice method `completeURL(str)` [1] that resolved URLs relative to, I guess, the `Document` object (or whatever context is). So they can basically do

Re: Running C++ early in shutdown without an observer

On Fri, Jun 07, 2019 at 11:40:05AM -0700, Chris Peterson wrote: Note that on Android, you may never get an opportunity for a clean shutdown because the OS can kill your app at any time. I don't know what is the recommendation for shutdown activities on Android. The GeckoView team has had some

Re: Running C++ early in shutdown without an observer

On Fri, Jun 07, 2019 at 09:18:38AM +0300, Henri Sivonen wrote: For late shutdown cleanup, we have nsLayoutStatics::Shutdown(). Do we have a similar method for running things as soon as we've decided that the application is going to shut down? (I know there are observer topics, but I'm trying to

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Wed, May 15, 2019 at 07:02:58PM -0400, Botond Ballo wrote: On Wed, May 15, 2019 at 6:54 PM Jean-Yves Avenard wrote: It is then up to each process to handle preference modifications and pass that change. There's no automatic or universal method on how this is done unfortunately. Will

Re: nsresult code lookup via IRC (mrgiggles bot)

ling list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation It is the mark of an educated mind to be able to entertain a thought without accepting it. --Aristotle

Re: Searchfox now indexing m-beta, m-release, m-esr60

/listinfo/dev-platform -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation For every complex problem there is an answer that is clear, simple, and wrong. --H. L. Mencken ___ dev-platform mailing list dev-platform

Re: What is dom/browser-element/ used for?

On Thu, Feb 28, 2019 at 11:45:29AM +0200, Henri Sivonen wrote: It appears dom/browser-element/ was created for Gaia. Is it used for something still? WebExtensions perhaps? We've talked about giving access to WebExtensions (bug 1318532; partly because Google provides a similar element, and

Re: PSA: New method for registering XPCOM components

pending patches to convert) pretty much all of our old-style registrations, it wasn't clear to me that it would. On 5 Feb 2019, at 22:12, Kris Maglione wrote: As of bug 1478124, the new preferred method for registering XPCOM components is via static manifest files, as documented here: https

PSA: New method for registering XPCOM components

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

Re: Intent to ship: Devirtualizing IPC method calls (bug 1512990)

On Mon, Feb 04, 2019 at 04:29:54PM -0500, Alex Gaynor wrote: b) Memory -- we no longer need to emit vtables for all of these methods (~20 KB per process) \o/ c) Ergonomics -- implementing classes will now have control over whether they take arguments by value or reference \o/ Thank you :)

Re: Does mozilla allow modification of Strings

On Tue, Jan 29, 2019 at 02:08:59AM -0800, Nanday Dan wrote: On Tuesday, January 29, 2019 at 12:22:08 AM UTC+5:30, Kris Maglione wrote: >Is it possible to add an extra variable to mozilla string(nsTStringRepr). > > >I added a bool variable to nsTStringRepr class in Xpcom/Strings/

Re: PSA: Major ChromeUtils.import() API change

On Mon, Jan 28, 2019 at 04:50:28PM -0800, Kris Maglione wrote: Whatever else this whole process accomplishes, it will have the major side-effect of making our system JS code much more JIT-friendly, and in many cases, some orders of magnitude faster. Since there's been some question about my

PSA: Major ChromeUtils.import() API change

As of bug 1514594, the behavior ChromeUtils.import() API has changed in order to avoid touching the caller's global scope, or returning the imported module's global scope. In short, where you previously wrote: ChromeUtils.import("resource://gre/modules/Services.jsm"); You should now write

Re: Does mozilla allow modification of Strings

On Mon, Jan 28, 2019 at 04:51:12AM -0800, edusubscr...@gmail.com wrote: Is it possible to add an extra variable to mozilla string(nsTStringRepr). I added a bool variable to nsTStringRepr class in Xpcom/Strings/ As something of a side note, the general way to do this is to add a new data

Re: Does mozilla allow modification of Strings

On Mon, Jan 28, 2019 at 02:05:18PM +0100, Emilio Cobos Álvarez wrote: There are probably two different issues. On 1/28/19 1:51 PM, edusubscr...@gmail.com wrote: Is it possible to add an extra variable to mozilla string(nsTStringRepr). I added a bool variable to nsTStringRepr class

Re: Proposal to adjust our clang-format rules to include spaces after the hash for nested preprocessor directives

On Thu, Jan 10, 2019 at 08:01:52PM -0500, Ehsan Akhgari wrote: The common way to deal with this problem is to indent nested preprocessor directives, very much similarly to how we indent normal code, for example: #if foo # if bar #define x 1 # else #define x 2 # endif #endif +1

Re: Pointer to the stack limit

On Wed, Dec 19, 2018 at 07:36:52AM -0500, David Major wrote: You'll need platform-specific code, but on Windows there's https://searchfox.org/mozilla-central/rev/13788edbabb04d004e4a1ceff41d4de68a8320a2/js/xpconnect/src/XPCJSContext.cpp#986. And, to get a sense of caution, have a look at the

Re: PSA: Landing Rust code that warns is no longer ok

On Sat, Dec 15, 2018 at 04:06:05AM +0100, Emilio Cobos Álvarez wrote: In https://bugzilla.mozilla.org/show_bug.cgi?id=1513009 I just landed a patch so that warnings for non-third-party Rust code get reported as errors in automation, and thus fail to build (also if you build locally with

Re: Dropping support for compiling with MSVC in the near future

On Fri, Dec 07, 2018 at 10:57:41AM -0500, Gabriele Svelto wrote: On 06/12/18 15:39, Kris Maglione wrote: As it stands, we need to remain compatible with at least GCC and Clang, because some of our static analysis code still depends on GCC plugins. Some Linux distros will keep building Firefox

Re: Dropping support for compiling with MSVC in the near future

On Thu, Dec 06, 2018 at 03:34:59PM -0500, Jonathan Kew wrote: While I sympathize with the concern that "supporting more than one compiler is a maintenance burden", this still leaves me feeling a little uneasy. Ensuring that our code builds successfully with multiple compilers is a useful way

Re: Dropping support for compiling with MSVC in the near future

\o/ On Thu, Dec 06, 2018 at 03:00:12PM -0500, Ted Mielczarek wrote: Hello, In light of the fact that we've switched to clang-cl for our Windows builds[1], we are planning to drop support for compiling Firefox with MSVC in the near future[2]. Our estimate is that this will happen sometime in

Re: Performance profiling improvements #3

On Thu, Nov 01, 2018 at 02:38:46PM +0900, Mike Hommey wrote: On Thu, Nov 01, 2018 at 01:07:54AM -0400, Randell Jesup wrote: >I think sudo will let you have symbolicated kernel stacks which can be handy. $ sudo perf record ./firefox has a problem: "Running Nightly as root in a regular

Re: assignment between related nsCOMPtrs<> now works

On Tue, Oct 02, 2018 at 09:29:51AM -0700, Andrew McCreight wrote: This is a step towards bug 1493226, which is going to statically ban trivial do_QueryInterface calls like this: \o/ ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

On Mon, Sep 24, 2018 at 04:05:22PM -0400, Randell Jesup wrote: On 9/20/18 5:59 PM, Andrew McCreight wrote: On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione wrote: On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote: So, I don't think we need to do anything fancy with forking - we'd

Re: Browser Architecture Newsletter #7 (S02E02)

On Thu, Sep 20, 2018 at 09:02:09AM -0700, Nicholas Alexander wrote: On Thu, Sep 20, 2018 at 7:25 AM smaug wrote: > I'm reminded of https://bugzilla.mozilla.org/show_bug.cgi?id=618912 but > IIRC there were similar experiments back then on desktop, and basic html > chrome was significantly

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

ews" for personal email ___ 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://lis

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

On Wed, Sep 19, 2018 at 11:52:07AM -0400, Ehsan Akhgari wrote: FWIW, I think your original proposal, having a way to opt into assertions without a slow build locally, is extremely valuable. I could see myself using that option intentionally even with the pain points I described above, but for

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

There are some non-trivial snags for this proposal. A lot of assertions rely on other code gated on #ifdef DEBUG or DebugOnly<...> to avoid defining data members or storing values in non-debug builds. We could replace those with more fine-grained macros, of course, but particularly in the case

Re: MinGW Target Re-Enabled on TaskCluster

Thank you. This will make my development flow much easier. On Wed, Sep 12, 2018 at 12:09:36AM -0500, Tom Ritter wrote: Previous Thread: https://groups.google.com/forum/#!topic/mozilla.dev.platform/r3mYWbb42pM As of a few hours ago, there is a new Tier 2 MinGW build on TaskCluster. It's in the

Re: Plan for Sunsetting MozReview

___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation Memory is like an orgasm. It's a lot better if you don't have to fake

Re: PSA: nsISimpleEnumerator now works as a JS iterator

Oh, and from C++, there's also now a range iterator wrapper with similar semantics: for (auto& docShell : SimpleEnumerator(docShellEnum)) { ... } On Thu, Aug 23, 2018 at 03:19:55PM -0700, Kris Maglione wrote: As of bug 1484496, any C++-implemented nsISimpleEnumertor instance can be

Re: Proposal: Require dangling commas for multiline objects/arrays on all Javascript mozilla-central code

to the end of an array or object without realizing the last element didn't have a comma. Most of the areas I'm responsible for already require this rule, and it's saved me a lot of headaches. -- Kris Maglione The use of COBOL cripples the mind; its teaching should therefore be regarded as a criminal

Re: mozilla::Hash{Map,Set}

__ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation He who joyfully marches to music in rank and file has already earned my contempt. He has been

Re: mozilla::Hash{Map,Set}

On Wed, Aug 15, 2018 at 07:28:26PM -0400, Ehsan Akhgari wrote: On Wed, Aug 15, 2018 at 5:39 AM Nicholas Nethercote wrote: Bug 1477627 converted a hot hash table from PLDHashTable to mozilla::HashSet and appears to have sped up cycle collection in some cases by 7%. If you know of another

Re: mozilla::Hash{Map,Set}

___ 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 -- Kris Maglione Senior Fire

Re: PSA: xptcall on Tier-3 platforms

This is fantastic news. XPIDL has been stagnant for far too long, given how core a part of our platform it is. As anyone who's had to work with it can attest, it's basically a relic of the coding styles of the late '90s, and doesn't translate well to the practices of our current codebase.

Re: Stopgap for Commit Series in Phabricator

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 -- Kris Maglione [T]he people can always be brought to the bidding of the leaders. Th

Re: PSA: Major preference service architecture changes inbound

On Fri, Jul 20, 2018 at 11:53:22AM -0400, Ehsan Akhgari wrote: On Fri, Jul 20, 2018 at 5:00 AM, Jonathan Kew wrote: +1 to that. Our need for OMT access to prefs is only likely to grow, IMO, and we should just fix it once, so that any code (regardless of which thread(s) it may eventually run

Re: PSA: Major preference service architecture changes inbound

by a single thread). I think the trend needs to be in the opposite direction. Rust and JS make this much easier than C++ does, unfortunately. But we're getting better at it in C++, and moving more and more code to Rust. On Thu, Jul 19, 2018 at 2:19 PM, Kris Maglione wrote: On Tue, Jul 17, 2018 at 03

PSA: Default thread stack size decreased to 256K

tl;dr: Bug 1476828 significantly decreased the default thread stack size. If you notice any thread abort issues, please file bugs blocking that bug. For some time, our default stack size for thread pools has been 256K on most platforms, but the stack size for other threads has remained set to

Re: PSA: Major preference service architecture changes inbound

Maglione wrote: On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan Kew wrote: On 13/07/2018 21:37, Kris Maglione wrote: tl;dr: A major change to the architecture preference service has just landed, so please be on the lookout for regressions. We've been working for the last few weeks

Re: PSA: Major preference service architecture changes inbound

, Kris Maglione wrote: On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan Kew wrote: On 13/07/2018 21:37, Kris Maglione wrote: tl;dr: A major change to the architecture preference service has just landed, so please be on the lookout for regressions. We've been working for the last few weeks

Re: PSA: Major preference service architecture changes inbound

On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan Kew wrote: On 13/07/2018 21:37, Kris Maglione wrote: tl;dr: A major change to the architecture preference service has just landed, so please be on the lookout for regressions. We've been working for the last few weeks on rearchitecting

Re: XUL Overlays Removed

On Fri, Jul 13, 2018 at 02:10:54PM -0700, Brendan Dahl wrote: This is hopefully the last thing you’ll ever hear about XUL overlays as they have now been completely removed from Firefox[1]. \o/ Thank you to everyone who was involved in this! Removing overlays cut around 3.5K lines of code

PSA: Major preference service architecture changes inbound

tl;dr: A major change to the architecture preference service has just landed, so please be on the lookout for regressions. We've been working for the last few weeks on rearchitecting the preference service to work better in our current and future multi-process configurations, and those

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On Fri, Jul 13, 2018 at 11:14:24AM -0400, Randell Jesup wrote: Hash tables are a big issue. There are a lot of 64K/128K/256K allocations at the moment for hashtables. When we started looking at this in bug 1436250, we had a 256K, ~4 128K, and a whole bunch of 64K hashtable allocs (on linux).

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On Thu, Jul 12, 2018 at 10:27:13PM +0200, Gabriele Svelto wrote: On 12/07/2018 22:19, Kris Maglione wrote: I've actually been thinking on filing a bug to do something similar, to measure cumulative effects of excess padding in certain types since I began looking into bug 1460674, and Sylvestre

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On Thu, Jul 12, 2018 at 04:08:49PM -0400, Randell Jesup wrote: I do hope that the 100 process figures scenario that was given is a worse case scenario though... It's not. Worst case is a LOT worse. Shutting down threads/threadpools when not needed or off an idle timer is a Good thing.

Re: Intent to remove: the 'Memory usage of Subprocesses' table from about:performance

Florian -- Florian Quèze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation If we wish to count lines of code, we should not regard them as lines p

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

proportionally to the number of processes we have. On 07/10/2018 08:19 PM, Kris Maglione wrote: Welcome to the first edition of the Fission MemShrink newsletter.[1] In this edition, I'll sum up what the project is, and why it matters to you. In subsequent editions, I'll give updates on progress

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

up on this front is that bug 1402910 will probably allow us to increase the load factors of most of our hashtables without losing performance. Having up-to-date numbers for these things would probably help decide how to prioritize those sorts of bugs. On 07/10/2018 08:19 PM, Kris Maglione

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On Wed, Jul 11, 2018 at 11:42:01PM +0200, Jean-Yves Avenard wrote: On 11 Jul 2018, at 10:10 pm, Kris Maglione wrote: It looks like it will be helpful, but unfortunately won't give us the 2MB simple arithmetic would suggest. On Windows, at least, (and probably elsewhere, but need to confirm

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

stack sizes as we pretty much know which one needs more over others. JY On 10 Jul 2018, at 8:19 pm, Kris Maglione wrote: Welcome to the first edition of the Fission MemShrink newsletter.[1] In this edition, I'll sum up what the project is, and why it matters to you. In subsequent editions

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On Wed, Jul 11, 2018 at 02:42:11PM +0200, David Bruant wrote: 2018-07-10 20:19 GMT+02:00 Kris Maglione : The problem is thus: In order for site isolation to work, we need to be able to run *at least* 100 content processes in an average Firefox session I've seen this information of 100

Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

Welcome to the first edition of the Fission MemShrink newsletter.[1] In this edition, I'll sum up what the project is, and why it matters to you. In subsequent editions, I'll give updates on progress that we've made, and areas that we'll need to focus on next.[2] The Fission MemShrink

Re: CPOWs are now almost completely disabled

\o/ On Thu, Jun 28, 2018 at 12:52:51AM +0200, Tom Schuster wrote: Since landing bug 1465911 [1], CPOWs [2] are only functional on our testing infrastructure. In normal builds that we ship to users CPOWs can be created, but no operations like property lookup can be performed on them. CPOWs

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

Just to add one other point to this discussion: I *hate* backouts. I don't just mean of my patches. I mean in general. Whenever I come across a backout in a blame walk or a bisect, it makes my life much more difficult. And I know I'm not alone in this. I thought the policy for autoland was

Re: XPIDL trajectory

On Mon, Jun 25, 2018 at 09:45:22PM -0700, L. David Baron wrote: On Tuesday 2018-06-26 14:29 +1000, Nicholas Nethercote wrote: 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

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

On Sun, Jun 24, 2018 at 03:28:45PM -0400, Boris Zbarsky wrote: On 6/19/18 9:04 AM, Sebastian Hengst wrote: TL;DR: We would like to change the mozilla-inbound backout policy to be like autoland’s. This seems like a pretty reasonable change in general. Is there a well-documented try syntax

Re: Intent to move Activity Stream into its own process

and about:newtab, yes. There will still be Activity Stream code in the main process, but those pages will move from an ordinary content process to their own content process. 2018-06-18 21:58 GMT+02:00 Kris Maglione : +1 This should also have some memory benefits by preventing us from

Re: Intent to move Activity Stream into its own process

On Mon, Jun 18, 2018 at 09:19:18PM +0100, Gijs Kruitbosch wrote: Hey, This sounds really interesting. However, wouldn't this mean that we will do a process switch for the tab's browser whenever we load a URL in the same tab that has AS in it? Or would you still intend to run the actual AS

Re: Intent to move Activity Stream into its own process

+1 This should also have some memory benefits by preventing us from unnecessarily loading AS things into multiple content processes, like we do now. On Mon, Jun 18, 2018 at 03:35:01PM -0400, Mike Conley wrote: (posted on both dev-platform and firefox-dev. Please send replies to

PSA: Please use XPCOMUtils.defineLazyGlobalGetters rather than Cu.importGlobalProperties

tl;dr: importGlobalProperties is expensive. If you don't need the imported properties immediately, please use defineLazyGlobalGetters instead. Calling importGlobalProperties immediately defines the properties that you're importing and any prototypes that they require. Aside from CPU overhead,

Re: PSA: Please use ChromeUtils.generateQI for JS QueryInterface methods

useful. [1] https://searchfox.org/mozilla-central/rev/da499aac682d0bbda5829327b60a865cbc491611/tools/lint/eslint/eslint-plugin-mozilla/lib/rules/use-chromeutils-import.js#2 Thanks, Jared On Tue, May 8, 2018 at 3:26 PM Kris Maglione <kmagli...@mozilla.com> wrote: Bug 1456035

Re: Investigating leaks using DMD heap scan mode

On Tue, May 08, 2018 at 04:08:27PM -0700, Andrew McCreight wrote: A few years ago I came up with an approach for using a combination of cycle collector logs and DMD (which tracks all live blocks of heap allocated memory) to investigate leaks of refcounted objects. I've only had to use it about a

PSA: Please use ChromeUtils.generateQI for JS QueryInterface methods

Bug 1456035 added a ChromeUtils.generateQI helper to create QueryInterface methods for JS objects. The QueryInterface methods generated by this function are highly optimized, and have a fast path for calls from XPConnect. Which is to say, please use this method rather than manually writing

Re: PSA: new helper class for MozPromise in DOM code

of footguns for a while. We could probably use something similar for JS... RefPtr<DOMMozPromiseRequestHolder> holder = new DOMMozPromiseRequestHolder(global); Note, this can be written a bit more concisely as: auto holder = MakeRefPtr<DOMMozPromiseRequestHolder>(globa

Re: PSA: Deprecating JS-Implemented WebIDL

On Tue, Apr 24, 2018 at 07:25:18AM +0100, Andreas Tolfsen wrote: Also sprach Bobby Holley: For reasons outlined in bug 1450827, the DOM peers have decided to deprecate support for JS-implemented WebIDL APIs. This means that new additions of |JSImplementation="foo"| are no longer permitted.

Is super-review still a thing?

I can't remember the last time I saw a super-review request, but it's still documented as a policy[1]. Is it still a thing? Do we want it to still be a thing? The reason that I ask is that I have a problem that I think I might be able to solve by co-opting the super-review flag, but I don't

Re: Using WebIDL objects in XPIDL

On Thu, Apr 19, 2018 at 12:58:33PM -0700, Andrew McCreight wrote: On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch wrote: If I understand correctly, with these changes I could now just use Promise instead. Is that correct? Can I declare it including the resolution

Re: Using WebIDL objects in XPIDL

\o/ On Wed, Apr 18, 2018 at 11:19:27PM -0400, Nika Layzell wrote: 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

Re: XPT files shouldn't be added to package-manifest.in any more

On Wed, Apr 18, 2018 at 03:15:23PM -0400, Boris Zbarsky wrote: On 4/18/18 1:54 PM, Gijs Kruitbosch wrote: Given that we're also not supposed to be making new JS-implemented webidl things, what's the long-term plan for artifact build support for changing JS-implemented interfaces? For the

Re: The future of "remote XUL"

On Tue, Mar 27, 2018 at 03:48:24PM +, Dave Townsend wrote: My understanding is that it has been effectively unsupported for some time anyway so I think we should just go ahead and disable it altogether at this point. If we need bits for automated tests then we should work to switch tests

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Tue, Mar 20, 2018 at 11:43:13AM +0100, Frederik Braun wrote: On 20.03.2018 04:33, Dave Townsend wrote: The DoH service we're using is likely more private than anything the user is currently using. This is only true for some parts of the world. I'd like us not to regress for our user base

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 07:27:39PM -0700, Nicholas Alexander wrote: Hi all, On Mon, Mar 19, 2018 at 3:56 PM, Xidorn Quan wrote: It's fine to embed this experiment in the product, and blog about it, but it's definitely not fine to have it enabled by default and send every

Re: Use cases for invalid-Unicode atoms

On Mon, Mar 19, 2018 at 08:49:10PM +0200, Henri Sivonen wrote: It appears that currently we allow atomicizing invalid UTF-16 string, which are impossible to look up by UTF-8 key and we don't allow atomicizing invalid UTF-8. I need to change some things in this area in response to changing error

PSA: Unsafe CPOWs are no longer permitted in mochitests

For the last few years, mochitests have run in special extension scopes, which did things like interpose them with e10s shims and allow them to use unsafe CPOWs. As of today, those extension scopes no longer exist, and neither the mochitest harness nor the tests it runs have access to unsafe

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 08, 2018 at 04:41:38PM -0800, Bobby Holley wrote: On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione <kmagli...@mozilla.com> wrote: That said, if we're worried about binary size becoming an issue for internal interfaces, there are things we can do to reduce the code size of bi

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Thu, Mar 08, 2018 at 03:06:57PM -0800, Kris Maglione wrote: The amount of WebIDL overhead I regularly see in profiles can be staggering. The amount of *XPConnect* overhead... ___ dev-platform mailing list dev-platform@lists.mozilla.org https

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

performance issues, but I've never had a reviewer suggest that I should be worried about over-use. On Thu, Mar 8, 2018 at 2:01 PM, Kris Maglione <kmagli...@mozilla.com> wrote: It is now possible[1] to create chrome-only WebIDL interfaces in the dom/chrome-webidl/ directory t

PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

It is now possible[1] to create chrome-only WebIDL interfaces in the dom/chrome-webidl/ directory that do not require review by DOM peers after every change. If you maintain an internal performance-sensitive XPIDL interface, or are considering creating one, I'd encourage you to consider

Re: Prefs overhaul

On Wed, Mar 07, 2018 at 02:08:59PM +1100, Nicholas Nethercote wrote: Hi, I've been doing a lot of work to improve libpref recently, and there is more in the pipeline. I've written a brief roadmap that might be of interest to people: https://wiki.mozilla.org/Platform/PrefsOverhaul I'd be happy

  1   2   3   >