Response.body streams landing on trunk, default off

Hi all, As some of you may know :till and :baku have been working hard to implement ReadableStream support. Till landed the js bits in bug 1272697: https://bugzilla.mozilla.org/show_bug.cgi?id=1272697 Andrea has been working on the DOM integration with Fetch API in bug 1128959:

Re: More Rust code

On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote wrote: > On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley > wrote: > > > If I were the owner of that module I would consider implementing a policy > >> something like the following: > >> > >>

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

We have implementation close to review for one-shot sync. I don't know of any browser that has implemented and shipped periodic sync yet. On Tue, Jul 11, 2017 at 2:49 PM, L. David Baron wrote: > On Tuesday 2017-07-11 11:38 -0700, L. David Baron wrote: > > On Wednesday

Re: Phabricator Update, July 2017

On Tue, Jul 11, 2017 at 11:49 PM, Martin Thomson wrote: > On Wed, Jul 12, 2017 at 1:34 PM, Byron Jones wrote: > > instead of disabling splinter for phabricator backed products, we could > make > > it a read-only patch viewer. > > Given the number of bugs that

Re: Phabricator Update, July 2017

On Wed, Jul 12, 2017 at 11:27 AM, Byron Jones wrote: > But indeed having also the patches in bugzilla would be good. >> > no, it would be bad for patches to be duplicated into bugzilla. we're > moving from bugzilla/mozreview to phabricator for code review, duplicating >

Re: Phabricator Update, July 2017

Also a random reply. I think this kind of effort is more likely to be successful if it gets input and buy-in from the key stakeholders. In this case that would be the most frequent reviewers. It would be nice to run a bugzilla query to find the top 10 or 20 reviewers. Talk to these folks,

Re: Phabricator Update, July 2017

On Jul 14, 2017 6:27 PM, "Mike Hommey" <m...@glandium.org> wrote: On Fri, Jul 14, 2017 at 01:00:51PM -0400, Ben Kelly wrote: > I know feedback was collected, but maybe not from this group. Feedback was collected from a selected set of the people who do the most reviews. I'm o

Re: Phabricator Update, July 2017

On Mon, Jul 17, 2017 at 12:27 PM, Gregory Szorc wrote: > If the bug is only serving as an anchor to track code review, then the > question we should be asking is "do we even need a bug." > In my experience the answer to this is "yes, we need a bug". I very rarely have a

Re: Keyboard APZ has landed on Inbound

On Sat, Jul 22, 2017 at 2:05 AM, Ryan Hunt wrote: > Keyboard APZ can't be used in every case. Currently it's disabled in the > presense of key event listeners, as they can preventDefault scrolling and > that > is a non-negotiable part of the web. > Do we do keyboard APZ if the

Re: Intent to remove: sensor APIs

On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren wrote: > * Device orientation > Isn't this one required to build a decent web experience on mobile for some sites? It seems pretty common on mobile to adjust the UX based on whether the device is in portrait/landscape

Re: 64-bit Firefox progress report: 2017-07-18

On Jul 19, 2017 8:57 PM, "Mike Hommey" <m...@glandium.org> wrote: On Wed, Jul 19, 2017 at 08:48:45PM -0400, Ben Kelly wrote: > On Jul 19, 2017 6:20 PM, "Mike Hommey" <m...@glandium.org> wrote: > > > What would be the rationale behind this choice? >

Re: 64-bit Firefox progress report: 2017-07-18

On Jul 19, 2017 6:20 PM, "Mike Hommey" wrote: > What would be the rationale behind this choice? Smaller memory footprint, which, you'll admit, when you're on a machine with (less than) 2GB RAM, makes a difference. I thought we had data that showed OOM (small) due to VM

Re: Ambient Light Sensor API

The post suggests that limiting precision would mitigate the issue. We could do that immediately while we wait for telemetry to roll in. The post says reducing the frequency of the readings would not be very effective, but maybe we should reduce the frequency anyway? Possibly firing an event

Re: disabled non-e10s tests on trunk

