Re: Intent to disable service workers and push in 52 ESR

I just filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1338144 On Thu, Feb 9, 2017 at 4:26 AM, Kohei Yoshino wrote: > Do we already have a bug for this? Firefox 52 will be shipped just in 4 > weeks. > > > On 2017-01-18 10:49 AM, Ben Kelly wrote: > >> I'd like

Re: All the processes

On Fri, Mar 3, 2017 at 7:15 PM, Nicholas Nethercote wrote: > Do I have any of these details wrong? Have I missed any? > We plan to ship a "worker" process that will run ServiceWorker (and eventually SharedWorker) threads as part of: https://bugzilla.mozilla.org/show_bug.cgi?id=1231208 In the f

Re: All the processes

On Mon, Mar 6, 2017 at 5:12 PM, Nicholas Nethercote wrote: > Now for the reason I raised this: the major downside of using multiple > processes is that it increases memory usage. Recent-ish measurements showed > that for e10s-multi we could probably go up to 4 content processes without > blowing

Re: All the processes

On Mon, Mar 6, 2017 at 5:42 PM, Nicholas Nethercote wrote: > On Tue, Mar 7, 2017 at 9:22 AM, Ben Kelly wrote: > >> These measurements are for full content processes. Many of the processes >> in the above do not need all the chrome script we load in content processes >&

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

On Tue, Mar 7, 2017 at 6:09 PM, Xidorn Quan wrote: > > This major version change is downgrade-incompatible, so IndexedDB and > > DOM cache won't work in an older version if their profile has been > > upgraded. > > IndexedDB is also used internally, so stuff that depends on it likely > > won't wor

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote: > On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: > > I review a large number of patches on a typical day, and usually I have > to > > spend a fair amount of time to just understand what the patch is doing. > As > > the patch autho

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 5:48 PM, Eric Rescorla wrote: > > > On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly wrote: > >> (Just continuing the thread here.) >> >> Personally I prefer looking at the bug for the full context and single >> point of truth. Also, security

windows build anti-virus exclusion list?

Hi all, I'm trying to configure my new windows build machine and noticed that builds were still somewhat slow. I did: 1) Put it in high performance power profile 2) Made sure my mozilla-central dir was not being indexed for search 3) Excluded my mozilla-central directory from windows defender W

Re: windows build anti-virus exclusion list?

On Thu, Mar 16, 2017 at 11:26 PM, Ben Kelly wrote: > - mozilla-build install dir > - visual studio install dir > - /users/bkelly/appdada/local/temp > - /users/bkelly (because temp dir was not enough) > FWIW, adding all these extra exclusions dropped my build time from ~22

Re: windows build anti-virus exclusion list?

