GeckoView now supported by mach run --debug

Hi everybody, I am pleased to announce that I have landed bug 1581971, which adds support for using `mach run --debug` with GeckoView and jdb+lldb! To use it, you will need to re-bootstrap and re-configure your GeckoView build. Furthermore, if you explicitly set the location of your

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

On 6/10/2020 2:09 PM, tom...@gmail.com wrote: * GeckoView still supports running in non-e10s mode, and inability to mimic that environment on desktop builds would complicate writing code that works on android. GeckoView's only technical reason for supporting non-e10s was FxR, but they have

Re: PSA: Dispatching background tasks just got easier!

\o/ This is super exciting! Thank you! On 12/13/2019 12:25 PM, Kristen Wright wrote: Hello! Now that Bug 1584568 just landed I wanted to mention the new background thread pool for general purpose and blocking IO runnables. Existing one-off threads, as well as new jobs

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

\o/ Way to go! On Wed, Nov 20, 2019 at 1:27 PM wrote: > Hi all, > > I have just landed the patch to enable moving accelerated Canvas 2D to the > GPU process on Windows. > > This is only enabled on Nightly at the moment and is part of our work to > move GPU access and win32k system calls out of

e10s tooling (Was 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 11:40 PM Jean-Yves Avenard wrote: > > Before non-e10s support is removed, I'd love to see better > development/debugging tools, particularly on Windows added to help our > workflow. Was there anything in particular that you had in mind? - Aaron > >

Re: Moving Windows MSVC Builds Back To Tier 1

On Fri, Oct 12, 2018 at 2:30 PM Ryan VanderMeulen wrote: > As was noted in the bug, deciding to explicitly un-support MSVC is a > decision which merits wider discussion and is not something I wanted to > tackle in that bug. > > Has such a discussion been planned or already happened? If not, can

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

\o/ \o/ \o/ \o/ \o/ THANK YOU! On 11/2/2018 9:32 AM, Kartikaya Gupta wrote: Hello searchfox fans, Those of you working in Windows-only Rust and C++ code will probably be happy to hear that as of today searchfox is indexing the Windows-only bits of our codebase as well. The same caveat as

Re: Windows launcher process enabled by default on Nightly

On 9/28/2018 12:07 PM, Aaron Klotz wrote: On 9/27/2018 9:47 AM, Ted Mielczarek wrote: We have `MOZ_DEBUG_CHILD_PROCESS` for e10s content processes[1]. Would something similar (or maybe just supporting that?) be useful for the browser process as well? Sure, I have filed bug 1495039

Re: Windows launcher process enabled by default on Nightly

On 10/1/2018 3:21 AM, Jean-Yves Avenard wrote: Can we have something to entirely disable that new feature such as ./mach run --disable-e10s that won't make firefox spawn another process? affects development/debugging process otherwise, not everyone use Visual Studio nor WinDbg for debugging

Re: Windows launcher process enabled by default on Nightly

On 9/28/2018 12:10 PM, Ehsan Akhgari wrote: Is the --wait-for-browser flag the default in headless mode, since that mode is mostly for automation Good question. We already do that for --marionette, but not for headless. I have filed bug 1495049 to add this. Aaron

Re: Windows launcher process enabled by default on Nightly

On 9/27/2018 1:53 PM, David Teller wrote: It sounds cool, but I'm trying to understand what it means :) Do I understand correctly that the main benefit is security? In its current form, there are currently two primary security benefits that the launcher process provides: * When the

Re: Windows launcher process enabled by default on Nightly

On 9/27/2018 9:47 AM, Ted Mielczarek wrote: We have `MOZ_DEBUG_CHILD_PROCESS` for e10s content processes[1]. Would something similar (or maybe just supporting that?) be useful for the browser process as well? Sure, I have filed bug 1495039. * If you use WinDbg, you may start your

Windows launcher process enabled by default on Nightly

Hi everybody, Yesterday evening bug 1488554 [1] merged to mozilla-central, thus enabling the launcher process by default on Windows Nightly builds. This change is at the build config level. What is the launcher process? = Simply put, on Windows builds, the

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

On 9/19/2018 5:30 PM, Mike Hommey wrote: On Linux and Mac, we could make MOZ_ASSERT fork and crash in the child, and continue in the parent process. There is kind of a way to do this on Windows 8.1+ too if we wanted [1], though it obviously doesn't quite work the same way. [1]

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

On 9/17/2018 1:31 PM, Botond Ballo wrote: One potential issue here is that an assertion failure in Nightly builds might be simultaneously very annoying (because it crashes the browser of Nightly users every time it occurs) and not very actionable (because no reliable STR can be found for it).

Re: Gecko natvis file now in-tree

This is great news! Are the natvis files embedded in the PDBs, or do we have to reference them separately? On 5/9/2018 1:17 PM, Ted Mielczarek wrote: Hello, I recently landed a patch[1] that added a Gecko.natvis file[2] to the tree. natvis files[3] are Microsoft's current way of providing

Re: Uploading symbols from try builds

This is awesome, Ted, THANK YOU! \o/ -Aaron On 5/8/2018 11:37 AM, Ted Mielczarek wrote: Hello, I landed some patches yesterday[1] that have now merged to m-c to allow uploading symbols from try builds to the symbol server. Previously if you wanted to debug a try server build it involved a

Re: MinGW Target on TaskCluster

I'd like to follow up on this old thread to discuss what we can do about improving the mingw developer experience for people doing Windows-centric stuff. I've had several patches backed out over the past month because of mingw header files differing in case from the headers distributed by the

Re: Have you run 'mach bootstrap' lately?

On 5/12/2017 8:29 AM, Ryan VanderMeulen wrote: And while we're on that topic, I'll also remind people once again that for Windows MozillaBuild users, you can keep your copy of Mercurial up to date via pip! Simply run |pip install -U mercurial| and you'll have the latest version available - no

Re: FYI: We've forked the Breakpad client code

This is great news, Ted! Are you going to be creating a module for this? Who are the peers? -Aaron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Frame Pointer Omission Unconditionally Disabled on Win32

This is fantastic news! I hope this sticks! On 1/12/2017 2:12 PM, Eric Rahm wrote: As of landing bug 1322735 [1], we now unconditionally disable frame pointer omission (FPO) on all win32 builds. FPO was already disabled on nightly/aurora builds as a side-effect of having profiling enabled, but

Re: Please do not add any new CppUnitTests/GeckoCppUnitTests

What about CppUnitTests that only pull in stuff from headers and don't emit references to xul symbols? Will we still be able to create those, or is all CppUnitTest build capability going away? On 11/9/2016 12:47 PM, Benjamin Smedberg wrote: Please do not add any new CppUnitTests. With the

Re: How useful is the WinSock LSP field in crash reports?

On 7/25/2016 12:20 AM, Nicholas Nethercote wrote: I suspect it is rare for this field to be useful. (I've never found it useful.) It is also long, typically dozens of lines, and typically accounts for a quarter or more of the space taken up by the fields in the "Details" tab. I use it when

Re: Gecko shutdown (London session)

was shutdown-safe. That's one of the reasons we had to come up with nsIAsyncShutdown/AsyncShutdown.jsm. One of the not-entirely-stated goals was that once everything registered with AsyncShutdown had finished shutting down, we could call _exit(0). Cheers, David On 30/06/16 17:41, Aaron Klotz wrote

Re: Gecko shutdown (London session)

Did the now-defunct exit(0) project ever come up in this discussion? See bugs 662444 and 826143. This was a perf team project back in the Snappy days where the objective was to write important data to disk ASAP, then exit(0) without doing a bunch of cleanup. The argument for this was that,

Re: Updating 32-bit Windows users to 64-bit Windows builds?

The DLL Interceptor has some problems on 64-bit Windows 10 that we'd probably want to fix before doing this. See bug 1240977. On 5/12/2016 9:45 AM, Ted Mielczarek wrote: Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows

Re: How is libc shared object chosen in libxul?

This question is better suited to the dev-platform audience. On 4/24/2016 1:50 PM, john smith wrote: Hello, Today I installed musl C x86-64 library next to GLIBC on Linux 86-64 system. It has been installed to /usr/lib/libc.so. I didn't expect any problems with that, in fact all programs

Re: Intent to enable e10s by default when running tests locally

I know that most people aren't debugging e10s on Windows, but if you are, here's a protip (provided that you are using WinDbg): If you include the "-o" option in the debugger args, WinDbg will automatically attach itself to all child processes that are started by the chrome process. No

Re: Intent to switch to Visual Studio 2015

I'm looking forward to this! On 3/10/2016 9:14 AM, Gregory Szorc wrote: A host of new C++ features should be available after the switch. Although, we may have to drop support for VS2013 before those can be fully realized. I defer to others to determine when VS2013 will be dropped. There's

Re: Moving away from autoconf

Giggity On 2/24/2016 3:28 PM, Mike Hommey wrote: Hi, We are, officially, and starting today with the landing of bug 1250294, moving away from autoconf. This is not going to happen overnight, and it is going to be painful, but the first step has just been made, and we're not turning back. The

Re: Too many oranges!

I like the sound of your ideas and I would like to subscribe to your newsletter. On 12/22/2015 9:16 AM, Douglas Turner wrote: Mike -- totally supportive of this. I would *love* to see a release cycle completely dedicated to quality. We branch again on January 26. We could use that cycle to

Re: Faster Windows builds on Try

<3<3<3 On 11/19/2015 3:23 PM, Chris AtLee wrote: Over the past months we've been working on migrating our Windows builds from the legacy hardware machines into Amazon. I'm very happy to announce that we've wrapped up the initial work here, and all our Windows builds on Try are now happening in

Re: Intent to unship: jar: URIs from content

SGTM! On 10/15/2015 11:58 AM, Ehsan Akhgari wrote: We currently support URLs such as . This is a Firefox specific feature that no other engine implements,

Tech talk tomorrow: Windows GUI, COM, and IPC: Oh my!

In case anybody is interested: I'm going to be doing a tech talk tomorrow about the challenges of combining Windows GUI, Microsoft COM, and IPC in our code. It'll start with a history lesson on the Windows GUI, some Microsoft COM essentials, and then I'll demonstrate how these topics

Re: MOZ_RAII has landed on inbound

Can you please update https://developer.mozilla.org/en-US/docs/Using_RAII_classes_in_Mozilla with this information? Thanks, Aaron On 9/12/2015 3:06 PM, Michael Layzell wrote: Hey everyone, Bug 1201190 (https://bugzilla.mozilla.org/show_bug.cgi?id=1201190) just landed on inbound, which

Re: [feature] open certain domains into a private window

On 2015-06-24 4:27 PM, Nicholas Alexander wrote: This would be valuable, I think. We have a (new) flag for opening all links in PB mode; this should work with that. Worth filing a ticket (if there is not yet one). Nick Filed bug 1177472. ___

Re: [feature] open certain domains into a private window

I would like to see this as an addition to tab queues: having an option in the toast to choose to open the link in a private tab. On Jun 23, 2015 8:58 PM, Andreas Tolfsen a...@mozilla.com wrote: On 23 Jun 2015, at 20:24, Karl Dubost kdub...@mozilla.com wrote: Le 23 juin 2015 à 19:16, Eric

Re: Disabling the startup cache

On 6/20/2015 10:20 AM, Philip Chee wrote: Anyone want to try the same with Firefox nightly? Already did it and subsequently filed bug 873638. We can do it if we modify the encoding of the JS source at omnijar build time. I did some measurements last year at the 2014 JS workweek and it

Re: Disabling the startup cache

On 2015-06-20 9:55 PM, Mike Hommey wrote: Would encoding the js files in UTF-16 eliminate the conversion step? If so, we can easily do that at packaging time, although local builds would not benefit from that. Mike That is precisely what I had in mind.

Re: Use of 'auto'

Yeah, I like to ask myself whether I am losing any information by using auto. If it ends up eliminating redundancy within a line of code, I like to use it. OTOH if it eliminates useful human-friendly type information from the code then I don't. On 6/2/2015 2:43 PM, Martin Thomson wrote: On

Re: Treeherder UI performance much worse in Nightly vs Chrome

I just tried it (I'm still running yesterday's nightly on Windows). It looked great to me! On 4/23/2015 9:26 AM, Jared Wein wrote: How was the performance when APZ + e10s was turned on the other day? I imagine that will have a big impact on scrolling performance for treeherder since it's a

Re: Excessive inbound bustage

On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor. Is this really an issue though, given the time and effort required to earn sufficient commit access

Re: Excessive inbound bustage

On 4/21/2015 1:11 PM, Andrew Halberstadt wrote: On 21/04/15 03:02 PM, Aaron Klotz wrote: On 4/21/2015 12:50 PM, Andrew Halberstadt wrote: This could be effective, but if not implemented with care it could also be very de-motivating, especially for a well-intentioned contributor

Asynchronous Plugin Initialization is enabled by default on Aurora 39

Asynchronous initialization of NPAPI plugins is enabled by default on desktop Aurora 39. It is controlled by the dom.ipc.plugins.asyncInit pref. Since this feature is not yet 100% e10s compatible, the Aurora channel is the first time that the feature is seeing widespread deployment. Because

Re: Fwd: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images

+1. Anecdotally I've seen users on reddit who want click-to-play for flash, but specifically do not want to enable click-to-play for it because they still want to be able to see a hint of what is in the video. The poster image would allow for the best of both worlds. On 2015-02-07 4:44 AM,

Re: NS_StackWalk is totally broken on Win64

I've been thinking about NS_StackWalk and Win64 lately and I've been debating whether it would be beneficial for us to remove our dependency on dbghelp.dll in the Win64 case. Windows provides Rtl* functions to do 64-bit unwinding. I think that the work that Nathan, Luke and dmajor did in bug

Re: nsRefPtr vs RefPtr

On 5/13/14 9:25 AM, Ehsan Akhgari wrote: The chromium IPC code is ours now, so we can mdify it as needed. Not sure about the Chromium sandbox code. Also AFAIK RefPtr was first incorporated into our code base as a way to replace wtf::RefPtr for YARR but I have no evidence that it actually