Re: Intent To Ship: backdrop-filter

One other note: I don't think we should be too concerned about the specific multiple-graphics-backends situation arising frequently in the future. The goal is to have a single backend (WebRender) going forward, and last I checked the plan was to completely drop all other backends within the next 12

Re: PSA: Precise test scheduling with |mach try auto|

This is very exciting on a number of fronts: reduced CI spend, detecting more defects, and reduced cognitive overhead for developers. Thanks to Andrew and everyone else involved for getting us here! On Mon, Jun 8, 2020 at 9:14 AM Andrew Halberstadt wrote: > *tl;dr**: Your |mach try auto| pushes

Re: ChromeUtils.addProfilerMarker - new API to add profiler markers from JS code

On Wed, Apr 8, 2020 at 6:35 PM Tom Ritter wrote: > I'm pretty sure that if you're not in the System Principal; your > timestamps from the performance object are going to be clamped to 1ms > resolution (and potentially jittered forward) > ChromeUtils is only available to System Principal code

Re: Intent to implement and ship: Ignore navigation to unknown protocol

Reading the post a few times, I'm still unclear on a few things, so would appreciate clarification. Here's what I understand from the post: On the user's machine, there is some entropy, i.e. the set of schemes for which an external protocol handler is registered. This entropy is currently retrieva

Re: New and improved stack-fixing

So excited to see this fixed - thank you Nick! On Thu, Mar 5, 2020 at 2:52 PM Nicholas Nethercote wrote: > Hi all, > > I have written a new stack-fixing tool, called `fix-stacks`, which > symbolizes stack traces produced by Firefox. > > `fix-stacks` is intended to replace our existing stack-fixi

Re: Intent to Deploy: ThreadSanitizer

Very excited to see TSan going live. Thanks for pushing it forward! On Thu, Feb 6, 2020 at 6:12 AM Christian Holler wrote: > Data races in C/C++ code are a class of bugs that can severely impact > stability of the product while being hard to reproduce and debug. > Furthermore, data races are und

Re: PSA: You can use UTF8String from WebIDL

Thank you (and all the dependent authors) for working on this! String conversion overhead is so silly in theory yet so difficult to eliminate in practice. It's great to see us investing in the right architecture to enable these optimizations across the board. On Sun, Jan 5, 2020 at 5:51 PM Emilio

Re: PSA: Remote Canvas 2D is being enabled on Nightly

Very excited to see this happening - consolidating D3D access into the GPU process is important on a number of fronts (security, but also memory). Thanks Bob and everyone else involved for pushing this forward. On Wed, Nov 20, 2019 at 12:27 PM wrote: > Hi all, > > I have just landed the patch t

Re: Proposal: Replace NS_ASSERTION with MOZ_ASSERT and then remove it.

On Wed, Oct 30, 2019 at 8:47 AM Nathan Froyd wrote: > On Wed, Oct 30, 2019 at 11:36 AM Tom Ritter wrote: > > > > I will claim that the most common behavior of developers is to leave > > XPCOM_DEBUG_BREAK alone and not set it to any particular value. I bet > most > > people haven't even heard of

Re: PSA: Android test environments

This is a great summary, and reflects a ton of hard work over the past year to improve our mobile testing story and reduce our CI spend. Thanks gbrown and everyone else who helped make it happen! On Fri, Oct 18, 2019 at 11:52 AM Geoffrey Brown wrote: > The Android test environments used for cont

Re: Elements no longer have a QueryInterface method in JS

Huzzah! So excited to see all this going away. On Mon, Oct 14, 2019 at 7:15 PM Boris Zbarsky wrote: > Hello all, > > Now that we no longer have xbl implements="" to worry about, I have > landed patches to remove the QueryInterface method from Element > instances [1] and the infrastructure for ex

Re: Intent to remove: Fennec

+1. This is a big milestone, and reflects countless hours of hard work building our next-generation mobile stack. Congrats to everyone involved! On Thu, Sep 19, 2019 at 12:59 PM Kris Maglione wrote: > > This sounds like a stellar plan. > > -Kris > > On Thu, Sep 19, 2019 at 02:55:56PM -0500, James