a.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites Thanks. Ben > > - mhoye > > > On Mar 16, 2017 20:34, "Ben Kelly" wrote: > > On Thu, Mar 16, 2017 at 11:26 PM, Ben Kelly wrote: > > > - mozilla-build install dir > >

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 12:05 AM, Ben Kelly wrote: > On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye wrote: > > Depending on your AV, if you don't exempt mozilla-central some of our >> tests will get quarantined and you won't be able to build at all. >> > >

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 1:36 PM, Ted Mielczarek wrote: > Back to the original topic, I recently set up a fresh Windows machine > and I followed the same basic steps (enable performance power mode, > whitelist a bunch of stuff in Windows Defender) and my build seemed > basically CPU-bound[1] durin

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 2:43 PM, Ted Mielczarek wrote: > > The 14min measurement must have been for a partial build. With defender > > disabled the best I can get is 18min. This is on one of the new lenovo > > p710 machines with 16 xeon cores. > > Nope, full clobber builds: `./mach clobber; tim

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 2:52 PM, Ben Kelly wrote: > On Fri, Mar 17, 2017 at 2:43 PM, Ted Mielczarek > wrote: > > Yeah, I specifically meant "CPU-bound during the compile tier", where we >> compile all the C++ code. If you look at the resource usage graphs I >>

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 3:40 PM, Ted Mielczarek wrote: > Yeah, the JS engine uses a lot more complex C++ features than the rest of > the code in our tree, so it takes longer to compile. This is also why the > `FILES_PER_UNIFIED_FILE` setting is lower in js/src than the rest of the > tree. We do t

Re: unowned module: Firefox::New Tab Page, help me find an owner

On Wed, Mar 22, 2017 at 9:22 AM, wrote: > I have not been able to find an owner for the Firefox::New Tab Page > bugzilla component (bug 1346908). There are 35 tests in the tree and > without anyone to assume responsibility for them when they are intermittent > (bug 1338848), I plan to delete the

Re: unowned module: Firefox::New Tab Page, help me find an owner

On Wed, Mar 22, 2017 at 9:39 AM, wrote: > On Wednesday, March 22, 2017 at 9:35:35 AM UTC-4, Ben Kelly wrote: > > You plan to delete all the tests? This seems somewhat extreme for a > > shipped feature. Why not disable just the tests that are intermittent? > > I agree th

Re: unowned module: Firefox::New Tab Page, help me find an owner

On Wed, Mar 22, 2017 at 10:00 AM, David Burns wrote: > On 22 March 2017 at 13:49, Ben Kelly wrote: > >> Finding someone to own the feature and investigate intermittents is >> important too, but that doesn't mean the tests have zero value. >> > > This just stri

Re: e10s-multi update and tests

On Wed, Mar 22, 2017 at 9:12 PM, Andrew McCreight wrote: > On Wed, Mar 22, 2017 at 6:00 PM, Nicholas Nethercote < > n.netherc...@gmail.com > > wrote: > > > Do we have a clear definition of "content process"? I.e. does/will it > > include: > > > > - GMP processes (no?) > > - GPU process (probably

Re: Better download security through browsers

We now have SRI and support integrity attributes on elements like

Re: A reminder about commit messages: they should be useful

On Mon, Apr 17, 2017 at 9:21 PM, Nicholas Nethercote wrote: > > That is why we have links to the bug. Bug should always be the unite of > > truth telling > > why some change was done. Bugs tend to have so much more context about > the > > change than any individual commit message can or should ha

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 eve

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 have quite the right s

Re: Avoiding jank in async functions/promises?

On Wed, May 17, 2017 at 10:19 PM, Ben Kelly 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 number here: https://bug

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: http

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: 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 wrote: > Hi all, > > I want to give everyone a heads-up that I'm

Re: more setTimeout() changes incoming

; dictacted by our nsITimer implementation. Our 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 wrot

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 flags). >>> >>> But it do

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 pr

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 Linux support (Firefox

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 more at > > web developers and testing regu

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: > >> > >> "When a person writes a new compiled-code component,

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 2017-07-05 11:02 -0700, L.

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 exist with patches attached, that wo

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 > phabricate reviews back i

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, solve

Re: Phabricator Update, July 2017

On Jul 14, 2017 6:27 PM, "Mike Hommey" 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 one of them. I don&#x

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 one-to-one mapping betwe

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 fragmentation still outw

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

On Jul 19, 2017 8:57 PM, "Mike Hommey" wrote: On Wed, Jul 19, 2017 at 08:48:45PM -0400, Ben Kelly wrote: > On Jul 19, 2017 6:20 PM, "Mike Hommey" wrote: > > > What would be the rationale behind this choice? > > Smaller memory footprint, which, you'll 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 event listener is

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 orientation. _

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: failed to run custom bui

Re: sccache as ccache

On Wed, Aug 2, 2017 at 12:26 PM, Ben Kelly wrote: > 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

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 in non-e10s mode, righ

Re: disabled non-e10s tests on trunk

On Tue, Aug 8, 2017 at 5:18 PM, Ben Kelly wrote: > On Tue, Aug 8, 2017 at 5:12 PM, wrote: > >> While we get some advantages to not running duplicated tests (faster try >> results, less backlogs, fewer intermittent failures) there might be >> compelling reasons to run som

Re: disabled non-e10s tests on trunk

On Tue, Aug 8, 2017 at 5:18 PM, Ben Kelly wrote: > On Tue, Aug 8, 2017 at 5:12 PM, wrote: > >> In bug 1386689, we have turned them off. There was some surprise in >> doing this and some valid concerns expressed in comments in the bug. Given >> that, I thought we shoul

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: https://bugzill

Re: Firefox and clang-cl

On Mon, Aug 14, 2017 at 6:11 AM, Till Schneidereit < t...@tillschneidereit.net> wrote: > On Mon, Aug 14, 2017 at 9:27 AM, Julian Seward wrote: > > > On 13/08/17 03:40, Ehsan Akhgari wrote: > > > As you may have heard by now, Chromium has started to switch their > > Windows > > > builds to use cla

Re: Response.body streams landing on trunk, default off

FYI, the Fetch API side of streams has landed and is now in nightly. Please test and file bugs. Thanks! Ben On Thu, Aug 10, 2017 at 11:29 PM, Ben Kelly wrote: > Hi all, > > As some of you may know :till and :baku have been working hard to > implement ReadableStream support. Til

Re: Linking with lld instead of ld/gold

On Sun, Aug 13, 2017 at 5:08 PM, Sylvestre Ledru wrote: > To use it, you should have a clang >= 4.0 installed and lld installed > on the system. > clang is in charge of the LLD detection with its option -fuse-ld=lld > (this option is also supported by gcc since version 6). Clang will > look for t

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

Chris, Do you know who controls this blog post? https://blog.mozilla.org/firefox/firefox-64-default-64-bit-windows/ The chart is really misleading. What does the vertical bar chart for "security" even mean? As noted on twitter: https://twitter.com/kylealden/status/897222041476005888 The bar

Re: disabled non-e10s tests on trunk

On Tue, Aug 15, 2017 at 4:29 PM, wrote: > While there are many tests which individually are disabled or lacking > coverage, these test suites have no non-e10s coverage: > * web-platform-tests > * browser-chrome > * devtools > * jsreftests > * mochitest-webgl, mochitest-gpu, mochitest-media > * re

Re: disabled non-e10s tests on trunk

On Tue, Aug 15, 2017 at 4:37 PM, Joel Maher wrote: > All of the above mentioned tests are not run on Android (well > mochitest-media is to some degree). Is 4 months unreasonable to fix the > related tests that do not run in e10s? Is there another time frame that > seems more reasonable? > Last

Re: disabled non-e10s tests on trunk

On Tue, Aug 15, 2017 at 4:43 PM, Joel Maher wrote: > This is a discussion about tests in e10s mode, not WPT on Android. > Yes. And android is our last tier 1 platform that requires non-e10s. I think that makes it relevant to the discussion. > > What specific coverage are we missing by not ru

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 > coverage and ensure that use

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 avoid the need to heap > all

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

On Mon, Aug 21, 2017 at 10:00 AM, Ben Kelly 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 mailing list dev-pl

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 read-ish > pull-request, b

Re: Intent to ship: Abort API

On Tue, Aug 29, 2017 at 9:39 AM, Ben Kelly 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 >> default everywhere in our codebase (dom.abor

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 perceived performance. > I jus

Re: Quantum Flow Engineering Newsletter #22

On Fri, Sep 1, 2017 at 10:06 AM, Ben Kelly wrote: > 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 >><https://bugzilla.mozilla.org/

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 implementing this Andrea! Be

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 > And the patch: > https

Re: Re: Firefox and clang-cl

On Thu, Sep 7, 2017 at 10:09 AM, Nathan Froyd wrote: > On Thu, Sep 7, 2017 at 10:04 AM, Ben Kelly wrote: > > On Mon, Aug 14, 2017 at 10:44 AM, Tristan Bourvon > > wrote: > > > >> Here's the RFC of the overflow builtins: > >> http://clang-

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 be

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: 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 dropping them. (Since the >

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, w

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 http://searchfox.org/mozilla-central/source/dom/base/nsDocument.cpp#1

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, > > TL;DR - containers i

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

On Mon, Sep 25, 2017 at 9:28 AM, Ben Kelly 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/releases/latest > Sorry,

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" 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 wrote: > On Mon, Sep 25, 2017 at

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 https://w3c.g

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, 2017 at 12:02 PM, Jeff Muizelaar > > > wro

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 working really well. We'd

Re: Intent to ship: Retained Display Lists

On Tue, Oct 31, 2017 at 11:44 PM, Ben Kelly 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. Its unclear what flipping the pre

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 = NS_NewRunnableFunction([uniqueThin

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 secur

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: https:/

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 wrote: > Hi all, > > I just wanted to send a note about a bug in nightly which is leading to > delayed shutdowns. Curre

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" 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. > > On Thu, Nov 30,

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 wrote: > Both fixes have stuck and are in the latest nightly. Sorry for the > headaches here.

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 runn

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 week. (I'm not going t

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

On Dec 9, 2017 8:25 AM, "Gijs Kruitbosch" 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 > initial implementation is limited t

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 of what we achieved in wp

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 l

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 > the list but it coul

Re: Refactoring proposal for the observer service

On Thu, Jan 4, 2018 at 10:00 AM, Nathan Froyd wrote: > On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly wrote: > > 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 > >> though

Re: Refactoring proposal for the observer service

On Thu, Jan 4, 2018 at 4:35 PM, Gabriele Svelto 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. > > > AFAIK there is no way i

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., > https://bugzilla.mozilla.org/show_bug.cgi?id=14

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 > > Insecure Contexts > > > > >

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 wrote: >

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 wrote: > Sum

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: 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 AM,

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: > Hello everyone, > > I

  1   2   >