On Tue, Aug 8, 2017 at 5:18 PM, Ben Kelly <bke...@mozilla.com> wrote: > On Tue, Aug 8, 2017 at 5:12 PM, <jma...@mozilla.com> wrote: > >> While we get some advantages to not running duplicated tests (faster try >> results, less backlogs, fewer intermittent failures

Re: disabled non-e10s tests on trunk

On Tue, Aug 8, 2017 at 5:12 PM, wrote: > As Firefox 57 is on trunk, we are shipping e10s by default. This means > that our primary support is for e10s. As part of this, there is little to > no need to run duplicated tests in non-e10s and e10s mode. > We still run android

Re: sccache as ccache

On Wed, Aug 2, 2017 at 12:26 PM, Ben Kelly <bke...@mozilla.com> wrote: > On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek <t...@mielczarek.org> > wrote: > >> Yesterday I published sccache 0.2 to crates.io, so you can now `cargo >> install sccache` and get

Re: sccache as ccache

On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek wrote: > Yesterday I published sccache 0.2 to crates.io, so you can now `cargo > install sccache` and get the latest version (it'll install to > ~/.cargo/bin). > I tried this on my linux build machine today and got: error:

Re: disabled non-e10s tests on trunk

On Wed, Aug 16, 2017 at 2:32 PM, Joel Maher wrote: > Thanks everyone for chiming in here. I see this isn't as simple as a > binary decision and to simplify things, I think turning on all non-e10s > tests that were running for windows7-debug would give us reasonable >

Re: Avoiding jank in async functions/promises?

On Wed, May 17, 2017 at 10:03 PM, Boris Zbarsky wrote: > On 5/17/17 9:22 PM, Mark Hammond wrote: > >> I'm wondering if there are any ideas about how to solve this optimally? >> > > I assume https://w3c.github.io/requestidlecallback/#the-requestidleca > llback-method doesn't

Re: Avoiding jank in async functions/promises?

On Wed, May 17, 2017 at 10:19 PM, Ben Kelly <bke...@mozilla.com> wrote: > FWIW, we have a similar problem in the native TimeoutManager::RunTImeout() > method. I'm using a time budget approach to make it adapt to different > hardware better. > I meant to include the bug n

more setTimeout() changes incoming

Hi all, I want to give everyone a heads-up that I'm hoping to push some setTimeout() changes to inbound in the next day or two: https://bugzilla.mozilla.org/show_bug.cgi?id=1363829 The main result people should be aware of is that setTimeout() will be more accurate and precise after this lands

Re: Intent to ship: NetworkInformation

Can the people who have concerns about the NetworkInformation API please provide the feedback to google on this blink-dev thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/UVfNMH50aaQ/CXY6S39TBQAJ In particular, I think they tried to consider privacy in this part of the spec:

Re: more setTimeout() changes incoming

precision should be approximately the same as behavior. The main benefit of this landing will be reduced allocation and locking overhead when setTimeout()/setInterval() is used. On Thu, May 25, 2017 at 11:00 AM, Ben Kelly <bke...@mozilla.com> wrote: > Hi all, > > I want to give ever

Re: JSBC: JavaScript Start-up Bytecode Cache

On Tue, Jun 13, 2017 at 5:50 AM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > The JavaScript Start-up Bytecode Cache⁰ is a project which aims at > reducing the page load time by recording the bytecode generated during the > last visits and by-pass the JavaScript parser. > > This

Re: Shipping Headless Firefox on Linux

I typically use xvfb-run when executing tests locally. How does headless mode differ? Does it just run faster, but at the cost not testing some widget code? On Wed, Jun 14, 2017 at 7:51 PM, Brendan Dahl wrote: > Hello All, > > > As of Firefox 55 I intend to ship headless

Re: Shipping Headless Firefox on Linux

On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd wrote: > On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: > > Headless will run less of the platform specific widget code and I don't > > recommend using it for platform specific testing. It is targeted

Re: Linux builds now default to -O2 instead of -Os

On Tue, Jun 6, 2017 at 3:07 PM, Chris Peterson wrote: > On 6/6/17 10:33 AM, Boris Zbarsky wrote: > >> On 6/1/17 9:04 PM, Mike Hommey wrote: >> >>> Ah, forgot to mention that. No, it doesn't affect *our* shipped builds >>> (because PGO uses a different set of optimization

PSA: nsPipe3.cpp is now using diagnostic assertions

Hi all, FYI, I just pushed a patch to nsPipe3.cpp that switches it to use MOZ_DIAGNOSTIC_ASSERT() instead of the weaker assertions it used to use. This class is used extensively throughout the browser and state problems can manifest as intermittent hangs, crashes, and memory leaks. For example,

Re: TabChild visibility

FWIW, our nsIDocument::VisibilityState() is updated when the docshell goes active: http://searchfox.org/mozilla-central/source/dom/base/nsIDocument.h#2855 http://searchfox.org/mozilla-central/source/dom/base/nsDocument.cpp#12504

Intent to implement and ship PerformanceResourceTiming.workerStart

The PerformanceResourceTiming API has had a `workerStart` value specified for a couple years now. Its defined to represent the time when we trigger a service worker FetchEvent. It will be zero if service workers are not involved. https://bugzilla.mozilla.org/show_bug.cgi?id=1191943

Re: disabled non-e10s tests on trunk

Joel, Is there an easy way for me to run non-e10s tests on linux? We often use "t-style" try pushes where we only run tests on one platform. Restricting non-e10s to win7-debug means I either need to run tests on multiple platforms or use windows for the "t-style". I don't want to use windows

Re: Re: Firefox and clang-cl

On Thu, Sep 7, 2017 at 10:09 AM, Nathan Froyd <nfr...@mozilla.com> wrote: > On Thu, Sep 7, 2017 at 10:04 AM, Ben Kelly <bke...@mozilla.com> wrote: > > On Mon, Aug 14, 2017 at 10:44 AM, Tristan Bourvon <tbour...@mozilla.com> > > wrote: > > > >> He

Re: Re: Firefox and clang-cl

On Mon, Aug 14, 2017 at 10:44 AM, Tristan Bourvon wrote: > Here's the RFC of the overflow builtins: > http://clang-developers.42468.n3.nabble.com/RFC-Introduce- > overflow-builtins-td3838320.html > Along with the tracking issue: https://bugs.llvm.org/show_bug.cgi?id=12290 >

Re: Re-visiting the DOM tree depth limit in layout

On Wed, Sep 13, 2017 at 4:44 AM, Henri Sivonen wrote: > I suggest we do the following: > > 1) Change the HTML parser behave more like Blink's: Raise the limit > to 513 elements deep and append elements violating the limit to the > 512th element on the stack instead of

Re: Intent to ship: Abort API

On Wed, Sep 6, 2017 at 12:27 PM, Andrea Marchesini wrote: > Abort API and the Fetch() integration should be enabled by default in the > next nightly. > To clarify, its already enabled in nightly, but the patch to let it ride the trains is now in inbound. Thanks for

Re: indexedDB.open failing silently?

Can you have the user try in a fresh profile? I think this behavior might occur if they used a profile in a newer version of firefox (like nightly 57) and then try to take it back to an older version (like release 55). Database schemas can be updated in various storage APIs on disk which prevent

Re: Containers graduation from Test Pilot - we still care about 57+

Thanks Jonathan. Also, it seems the link to the web extension version of the container addon is broken above. This one works for me: https://github.com/mozilla/multi-account-containers/releases/latest On Sat, Sep 23, 2017 at 9:52 AM, Jonathan Kingston wrote: > Hi All, > >

Re: Containers graduation from Test Pilot - we still care about 57+

On Mon, Sep 25, 2017 at 9:28 AM, Ben Kelly <bke...@mozilla.com> wrote: > Thanks Jonathan. > > Also, it seems the link to the web extension version of the container > addon is broken above. This one works for me: > > https://github.com/mozilla/multi-account-containers/rel

Re: Containers graduation from Test Pilot - we still care about 57+

It disables multi-e10s. Forced to one content process. On Sep 27, 2017 12:58 PM, "Andrew McKay" <amc...@mozilla.com> wrote: Sorry, it disables e10s even though it has true in the install.rdf? That shouldn't be the case. On 27 September 2017 at 07:14, Ben Kelly <bke...

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

On Sun, Aug 20, 2017 at 6:35 PM, Nicholas Nethercote wrote: > Hi, > > For a long time we have had types nsAutoString and nsAutoCString which are > strings with 64 chars of inline storage. They are good for holding short > strings, most often on the stack, because they

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

On Mon, Aug 21, 2017 at 10:00 AM, Ben Kelly <bke...@mozilla.com> wrote: > Should that be `mStorage[N + 1]`? > Maybe not since things like NSID_LENGTH include the null pointer on their end. Sorry for my confusion. ___ dev-platform mail

Re: Quantum Flow Engineering Newsletter #22

On Fri, Sep 1, 2017 at 10:06 AM, Ben Kelly <bke...@mozilla.com> wrote: > On Fri, Sep 1, 2017 at 1:59 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > >>- Mike Conley made it so that background tabs are “warmed up” when >>hovering the mo

Re: Quantum Flow Engineering Newsletter #22

On Fri, Sep 1, 2017 at 1:59 AM, Ehsan Akhgari wrote: >- Mike Conley made it so that background tabs are “warmed up” when >hovering the mouse cursor over them >. This should >improve tab switching

Re: Intent to ship: Abort API

On Tue, Aug 29, 2017 at 2:05 AM, Andrea Marchesini wrote: > Abort API is already part of the DOM spec and I would like to enable it by > default everywhere in our codebase (dom.abortController.enabled). Abort + > Fetch integration is not part of the spec yet. There is a

Re: Intent to ship: Abort API

On Tue, Aug 29, 2017 at 9:39 AM, Ben Kelly <bke...@mozilla.com> wrote: > On Tue, Aug 29, 2017 at 2:05 AM, Andrea Marchesini < > amarches...@mozilla.com> wrote: > >> Abort API is already part of the DOM spec and I would like to enable it by >> d

PSA: increased chance of new leaks due to delayed shutdown issue

Hi all, I just wanted to send a note about a bug in nightly which is leading to delayed shutdowns. Currently nightly is taking 5 to 10 seconds to shutdown. Bisection has shown this was introduced by my landing in: https://bugzilla.mozilla.org/show_bug.cgi?id=1419536 I have a fix here:

Re: Next year in web-platform-tests

I know you aware, but just mentioning for the list: We need WPT coverage on Android to fully rely on it as our primary test suite. Particularly while Android's config deviates so far from desktop. On Dec 15, 2017 10:40 AM, "James Graham" wrote: > Following the summary

Re: mozilla-central now compiles with C++14

On Wed, Nov 15, 2017 at 8:44 PM, Nathan Froyd wrote: > * initialized lambda captures > I would like to use initialized lambda capture as I think it will allow move-only objects to be used in lambdas like this: UniquePtr uniqueThing = MakeUnique(); nsCOMPtr r =

service workers at risk for FF59 ESR

As you may be aware, we have disabled service workers in all ESR releases since it was implemented. At first this was because it was a big new feature with security implications. Then it was because we realized we needed to rewrite a lot of code to properly support multi-e10s. Back porting

Re: Intent to ship: Retained Display Lists

On Tue, Oct 31, 2017 at 11:44 PM, Ben Kelly <bke...@mozilla.com> wrote: > Anecdotely this pref seems to make twitter much less janky on fennec on my > Nexus 5x. > Actually, at least some retained display list code is disabled in non-e10s because of a process type check. I

Re: PSA: increased chance of new leaks due to delayed shutdown issue

Both fixes have stuck and are in the latest nightly. Sorry for the headaches here. On Dec 1, 2017 1:15 PM, "Ben Kelly" <bke...@mozilla.com> wrote: > FYI, we have a fix identified for the late shutdown leak as well. I will > push them to inbound once the trees re-open. &g

Re: PSA: increased chance of new leaks due to delayed shutdown issue

Actually this was backed out from m-c for a single failing android test this morning. So please be aware we are at risk of introducing leaks again. On Sat, Dec 2, 2017 at 9:27 PM, Ben Kelly <bke...@mozilla.com> wrote: > Both fixes have stuck and are in the latest nightl

Re: new code to help with cross-process windows/workers (and Clients API)

On Fri, Dec 8, 2017 at 4:38 PM, Mike Conley wrote: > >> I personally think this would be useful, and will (probably) only > happen if > >> you do it now, before you move on to the next thing. +1 for > documentation! > > I concur. > Alright. I'll work on a blog post next

Re: new code to help with cross-process windows/workers (and Clients API)

On Dec 9, 2017 8:25 AM, "Gijs Kruitbosch" <gijskruitbo...@gmail.com> wrote: On 08/12/2017 20:23, Ben Kelly wrote: > Please let me know if you have any question or if you think you have a > feature that could integrate with the clients infrastructure. While the &g

Re: PSA: increased chance of new leaks due to delayed shutdown issue

FYI, we have a fix identified for the late shutdown leak as well. I will push them to inbound once the trees re-open. On Thu, Nov 30, 2017 at 11:18 PM, Ben Kelly <bke...@mozilla.com> wrote: > Hi all, > > I just wanted to send a note about a bug in nightly which is leading to >

new code to help with cross-process windows/workers (and Clients API)

Hi all, I just want to give you a heads up about some new infrastructure that is landing in the tree. In particular, we now have: 1. A central list of windows and workers for the entire browser in the parent process. This includes information on their origin, url, and what process they are

Re: Default Rust optimization level decreased from 2 to 1

Would it be possible to have our profiling tools warn if about:compiler optimization flags are not in about:buildconfig? On Tue, Oct 31, 2017 at 3:39 PM, Jeff Muizelaar wrote: > On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc wrote: > > On Tue, Oct 31,

Re: Intent to ship: Retained Display Lists

On Oct 26, 2017 12:15 AM, wrote: On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote: > We're planning on landing the code for retaining display lists in 58, > behind the pref layout.display.list.retain. > This has now landed in Nightly, and looks to be

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

On Fri, Apr 27, 2018, 3:13 AM Jean-Yves Avenard wrote: > > The class is called DOMMozPromiseRequestHolder. Here is an example using > > it: > > is that just a refcounted version of MozPromiseRequestHolder? > No. It binds to the global and calls DisconnectIfExists() when

PSA: new CopyableErrorResult class

Hi all, I just pushed another helper class that I thought others might find useful. CopyableErrorResult is a specialized form of ErrorResult. Its intended to allow slightly more rich error values to be passed through things like ipdl structure and MozPromise. This is useful when implementing

Re: Refactoring proposal for the observer service

On Thu, Jan 4, 2018 at 4:35 PM, Gabriele Svelto <gsve...@mozilla.com> wrote: > On 03/01/18 23:30, Ben Kelly wrote: > > Could we use our existing idl/webidl/ipdl for this? It would be nice > > not to have to maintain another code generator in the tree if possible. > &

overly strict eslint rules

Hello, First let me say, I don't like participating in style discussions on the list. I don't think they are productive in general and I don't want to have one of those threads here. I feel I need to raise as an issue, though, as eslint rules are being pushed out into components with what seem

Re: Intent to Unship: Application Cache over Insecure Contexts

On Fri, Jan 19, 2018 at 12:26 PM, Mike Taylor wrote: > > When the pref is set to false the API will be removed: > > > > - > > > > window.applicationCache will be removed > > - > > > > The cache service Firefox implements for AppCache will be disabled over > >

PSA: service worker code has moved

Hi all, Just FYI, we have moved the service worker code and tests from: dom/workers dom/workers/test/serviceworkers To: dom/serviceworkers dom/serviceworkers/test We did this because the service worker feature is about much more than just spawning a thread in the current process. Its

Re: PSA: C++ virtual function declarations should specify only one of virtual, final, or override

Are we supposed to just use override or final on methods that are overriden when the class itself is marked final? Personally writing final again seems redundant with the class level final and the override keyword seems more informative. On Fri, Feb 16, 2018 at 3:36 PM, Chris Peterson

Re: Refactoring proposal for the observer service

On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote: > So after validating my approach in that bug (which is almost ready) I've > thought that it might be time to give the observer service the same > treatment. First of all we'd have a list of topics (I've picked YAML for

Re: Refactoring proposal for the observer service

On Thu, Jan 4, 2018 at 10:00 AM, Nathan Froyd <nfr...@mozilla.com> wrote: > On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly <bke...@mozilla.com> wrote: > > On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto <gsve...@mozilla.com> > wrote: > >> So after validating m

Re: Requiring secure contexts for new features

On Tue, Jan 16, 2018 at 1:11 PM, Anne van Kesteren wrote: > * Modules might want to look into ways of enforcing this > programmatically, to ease ongoing maintenance and guide everyone to do > the right thing without having to ask/review/etc. E.g., >

testing event targets for memory leaks

Hi all, I recently landed some test infrastructure for testing event targets for memory leaks. This was part of fixing my service worker memory leak in bug 1447871. I wanted to let people know this existed and also ask for help writing tests for more event targets. To repeat, I need help

Re: testing event targets for memory leaks

On Thu, Apr 5, 2018 at 12:18 PM, Ben Kelly <bke...@mozilla.com> wrote: > If one of these targets falls in your area, please try to find the time to > write a small test as described above. Also, please link it against the > meta bug here: > > https://bugzilla.mozilla.org/sh

Re: Phabricator and Bugzilla

On Sat, Mar 31, 2018, 10:09 AM Mark Côté wrote: > Regarding comment and flag mirroring, we've discussed this before: > > > https://groups.google.com/d/msg/mozilla.dev.platform/Y8kInYxo8UU/e3Pi-_FpBgAJ > >

Re: testing event targets for memory leaks

On Mon, Apr 9, 2018 at 12:06 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 4/5/18 1:11 PM, Ben Kelly wrote: > >> 1. Make sure you set the nsIGlobalObject owner by passing it to the DETH >> constructor or by calling BindToOwner(). >> > > Can we just enforce

Re: testing event targets for memory leaks

On Mon, Apr 9, 2018 at 12:32 PM, Ben Kelly <bke...@mozilla.com> wrote: > On Mon, Apr 9, 2018 at 12:06 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > >> On 4/5/18 1:11 PM, Ben Kelly wrote: >> >>> 1. Make sure you set the nsIGlobalObject owner by passing it to

Re: testing event targets for memory leaks

On Mon, Apr 9, 2018 at 3:16 PM, Randell Jesup wrote: > I'm surprises that DOMDataChannel wasn't found: > nsDOMDataChannel.h: > class nsDOMDataChannel final : public mozilla::DOMEventTargetHelper, > > perhaps you were looking for "public DOMEventTargetHelper"? > Yep.

Re: testing event targets for memory leaks

PSA, I am landing additional leak tests for AudioContext IDB WebSocket As part of: https://bugzilla.mozilla.org/show_bug.cgi?id=1451913 On Thu, Apr 5, 2018 at 12:18 PM, Ben Kelly <bke...@mozilla.com> wrote: > Hi all, > > I recently landed some test infrastructure fo

Re: CPU core count game!

That page says "physical cores", so its not taking into account hyper threading, right? So even a high end macbook pro falls in that category? On Tue, Mar 27, 2018 at 5:02 PM, Mike Conley wrote: > Thanks for drawing attention to this, sfink. > > This is likely to become

Re: PSA: nsIURI implementations are now threadsafe

Do we have any plan to be able to use NS_NewURI() off-main-thread? I thought that was included here, but I see now that it is not. The initial URL parse OMT is important for truly being able to remove all our "bounce to the main thread for URL stuff" legacy code. On Fri, Mar 23, 2018 at 8:25

Re: PSA: nsIURI implementations are now threadsafe

This is so great. Thank you! One question that comes to mind, though, is there any chance this could be uplifted to 60? As we start doing more OMT nsIURI stuff its going to become difficult to uplift code to 60ESR. On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu wrote:

Re: PSA: nsIURI implementations are now threadsafe

ry threadsafe parsing first and only fall back to a main thread bounce if its an oddball URL. Right now we hardcode a bunch of http/https/nsStandardURL things in various places to accomplish this. > > > On 26 March 2018 at 15:24, Ben Kelly <bke...@mozilla.com> wrote: > >> Do

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

Note, this effort is already being reported in the tech press based on this thread. For example: https://www.theregister.co.uk/AMP/2018/03/20/mozilla_firefox_test_of_privacy_mechanism_prompts_privacy_worries/ A blog post does sound like a good idea. On Mon, Mar 19, 2018, 11:33 PM Dave Townsend

Re: Intent to implement and ship: spec compliance Promise microtask behavior

I just want to give a huge thank you to everyone who worked on this. Its such a monumental task to change such a core feature, especially with new tests that might depend on the old behavior being added all the time. Thank you! Ben On Wed, Feb 28, 2018 at 6:58 AM, Hiroyuki Ikezoe

PSA: new helper class for MozPromise in DOM code

Hi all, I pushed a new helper class to inbound today to make it easier to work with MozPromise in DOM code. Specifically, it allows you to auto-disconnect a Thenable request when the global dies. The class is called DOMMozPromiseRequestHolder. Here is an example using it: #include

<    1   2