Re: JS testing functions and compartments in mochitest-plain

On Mon, Aug 26, 2019 at 12:02 AM Henri Sivonen wrote: > If in a plain mochitest I do > var rope = > SpecialPowers.Cu.getJSTestingFunctions().newRope(t.head, t.tail); > var encoded = (new TextEncoder()).encode(rope); > the encode() method doesn't see the rope. Instead, the call to > en

Re: [ann] `mach build` now includes `mach package` for Android

That's great news! Many thanks to Nick and all the other folks who've worked so hard to make our Android developer experience great. On Fri, Aug 23, 2019 at 2:12 PM Nicholas Alexander wrote: > Hi folks! > > tl;dr: you don't need to run `mach package` for Android (GeckoView) any > more. > > Bug 1

Re: Fission Newsletter #2

On Fri, Aug 9, 2019 at 11:11 AM Nika Layzell wrote: > On Fri, Aug 9, 2019 at 1:55 PM Alexis Beingessner > > wrote: > > > Is dogfoodability at all platform-specific for fission? i.e. is windows > > the only platform that is really actively developed/maintained? (as would > > make sense at this st

Re: cross-language LTO enabled on nightly for all platforms

Thanks! Nathan also clarified on IRC that this runs only on the "shippable" variant of CI builds. On Mon, Jul 22, 2019 at 8:58 AM Nathan Froyd wrote: > On Mon, Jul 22, 2019 at 11:45 AM Bobby Holley > wrote: > > Can you confirm which types of builds enable this? Does --en

Re: cross-language LTO enabled on nightly for all platforms

Thanks for the hard work getting this over the line! Can you confirm which types of builds enable this? Does --enable-release turn it on? On Mon, Jul 22, 2019 at 6:56 AM Nathan Froyd wrote: > Hi all, > > We now have link-time optimization (LTO) between Rust and C++ code > enabled on Nightly for

Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`

On Tue, Jul 9, 2019 at 3:23 PM Mike Hommey wrote: > On Tue, Jul 09, 2019 at 10:39:37AM -0400, Ehsan Akhgari wrote: > > On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart > > wrote: > > > > > Thank you all for some very interesting discussions so far. > > > > > > Even if we don't take blanket steps

Re: NS_NewURI is now thread-safe

This is awesome work and has been years in the making. Thanks to everyone involved for getting it over the line! On Mon, Jun 10, 2019 at 1:42 PM Valentin Gosu wrote: > On Mon, 10 Jun 2019 at 22:25, Boris Zbarsky wrote: > > > On 6/10/19 4:07 PM, Valentin Gosu wrote: > > > which means nsIURI > >

Re: nsIPresShell has gone

At long last - thank you! On Thu, May 2, 2019 at 7:20 PM Cameron McCormack wrote: > On Fri, May 3, 2019, at 11:44 AM, Masayuki Nakano wrote: > > Finally, I completely got rid of nsIPresShell from our tree. > > https://bugzilla.mozilla.org/show_bug.cgi?id=253889 > > Thank you for doing this, Masa

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

On Wed, May 1, 2019 at 10:27 AM Jonathan Kew wrote: > On 01/05/2019 17:29, Randell Jesup wrote: > > Jean-Yves writes: > >>> If anyone is chomping at the bit to remove 1proc support from their > module, > >>> please speak up. > >> > >> I am one of those developers that find non-e10s essential to d

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

On Thu, Apr 25, 2019 at 9:38 AM Joel Maher wrote: > > > On Thu, Apr 25, 2019 at 12:12 PM Bobby Holley > wrote: > >> On Thu, Apr 25, 2019 at 3:36 AM Joel Maher wrote: >> >>> >>> >>> On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley >>

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

On Thu, Apr 25, 2019 at 3:36 AM Joel Maher wrote: > > > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley > wrote: > >> > >>> > Thanks Mike! >>> > >>> > So Fennec is the last remaining non-e10s configuration we ship to >>> us

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

On Wed, Apr 24, 2019 at 4:30 PM Mike Hommey wrote: > On Wed, Apr 24, 2019 at 03:49:47PM -0700, Bobby Holley wrote: > > On Wed, Apr 24, 2019 at 2:21 PM David Major wrote: > > > > > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley > > > wrote: > > > > &

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

On Wed, Apr 24, 2019 at 2:21 PM David Major wrote: > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley > wrote: > > > > Thanks Mike! > > > > So Fennec is the last remaining non-e10s configuration we ship to users. > > Given that Fennec test coverage is somewh

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

;> user to end up using non-e10s? If so we should turn these tests back on. >> >> On Tue, Apr 23, 2019 at 8:25 AM Joel Maher wrote: >> >> > Here is where we initially turned on non-e10s tests for win7: >> > https://bugzilla.mozilla.org/show_bug.cgi?id=139137

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

If we're not testing it, we shouldn't be shipping it to users. It would be great if someone familiar with the esr60 situation could confirm that we don't plan to repeat it for esr68. It would also be great if someone could explain the rationale for running some, but not all of the suites in 1proc m

Announcing ./mach busted

TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a central clearinghouse of bugs for broken mozilla-central tooling. You can invoke |./mach busted| to get a list of known outstanding issues, and |./mach busted file| to report a new one. Few things burn up productivity quite like broken t

Re: Intent to deprecate - linux32 tests starting with Firefox 69

I'd like to refocus this thread a bit around Jed's question, because it gets to the core of the issue. The proposal argues that test results for linux32 closely track those for linux64, and that this duplication is expensive. If that's the only problem, we could solve it by keeping linux32 as a ti

Re: crash reporting, inline functions, and you

This is awesome - thank you Nathan! On Fri, Apr 5, 2019 at 9:34 AM Nathan Froyd wrote: > TL;DR: We're making some changes to how inlined functions are handled > in our crash reports on non-Windows platforms in bug 524410. This > change should mostly result in more understandable crash stacks fo

Re: To what extent is sccache's distributed compilation usable?

My (possibly outdated) understanding is that the sccache distributed compilation stuff is restricted to the build machines we control. Naively, I'm not sure there's a secure way to have machines in the wild contribute build artifacts, given the risk of malicious code. It seems plausible that we co

Re: How do we land `./mach vendor rust` patches, these days?

It's worth noting that pulling in code from crates.io has different trust properties than NSS. In general, it's the developer and reviewer's responsibility to ensure that any newly-vendored Rust code is not malicious. This usually doesn't necessitate a painstaking line-by-line review, but needs som

Re: XPCOM Tidying Proposal

On Fri, Jan 11, 2019 at 3:10 PM Kyle Machulis wrote: > On Fri, Jan 11, 2019 at 11:59 AM Bobby Holley > wrote: > >> The idea is that we should gradually pass BasePrincipal around the >> codebase >> rather than nsIPrincipal, which would avoid the need to invoke Cast at

Re: XPCOM Tidying Proposal

On Fri, Jan 11, 2019 at 11:30 AM Boris Zbarsky wrote: > On 1/10/19 6:15 PM, Kyle Machulis wrote: > > - Removal of [noscript] methods in interfaces in favor of direct calls > via > > Cast() where possible. > > This seems generally reasonably, though I'd like to put in a bit of a > vote for the pat

Re: Rust code coverage

On Fri, Jan 4, 2019 at 4:54 AM Marco Castelluccio wrote: > Hi everyone, > we have recently enabled collecting code coverage for Rust code too, > running Rust tests in coverage builds. It'll be great to finally see code coverage for the style system - thanks for doing this! > The support is st

Re: PSA: nsIDocument is now mozilla::dom::Document.

This is awesome - thanks Emilio! On Thu, Jan 3, 2019 at 3:27 PM Emilio Cobos Álvarez wrote: > I've always been slightly annoyed at the fact that Gecko used to have > multiple classes for the same concept of a document node without any > clear separation these days (nsIDocument and nsDocument). >

Re: This year in web-platform-tests - 2018 edition

Great stuff! Thanks to you and everyone involved for pushing the state of cross-browser testing forward. On Fri, Dec 7, 2018 at 7:45 AM James Graham wrote: > Welcome to the second annual update on progress in cross-browser interop > testing through web-platform-tests. This year has seen big impr

Re: Extension to integrate Searchfox features in Phabricator

I noticed this extension seems to be causing significant jank while typing comments into phabricator. I'll send a profile to Marco, but just an FYI for anyone else who's using it. On Tue, Oct 2, 2018 at 6:03 AM Marco Castelluccio wrote: > I've built an (experimental) WebExtension to integrate so

Re: assignment between related nsCOMPtrs<> now works

This is awesome - great papercut fix. Thanks Andrew! Any chance of fixing it for RefPtr too? On Tue, Oct 2, 2018 at 9:30 AM Andrew McCreight wrote: > I've landed bug 1494765, which allows you to do assignments between > nsCOMPtrs for classes that are related by subtyping. > > For instance: > >

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

So, I don't think we need to do anything fancy with forking - we'd just need to capture stacks and send them via telemetry rather than as a crash report. This was the idea behind bug 1209131, which got pretty far along but never made it to the finish line. I spoke with Georg about it recently, and

Re: geckodriver enabled in local developer builds

Thanks for doing this! I recently struggled to run some tests before realizing that they depended on geckodriver, which wasn't built by default. Assuming this didn't negatively impact build times, I'm glad to see a reduction in build config options. On Wed, Sep 12, 2018 at 2:36 AM Andreas Tolfsen

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

This is awesome - thanks kats! On Tue, Sep 11, 2018 at 12:58 PM Kartikaya Gupta wrote: > Just a heads up that as of today Searchfox is also indexing Rust and C++ > code that is conditionally compiled only on macOS. It was previously only > doing code compiled on Linux. Windows and Android are no

PSA: xptcall on Tier-3 platforms

XPConnect requires some platform-specific code to do its magic [1]. There are around ~28 different copies of this code in xpcom/reflect/xptcall, which makes it very difficult to maintain. Historically, we've handled this by treating xptcall as fixed and working around its deficiencies. Given the n

Re: C++ standards proposal for a embedding library

In practice, I kind of doubt that standard libraries would actually include multiple implementations of the web platform. It also seems like it could break update cadence, since standard libraries don't have nearly as rapid or streamlined and mechanism for pushing out updates. It seems like they c

Re: Using clang-cl to ship Windows builds

+1. This is really fantastic news, and frankly happened way faster than I would have thought possible. Thanks to everyone involved! On Tue, Jul 10, 2018 at 1:51 PM Gregory Szorc wrote: > On Tue, Jul 10, 2018 at 1:29 PM, David Major wrote: > >> Bug 1443590 is switching our official Windows build

Re: Rust crate approval

I think the key distinction here is that, unlike other rust-based projects (i.e. Servo), Firefox vendors all cargo dependencies into the tree, so it's more obvious to reviewers when a patch indirectly pulls in a new large dependency. In Servo the reviewer would have to look carefully at the Cargo.l

Re: CPOWs are now almost completely disabled

This is awesome - thanks Tom! On Wed, Jun 27, 2018 at 3:53 PM 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

Re: Rust crate approval

On Wed, Jun 27, 2018 at 12:42 PM Simon Sapin wrote: > On 27/06/18 19:45, Bobby Holley wrote: > > Hi Adam, > > > > At present, I think you should raise your questions with Nathan Froyd and > > Ehsan Akhgari, who are the owners of the C++/Rust usage module [1].

Re: Rust crate approval

Hi Adam, At present, I think you should raise your questions with Nathan Froyd and Ehsan Akhgari, who are the owners of the C++/Rust usage module [1]. There has been some discussion around creating a Rust-in-Firefox Advisory Committee to handle questions like this, but it hasn't happened yet. In

Re: Default Rust optimization level decreased from 2 to 1

On Wed, Apr 25, 2018 at 10:21 AM, Ted Mielczarek wrote: > On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote: > > At minimum we should make --enable-profiling build with rust-opt. > > This sounds reasonable, although the quirk is that we default > --enable-profiling on for nightly[1], so any

Re: Default Rust optimization level decreased from 2 to 1

I think that makes sense as a default, with the ability to explicitly --disable-release if people are profiling something specific, know what they're doing, and want faster builds. On Wed, Apr 25, 2018 at 9:32 AM, Jeff Muizelaar wrote: > At minimum we should make --enable-profiling build with ru

Re: Default Rust optimization level decreased from 2 to 1

Could we instead have the profiler UI throw up a warning if the build was not compiled with --enable-release? On Wed, Apr 25, 2018 at 9:23 AM, Emilio Cobos Álvarez wrote: > > > On 4/25/18 6:11 PM, Gregory Szorc wrote: > >> >> >> On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez wrote: >>> >>> The

PSA: Deprecating JS-Implemented WebIDL

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. If you maintain an existing JS WebIDL implementation, or are considering designs for a new API, pl

Re: Uint8Array in XPIDL

On Mon, Apr 9, 2018 at 1:22 AM, Henri Sivonen wrote: > In order to remove XPIDL interfaces when corresponding Web Platform > features are available, I've been trying to get our internal JS code > to switch from nsIScriptableUnicodeConverter to TextDecoder and > TextEncoder. > > The main problem i

Re: CPU core count game!

On Wed, Mar 28, 2018 at 12:03 PM, Steve Fink wrote: > Yes, sorry, a couple of people pointed that out to me privately. And I did > get that mixed up; I was assuming processors, despite the page specifically > pointing out "physical cores". > > I still think there's something to be kept in mind he

Re: Please try out clang-cl and lld-link on Windows

It's really exciting to see such rapid progress being made here. Thanks David! On Tue, Mar 13, 2018 at 7:31 AM, David Major wrote: > Link xul.dll in 20 seconds with this one weird trick! > > > Hi everyone, > > clang-cl builds of Firefox have come a long way, from being a hobby project > of a few

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

On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez wrote: > Nicholas Nethercote > 2018 March 9 at 20:02 > > What's your definition of XPCOM? > > This is basically what I'm asking Kris. I define it as the system that > Firefox uses to make intra- and inter-language calls between C++ and JS via > XPIDL a

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

On Fri, Mar 9, 2018 at 11:53 AM, Jeff Muizelaar wrote: > On Fri, Mar 9, 2018 at 7:21 AM, Ted Mielczarek wrote: > > On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote: > >> (C) The API uses complex arguments like promises that XPIDL doesn't > handle > >> in

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

On Fri, Mar 9, 2018 at 12:15 AM, Zibi Braniecki (Gandalf) < zbranie...@mozilla.com> wrote: > > > On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley > wrote: > >> I just looked at the first 10 methods/attributes on that interface. None >> of them are remotely performanc

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

On Thu, Mar 8, 2018 at 5:56 PM, Kris Maglione wrote: > On Thu, Mar 08, 2018 at 04:41:38PM -0800, Bobby Holley wrote: > >> On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione >> wrote: >> >>> That said, if we're worried about binary size becoming an issue for >

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

On Thu, Mar 8, 2018 at 5:04 PM, Mike Hommey wrote: > On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote: > > I've seen a lot of momentum around migrating chrome-only XPIDL interfaces > > to WebIDL. I'm concerned that insufficient attention is being paid to the

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

On Thu, Mar 8, 2018 at 3:06 PM, Kris Maglione wrote: > On Thu, Mar 08, 2018 at 02:40:52PM -0800, Bobby Holley wrote: > >> I've seen a lot of momentum around migrating chrome-only XPIDL interfaces >> to WebIDL. I'm concerned that insufficient attention is being paid to

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

I've seen a lot of momentum around migrating chrome-only XPIDL interfaces to WebIDL. I'm concerned that insufficient attention is being paid to the impact on our binary size. Fundamentally, the WebIDL bindings improve performance and spec correctness at the expense of code size (and build times).

Re: Prefs overhaul

This looks like great work - I'm very glad to see us investing in improvements to core infrastructure like this. Thanks Nick! On Tue, Mar 6, 2018 at 7:08 PM, 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

Reduced Build Times for Stylo Code

Just a happy update that the code size reduction work we've been doing on the style system also seems to have made an impact on build times. Over the past week, we've removed almost half a megabyte of code from libxul. On my linux64 ThinkStation, an optimized build of the style system [1] seems to

Re: [dev-servo] PSA: Avoid invoking Debug formatters in release-mode Rust

-mode compiles, so this would cause our logging code to break. > > In the PR you link, AFAICT you also removed some uses that were just very > small enums or even integers, which may not be necessary. > > > Le 13 janv. 2018 à 06:07, Bobby Hol

PSA: Avoid invoking Debug formatters in release-mode Rust

TL;DR: To prevent code bloat, avoid {:?} in format strings for panic!(), unreachable!(), error!(), warn!(), and info!() for Rust code that ships in Gecko. Longer version: One nice thing about Rust is that you can #[derive(Debug)] for a type, and the compiler will generate a stringification method

Re: performing cross-context instanceof checks

On Thu, Jan 11, 2018 at 12:06 PM, Kris Maglione wrote: > On Thu, Jan 11, 2018 at 05:12:37PM +0100, Tom Schuster wrote: > >> This could be an issue for WebExtensions as well. I think the >> contentscript >> sandbox runs in a different compartment. >> > > It runs in a different compartment, but the

Re: performing cross-context instanceof checks

IIRC Blink uses a different mechanism (called "separate worlds") to allow extensions to interact with content, whereas we use a separate global + xrays. So this likely will be a problem for WebExtensions, and we'll presumably need a sandboxOption to opt into the old behavior. On Thu, Jan 11, 2018

Re: PSA: searchfox now indexes rust

This is amazing! I just tried it out and it's now much easier to navigate around the style system. Tooling like this matters a lot. My deepest thanks to everyone involved in making this happen. bholley On Mon, Jan 8, 2018 at 8:15 AM, Kartikaya Gupta wrote: > Just a heads-up, thanks to a bunch

Re: Is ReentrantMonitorAutoExit a footgun?

Yeah I've always been pretty appalled that this exists. We should remove it if at all possible. bholley On Nov 24, 2017 04:45, wrote: I just came to realize: ReentrantMonitorAutoEnter lock1(...); ReentrantMonitorAutoEnter lock2(...); { ReentrantMonitorAutoExit unlock1(...); // This will n

Re: De-XBL Plans

As one of the lonely few peers for our XBL implementation, I am thrilled that this is finally happening. My deepest gratitude to everyone involved! bholley On Tue, Oct 31, 2017 at 3:06 PM, Dave Townsend wrote: > Having not heard any show-stopping concerns with the plan we will start to > proce

Re: Easier debugging/inspecting of remote tab state with the Browser Content Toolbox

Wow, this is great! I just ran into this problem a week ago and it was quite annoying to work around. Thanks for fixing it. :-) bholley On Tue, Oct 3, 2017 at 4:15 PM, Matthew N. wrote: > With bug 1401343 > fixed, `TabChildGlobal`s for the

Re: getComputedStyle now skips restyling if possible

This is a great optimization - thanks wcp! On Thu, Sep 28, 2017 at 2:00 AM, Wei-Cheng Pan wrote: > Hi, > > This week I landed bug 1363805[1], which will skip restyling if the > element does > not need that for getting correct value. Normal users should not notice any > difference, but this chang

Re: Intent to require `mach try` for submitting to Try

On Tue, Sep 19, 2017 at 9:20 AM, Andrew McCreight wrote: > On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla wrote: > > > Generally no, but this is an unfortunate consequence of Mozilla's > decision > > a while ago to pick a VCS which has not turned out to be the dominant > > choice (not placing bl

Re: Canonical cinnabar repository

po that includes the CVS history will make the SHA's > incompatible with doing a direct conversion of hg which is a > disadvantage. I'm not sure what's more valuable. > > -Jeff > > On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari > wrote: > > On 09/18/2017 01:16

Re: Canonical cinnabar repository

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight wrote: > On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta > wrote: > > > I've tried using cinnabar a couple of times now and the last time I > > tried, this was the dealbreaker for me. My worfklow often involves > > moving a branch from one machi

Re: Intent to require `mach try` for submitting to Try

FWIW, I've found |./mach try fuzzy| to be very intuitive and kind of the best of both worlds for command-line vs GUI. I don't know what the non-fuzzy version does, but perhaps fuzzy should be the default. On Fri, Sep 15, 2017 at 4:51 PM, Nicholas Nethercote wrote: > Are there docs on how to use

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

Note also that, post-stylo, there are some very rough plans to investigate rewriting the frame constructor in parallel Rust, which would likely move us to a non-recursive model. But we probably won't start brainstorming the details until the all-hands, have no idea if it will work, and even if it d

Kris Maglione and Andrew McCreight are now XPConnect Peers

XPConnect is not exactly a fun module. When I took the reins from mrbkap 4.5 years ago, Peter wiped a tear from his eye and said "Congratulations, Blake." Still, it's at the heart of Gecko, and needs ongoing attention from deep hackers. With the old hands busy with other things recently, Kris and

Re: Stylo now the default configuration for mozilla-central

On Tue, Sep 5, 2017 at 4:15 PM, L. David Baron wrote: > On Tuesday 2017-09-05 14:55 -0700, Chris Peterson wrote: > > We can stop testing the "stylo-disabled" test platforms on Mac and > Windows > > after we ship Stylo to Release. We can remove them entirely after we ship > > Stylo on Android. > >

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 1, 2017 at 9:59 AM, Botond Ballo wrote: > On Fri, Sep 1, 2017 at 12:11 PM, Ehsan Akhgari > wrote: > > How about this slight variation: > > > > HTMLEmbedElement.isInstanceOf(obj) > > > > instead of "is"? > > Isn't that backwards, though? HTMLEmbedElement isn't an instance of > 'obj',

Re: reducing high try macosx pending counts

Thanks to everyone involved for accommodating the extra load from the stylo side - it's a necessary part of our ramp-up to shipping. Luckily, we should only be running the two configurations side-by-side for a month or two, after which point load should drop back down to normal levels. Thanks Kim

Re: New minimum Rust version policy for Firefox

This is great - thanks Ralph! On Tue, Aug 1, 2017 at 11:53 AM, Ralph Giles wrote: > We've formalized a new plan for when we update the minimum-required Rust > version for building Firefox. Starting later this week we'll require the > latest stable Rust two weeks after it is released. > > This me

Re: who uses idl stuff

I might suggest having a look at https://wiki.mozilla.org/Gecko:Overview for your general architectural questions. On Sun, Jul 23, 2017 at 12:00 AM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > Hi folks, > > > could anyone please give me some insight, where the the IDLs >

Re: Care in the use of MOZ_CRASH_UNSAFE_* macros: data review needed

On Mon, Jul 17, 2017 at 9:42 AM, Benjamin Smedberg wrote: > I don't know really anything about how rust panics get reflected into > crash-data. Who would be the right person to talk to about that? > Rust panics are equivalent to MOZ_CRASHES, and we treat them as such (or at least try to, see bug

Re: More Rust code

On Mon, Jul 10, 2017 at 5:39 PM, Nicholas Nethercote wrote: > On Tue, Jul 11, 2017 at 2:33 AM, Bobby Holley > wrote: > >> >> In other words, I think we should encourage people to consider Rust for >> new code, but also make sure that we have a thoughtful and informed

Re: More Rust code

There are obvious benefits to writing new things in Rust. In general, the main barrier to doing so is the extent to which they may interact with existing C++ code, and the adequacy of our tooling for managing that interaction. In London last year, we had a meeting to discuss how we wanted to use R

Re: switch to macosx cross-compiled builds on taskcluster on trunk

+1 to that. So great to see so many parts of the org coming together to make something like this happen! On Wed, Jun 21, 2017 at 2:00 PM, Boris Zbarsky wrote: > On 6/21/17 2:38 PM, Kim Moir wrote: > >> At 11:00PT today, we will be landing patches to run mac opt builds on >> trunk >> as cross com

Re: Intent to unship: HTML scoped style sheets (

Yeah - stylo for the frontend would be nice, but it's not part of our MVP. It wouldn't be hard, just presumably implementing a few more scattered internal things and fixing more bugs exposed by the heavier usage of XBL. But we could ship in 57 without it, and so it seems foolish to widen our scope

Re: Intent to unship: HTML scoped style sheets (

Yeah - stylo for the frontend would be nice, but it's not part of our MVP. It wouldn't be hard, just presumably implementing a few more scattered internal things and fixing more bugs exposed by the heavier usage of XBL. But we could ship in 57 without it, and so it seems foolish to widen our scope

Re: Profiling nightlies on Mac - what tools are used?

Instruments is the big one that I'm aware of. On Mon, Jun 19, 2017 at 3:03 PM, Chris Cooper wrote: > Hey all, > > The build peers are looking to change the way that nightlies are created > on Mac as we switch to cross-compilation. Specifically, we're looking at > stripping the nightlies to avoid

Re: Intent to ship: SharedArrayBuffer and Atomics

On Thu, May 11, 2017 at 2:48 PM, Lars Hansen wrote: > On Thu, May 11, 2017 at 10:55 AM, Martin Thomson wrote: > > > On Thu, May 11, 2017 at 5:57 PM, Lars Hansen > wrote: > > > We do think there are > > > architectural improvements that hardware manufacturers, operating > > systems, > > > and br

Re: Using references vs. pointers in C++ code

I think passing non-nullable things by reference is good, but I think we should keep it consistent for a given type. So, for example, we shouldn't have some callsites that take an nsPresContext* and others that take an nsPresContext& (unless we have a rare case of a nullable presContext arg, in whi

Re: Editing vendored crates

On Sun, Feb 26, 2017 at 2:10 PM, Bobby Holley wrote: > On Sun, Feb 26, 2017 at 9:51 AM, Henri Sivonen > wrote: > >> I tried to add some panics to a vendored to create (rust-encoding) to >> see if the code in question runs. However, I didn't get to the running >&g

Re: Editing vendored crates take #2

I definitely made this work at some point: https://hg.mozilla.org/try/rev/18dc070e0308 The main difference with what you seem to be doing is that my version points directly into third-party/rust, which I think is preferable anyway. On Fri, Apr 28, 2017 at 10:05 AM, Josh Matthews wrote: > Back i

Re: [stylo-team] new configure option: --enable-debug-rust

This is awesome - thanks Nathan! On Fri, Apr 14, 2017 at 10:46 PM, Nathan Froyd wrote: > Bug 1353810, recently merged to central, adds a new configure option > --enable-debug-rust. This option enables compiling the Rust code > in-tree with debug-friendly settings (no optimization, multiple > co

Re: Changing the behavior for inheriting the Security Context of data: URLs

Really glad to hear that this is getting close - thanks for working on this stuff! On Wed, Apr 5, 2017 at 1:59 AM, Christoph Kerschbaumer < christ...@christophkerschbaumer.com> wrote: > Hey everyone, > > we are in the process of changing the handling of data: URLs to which user > agents navigate.

Re: The future of commit access policy for core Firefox

On Fri, Mar 17, 2017 at 12:41 AM, Jean-Yves Avenard wrote: > And yet, despite many people’s concerns, it appears that policy of > removing r+ whenever a new push has been made effective. > To my knowledge, mconnor's proposal has yet to get anywhere close to an actual policy. Was there a behavior

Re: Tracking bug for removals after XPCOM extensions are no more?

On Thu, Mar 16, 2017 at 11:23 AM, R Kent James wrote: > On 3/15/2017 3:51 PM, Benjamin Smedberg wrote: > >> after Firefox 57 when >> Webextensions are the only extensions, if our product no longer needs some >> functionality (and it's "API"), let's remove it. Quickly and ruthlessly. >> We >> need

  1   2   3   4   5   >