Re: Code Review Session

Sounds like we're talking about code review. But I want to qualify integration into bugzilla: I explicitly do not want a tool that is tightly coupled to bugzilla. In fact, I want a tool that has as little to do with bugzilla as feasible. I'm a contributor to the Review Board project[1],

Re: Poll: What do you need in MXR/DXR?

I love DXR for mozilla-central, and would love it if the UX branch (https://mxr.mozilla.org/projects-central/source/ux/) was indexed there as well! Keep up the great work, -Mike On 02/10/2013 3:33 PM, Erik Rose wrote: What features do you most use in MXR and DXR? Over in the recently

Re: Recommendations on source control and code review

SmartBear's tools, of course.) Mozillian Mike Conley reviewed SmartBear's study on his blog [2]. The results are interesting and actionable. Some highlights: * Review fewer than 200-400 lines of code at a time. * Spend no more than 60-90 minutes per review session. * Authors should pre-review

Re: Update on sheriff-assisted checkin-needed bugs

I try to mentor as many bugs as possible. My ideal workflow would be to grant r+, suggest a try: string, and set checkin-needed in a single act, without having to determine whether the contributor has try access and/or editbugs. If we already have people scanning for checkin-needed and looking

Re: e10s startup?

At least for xul:browser where remote=true, we behave as you describe; namely, we use the remote-browser binding defined in toolkit/content/widgets/remote-browser.xml, which on construction, injects a browser-child.js frame script via the message manager. On 29/07/2014 4:58 AM, Neil wrote: How

Re: Press Me! Button

A quick scan through DXR doesn't show any reference to Press Me! or Press Me in our strings, except for a likely coincidental match in some accessibility test[1]. Can you show us a screenshot of this button? [1]:

Re: How to use review-board to post a set of changes?

Hey Yonggang, Your best bet is push your changesets to the MozReview repo - it'll do the job of creating your review requests for you. There is a little bit of setup involved in order to make it possible, however - you need to install a Mercurial extension, and you need to configure Mercurial so

Cleopatra can take larger profiles now.

Good news everybody! TL;DR: Cleopatra used to have a limitation where it would only accept profiles of around 10MB. We've now made it so that Cleopatra can accept much, much larger profiles. This is going to become increasingly important as more profile-able processes get added. As an added

Re: Is there an e10s plan for multiple content processes?

not going to ship The Spinner Experience, because shipping it as-is is beyond ill-advised. :D -Mike On 05/05/2015 10:49 AM, Ehsan Akhgari wrote: On 2015-05-05 10:30 AM, Mike Conley wrote: The e10s team is currently only focused on getting things to work with a single content process at this time. We

Re: Is there an e10s plan for multiple content processes?

Funny folks should bring this up - I recently wrote a blog post about this: http://mikeconley.ca/blog/2015/05/04/electrolysis-and-the-big-tab-spinner-of-doom/ Funny how things cluster. :) I suggest reading that top to bottom before you continue reading this post. ... Welcome back! :D The e10s

Re: Is there an e10s plan for multiple content processes?

ship-worthy instead of resorting to heroics to get processCount=1 ship-worthy? On Tue, May 5, 2015 at 10:41 AM, Mike Conley mcon...@mozilla.com mailto:mcon...@mozilla.com wrote: Is there a more detailed description of what the issues with multiple content processes are that e10s itself

Re: Shutdown hangs are very common

Should fixing shutdown hangs be higher priority? Starting and shutting down properly (and quickly), IMO, fall into the core quality / no compromise / we have to get this right bucket. So making it higher priority sounds aligned with the Three Pillars. And if so, should we allow features with

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

I suspect that knowing what things were passed into a method or function is something that can be divined via static analysis. Aren't there tools for our (admittedly varied) editors / IDEs to make the readability that people are getting from aFoo readily available, but that don't also require us

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

56 PM, Ehsan Akhgari wrote: > On 2015-10-16 12:16 PM, Justin Dolske wrote: >> On 10/16/15 7:20 AM, Ehsan Akhgari wrote: >>> On 2015-10-15 5:00 PM, Mike Conley wrote: >>>> Note that this should not affect Gecko’s behaviour when the is >>>> displayed “inline”

Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

Hey dev-platform, TL;DR: I want Gecko to stop firing events on ’s on dropdowns. Context: Bug 1090602 was filed way back in the day by someone who used the old Treestatus app, because they noticed it was broken once e10s was flipped on by default. The problem was that the old Treestatus app

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

that all browsers seem to fire events for mouseover, mousedown, keyup, keydown, etc. It's only the dropdown case that seems to be special for each browser - likely due to the fact that the spec is vague for that case. On 2015-10-16 10:20 AM, Ehsan Akhgari wrote: > On 2015-10-15 5:00 PM, Mike

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

rhaps I'll work with you to hammer out that part of the spec. On 2015-10-16 4:12 AM, Anne van Kesteren wrote: > On Thu, Oct 15, 2015 at 11:00 PM, Mike Conley <mcon...@mozilla.com> wrote: >> Are there any objections or thoughts about this plan? > > You should check what the

Intent to unship: dialog=1 for window.open from web content

One of the arguments to window.open[1] is a “feature string” that is used to do things like set the size of the newly opened window, to set whether or not it is resizable, etc. Gecko currently supports a “dialog” feature that is really only evident on Windows platforms. This dialog feature

Re: Is there any events before loading a URL to a docshell.

Hey Yonggang, You might find nsIWebProgressListener useful: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWebProgressListener Specifically the onLocationChange method. This is fired once we've determined that we're going to load a new URI for a DOM Window.

dialog=1 for window.open from content

Hello dev-platform, I'm currently working on bug 1095236 - that's an e10s bug for us failing to open any windows if the features string includes dialog=1 (or dialog=yes). According to [1], setting dialog=1 makes a popup window that removes the min/max/restore buttons, and no "command" menu (the

Re: dialog=1 for window.open from content

Unfortunately, it looks like the kind of counter I would need is not yet supported[1]. Even if some bank in the world is using dialog=1, what does it give them? It doesn't change the behaviour of the window like showModalDialog (which runs in a nested event loop), it just changes the buttons

Re: SPS Profiles are now captured for entire subprocess lifetime

es was a prerequisite for being able to do that. > > On Thu, Dec 3, 2015 at 4:52 PM, Mike Conley <mcon...@mozilla.com> wrote: > > Just a heads up that there have been recent developments with regards to > > gathering SPS profiles from multiple processes. > > > > B

SPS Profiles are now captured for entire subprocess lifetime

Just a heads up that there have been recent developments with regards to gathering SPS profiles from multiple processes. Bug 1103094[1] recently landed in mozilla-central, which makes it so that if a subprocess starts up _after_ profiling has already been started in the parent, then the

Re: Too many oranges!

I would support scheduled time[1] to do maintenance[2] and help improve our developer tooling and documentation. I'm less sure how to integrate such a thing in practice. [1]: A day, a week, heck maybe even a release cycle [2]: Where maintenance is fixing oranges, closing out papercuts,

Re: Too many oranges!

fixing tests, > bug triaging, no feature development at all). > > Thoughts? > > On Tue, Dec 22, 2015 at 7:41 AM Mike Conley <mcon...@mozilla.com > <mailto:mcon...@mozilla.com>> wrote: > > I would support scheduled time[1] to do maintenance[2] and help >

Re: Faster Windows builds on Try

This is the greatest! Thank you so much! On 19/11/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

Re: Top crash list is odd right now

I reviewed the patch. Currently, the feature is only enabled on Nightly, Aurora and Beta. We originally wanted the beta unsubmitted crashes due to the content process crashes we were getting there with e10s that we didn't understand. Now that we have a better handle on those content process

PSA - With e10s enabled, initial browser in new windows will soon be remote by default

If you don’t write tests that open browser windows or work on the front-end of Firefox, you can probably ignore this. The initial browser in browser.xul is non-remote by default. This means that as soon as it browses to some URL that can be loaded in the content process (about:home, for

Re: Just Autoland It

I respect everybody talking in this thread a great deal, but I thought I might gently suggest that folks exercise a bit of empathy for what the MozReview team[1] are trying to accomplish, and how difficult that work actually is. Trying to build a tool that satisfies such a wide spectrum of

Re: Just Autoland It

erdiffs are sometimes wrong", which is clearly something to fix ASAP On 29/01/2016 11:18 AM, Boris Zbarsky wrote: > On 1/29/16 10:42 AM, Mike Conley wrote: >> most of the feedback is via negativa[2] > > That's definitely no good, I agree. > > Attacking the MozReview team is a

Re: Unsafe CPOWs are about to be outlawed in browser code

The spaghetti was put in the machine last night - this work has now landed on mozilla-central. If you start seeing "unsafe CPOW usage forbidden" in the Browser Console for various things, please mark them blocking bug 1233497. Thanks all, -Mike On 20/01/2016 3:54 PM, Mike Co

Re: Just Autoland It

I should point out that these interdiff issues are being actively worked on. At least one of them, bug 1238000[1], already has a patch that's under review to land in core[2]. Just be sure to file them. Having talked to the MozReview team about these types of bugs, I do know that trust-worthiness

Re: Proposed changes to Talos (performance) alerting

>> >> As Joel mentioned, it's pretty easy to schedule profiling runs for talos >> using trychooser. Scheduling a profiling run as part of the >> regression-filing process is something we could consider doing, if >> there's a broad consensus it would be useful (I'm always wary of putting >> extra

Unsafe CPOWs are about to be outlawed in browser code

(cross-posted to both dev-platform and firefox-dev) TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost all browser code. Unsafe CPOWs inside add-on scopes should continue to work properly. If you start seeing "unsafe CPOW usage forbidden” errors being throw for a feature

Re: Just Autoland It

FWIW, adding r- abilities is bug 1197879[1]. There's a prototype patch that adds the UI, but I believe the MozReview team was still trying to sort out the best terminology to use. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1197879 On 26/01/2016 10:46 AM, Benjamin Smedberg wrote: > > >

Re: pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

This is great, thank you! On 19/05/2016 7:09 PM, Matthew N. wrote: > Hello, > > One of the reasons developers have been avoiding pushPrefEnv compared to > the synchronous set*Pref (with a registerCleanupFunction) is because > pushPrefEnv required using a callback function to wait for the >

On using MozAfterPaint properly

Hello dev-platform, TL;DR: MozAfterPaint and nsIDOMWindowUtils has been given some extra stuff to make it easier to be sure that something you care about has been painted. This is good, at the very least, for Talos tests. Full-details: I've recently made a change to MozAfterPaint that some of

Re: PSA: Cancel your old Try pushes

If I had to guess, I'd say that it's just consuming more and more memory as more and more nodes are getting added to the DOM, and more AngularJS stuff gets instantiated. I would put good money on those multi-second pauses being attempts to GC / CC On 16 April 2016 at 05:50, Gijs Kruitbosch

Re: Moving XP to ESR?

The people on this thread might find chutten's recent blog post interesting: https://chuttenblog.wordpress.com/2016/04/19/firefoxs-windows-xp-users-upgrade-path/ Juicy chunk: "Between 40% and 53% of Firefox users running Windows XP are Stuck" -Mike On 18/04/2016 9:04 AM, Henri Sivonen wrote: >

Re: How to measure performance impact of l10n on UI

Is the firstPaint timestamp in nsIAppStartup's getStartupInfo[1] not sufficient? It's apparently recording the time that firstPaint occurred. I think you're already aware of this, but I'm in the process of modifying ts_paint to record the delta between the firstPaint timestamp and the process

Re: PSA - With e10s enabled, initial browser in new windows will soon be remote by default

p. > > Thanks. > > Ben > > On Mon, Jul 25, 2016 at 10:29 AM, Mike Conley <mcon...@mozilla.com> wrote: > >> After much toil, this has finally landed on central. Hopefully it sticks. >> >> Big thanks to all of my reviewers - especially smaug, who reviewed

Re: PSA - With e10s enabled, initial browser in new windows will soon be remote by default

After much toil, this has finally landed on central. Hopefully it sticks. Big thanks to all of my reviewers - especially smaug, who reviewed the bulk of the weirder stuff. -Mike On 9 June 2016 at 14:21, Mike Conley <mcon...@mozilla.com> wrote: > If you don’t write tests that ope

Re: How to measure performance impact of l10n on UI

me to the test you've written so far? That might help me to better understand what you're attempting to measure and how you're going about it. -Mike On 22/07/2016 8:47 PM, zbranie...@mozilla.com wrote: > On Friday, July 22, 2016 at 6:53:45 AM UTC-7, Mike Conley wrote: >> Is the fi

Re: Increased number of e10s related crashes for firefox-ui-tests on mozilla-central and integration branches

Might be unexpected fallout from bug 1261842 which landed on central on Monday (July 25th). Does that correspond to your timeline of when this started showing up? I'm seeing this in the log for at least one of these: "JavaScript error: chrome://marionette/content/listener.js, line 1017:

Re: Content process launch time distribution

> Also, is there a way to get numbers for the >> time from process launch to the point when we start loading the first URL I think there is. There's this "startup timeline" stuff that we record timestamps for:

Re: Project Stockwell - February 2017 update

There's good feedback in here. Are some of these known, jmaher? Are any intentional choices, or should we just start turning these into bugs to get fixed? On 08/02/2017 12:33 AM, Bill McCloskey wrote: > Hi Joel, > I spent about an hour tonight trying to debug a test failure, and I'm > writing

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

> I would expect not, though, since we are >> still rolling it out to the full population. I do believe the plan is to enable e10s on 52 ESR, but with the Firefox 50 restrictions (e10s enabled by default, disabled if a11y APIs used, disabled if non-WebExtension, non-mpc=true add-ons enabled).

Re: Intent to make Form Autocomplete popups use richlistbox's instead of trees

ike, > > I'm not much into that topic, though I'm wondering why you don't try to > switch to HTML already as the DevTools team started to do[1] recently. > > Sebastian > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1263750 > > On 19 August 2016 at 17:25, Mi

Intent to make Form Autocomplete popups use richlistbox's instead of trees

(Cross-posted to dev-platform and firefox-dev) Hey folks, If you don't work on front-endy things, you can safely ignore this. Summary says it all. See https://bugzilla.mozilla.org/show_bug.cgi?id=1296638 for details and rationale. I have a working version of this on my local machine, and will

Re: Requesting Help

Hi Amila! Welcome! We can absolutely help you out. There are a _lot_ of things going on that you can contribute to, depending on your current skillset, and also depending on what skills you'd like to grow. jdm wrote a tool to let you know about some of the things you might want to contribute

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

Yes, thank you Kan-Ru! On Aug 27, 2016 2:10 PM, "Nick Fitzgerald" wrote: > Thanks Kan-Ru! I've personally tried to include the header with the wrong > case multiple times, so I appreciate this change a lot. > > On Fri, Aug 26, 2016 at 7:54 PM, Kan-Ru Chen

Re: PSA: The return type of IPDL Recv* methods changed from bool to mozilla::ipc::IPCResult

This is _fantastic_. Thank you Kanru! On 16/11/2016 9:57 AM, Kan-Ru Chen wrote: > Hello, > > In bug 1314254 the return type of IPDL Recv* methods was changed from > bool to mozilla::ipc::IPCResult in order to make crash reports to have > better stack information. There are now three choices to

Re: Intent to make Form Autocomplete popups use richlistbox's instead of trees

<gijskruitbo...@gmail.com> wrote: > On 19/08/2016 16:25, Mike Conley wrote: > >> Summary says it all. See >> https://bugzilla.mozilla.org/show_bug.cgi?id=1296638 for details and >> rationale. >> >> I have a working version of this on my local machine, and

window.find dialog feature broken in Firefox 53 (a.k.a., Late Intent to Unship: window.find's dialog support)

Hello release-drivers (with dev-platform cc'd), TL;DR: The non-standard window.find feature[1] has, historically, been able to open up a dialog for the user to enter more strings to find on the page[2]. It turns out that the dialog portion of that API has been broken for all users with e10s

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

Incidentally, MozReview now allows you to provide feedback on the commit message in the diffviewer. On Mar 9, 2017 2:47 PM, "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

Re: Firefox startup code coverage (ts_paint talos test)

This is great, thanks so much Marco! This will likely be a useful way for us to find more opportunities to make start-up faster. Thanks for your work! On 2017-08-02 10:28 AM, Marco Castelluccio wrote: > Hello all, > at https://marco-c.github.io/ts_paint_startup_coverage_report/ you can > find a

Re: Quantum Flow Engineering Newsletter #18

> > Mike Conley ported scrollbox to use smooth scrolling instead of JS driven > scrolling <https://bugzilla.mozilla.org/show_bug.cgi?id=1356705>. This > affects most importantly scrolling the tab bar, and should make it more > smooth by removing a lot of slow code that used t

Re: Gecko Profiler Win64 stability

Tremendous work here. Thank you so much, dmajor! On 2017-05-18 3:04 PM, David Major wrote: > Hi, > > The Gecko Profiler used to be notoriously unstable on 64-bit Windows. > (If you're curious: it's mostly because the unwinding rules for Win64 > require the system libraries to do a lot of

The Joy of Profiling

(cross-posted between dev-platform and firefox-dev - please send responses to the dev-platform list). TL;DR: New show on AirMo - Joy of Profiling, examining Profiles: https://air.mozilla.org/search/?q=the+joy+of+profiling . Want your profile up on the show? Submit it via

Re: Quantum Flow Engineering Newsletter #25

t;> Another super important goal of mine was to give credit where it's due. >> What we have accomplished for Quantum Flow (and Firefox 57) so far >> couldn't >> have been accomplished without the help of many wonderful people in the >> community.  I often think that we need to ta

TabChild visibility

Hello dev-platform, TL;DR: TabChild's don't seem to care about the nsIBaseWindow visibility attribute that they implement. In fact, they often lie about it. What should we do about that? What's the best way to detect and tell the TabChild that it's visible or invisible? Also, what's the

Re: Proposal: Unified Bootstrap Stages for Gecko

Hey gandalf, Using WICG for browser start-up makes sense to me. We should also consider adding a milestone for the "hero element" for the browser. There's some discussion fragments in bug 1369417 about this (which I see you're already involved in! Great!), captured from a very caffeinated

Re: --verify option added to mochitest, reftest, xpcshell test harnesses

This is super cool! Thanks Geoffrey! On 2017-10-02 1:08 PM, Geoffrey Brown wrote: > The mochitest, reftest, and xpcshell test harnesses now support a > --verify option. For example: > > mach mochitest > docshell/test/test_anchor_scroll_after_document_open.html --verify > > In verify mode, the

Photon Engineering Newsletter #14

(via https://mikeconley.ca/blog/2017/08/24/photon-engineering-newsletter-14/ - I suggest visiting that post directly if you want to see the animated GIFs inline) Just like jaws did last week , I'm taking over for dolske

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

This all sounds great! >> 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Intent to move Activity Stream into its own process

(posted on both dev-platform and firefox-dev. Please send replies to dev-platform) Hello all, Just sending a quick note to let you know that I've filed bug 1469072[1] to move Activity Stream into its own content process. This is something that Fission needs, but we're hoping to squeeze some

Re: Intent to move Activity Stream into its own process

> > I am not sure about the specific AS work here, but for the general case, I > believe that Fission intends to cause a process switch anytime a tab > navigates to an unrelated origin, so this will also increase the frequency > of process switching. > Yep, this matches my understanding: we're

Re: Intent to move Activity Stream into its own process

nse of how this is going to be implemented? Is there going > to be specialized code for this, or is it going to be handled by all the > general navigation changes for process-switching when you change sites? > > Alex > > On Mon, Jun 18, 2018 at 5:02 PM Mike Conley wrote: > >&

Re: PSA: nsISimpleEnumerator now works as a JS iterator

Wow, this is a great improvement! Thank you! On Thu, Aug 23, 2018, 6:26 PM Kris Maglione wrote: > Oh, and from C++, there's also now a range iterator wrapper with > similar semantics: > > for (auto& docShell : SimpleEnumerator(docShellEnum)) { > ... > } > > On Thu, Aug 23, 2018 at

Re: Hey! Can you please briefly try this test build...

Solid tip from Xidorn. For the lazy, that command is: ./mach mozregression --launch b5a512aaef49 --repo try On 2018-04-20 9:53 AM, Xidorn Quan wrote: > FWIW, I always find that the easiest way to run some build is using > mozregression's "Run a single build", which would take care of

Re: CPU core count game!

Thanks for drawing attention to this, sfink. This is likely to become more important as we continue to scale up our parallelization with content processes and threads. On 21 March 2018 at 14:54, Steve Fink wrote: > Just to drive home a point, let's play a game. > > First,

Re: CPOWs are now almost completely disabled

This is great news! Thanks to everybody involved! On Thu, 28 Jun 2018 at 09:16, Alex Gaynor wrote: > Outstanding! I love a good IPC attack surface reduction! > > Alex > > On Wed, Jun 27, 2018 at 6:54 PM Tom Schuster wrote: > > > Since landing bug 1465911 [1], CPOWs [2] are only functional on

Re: A tool to put Phabricator and Bugzilla count into your browser toolbar

ues/3 to add a "working hours" feature so that you can disable the count outside of those hours. -Mike On Wed, 17 Oct 2018 at 10:09, Mike Conley wrote: > Hi folks, > > I wrote a WebExtension to put your total review count (Phabricator + > Bugzilla) into your browser UI. > &

Re: A tool to put Phabricator and Bugzilla count into your browser toolbar

I'm all for it. Tracking in this issue: https://github.com/mikeconley/myqonly/issues/5 On 2018-10-17 12:38 p.m., Nicholas Alexander wrote: > Mike, > > On Wed, Oct 17, 2018 at 7:09 AM Mike Conley <mailto:mcon...@mozilla.com>> wrote: > > Hi folks, > > I wr

A tool to put Phabricator and Bugzilla count into your browser toolbar

Hi folks, I wrote a WebExtension to put your total review count (Phabricator + Bugzilla) into your browser UI. So if you've ever wanted your review queue to haunt you while you surf the web, you can have that now. Here it is: https://addons.mozilla.org/en-US/firefox/addon/myqonly/ The

Re: Please enable build system telemetry

Yes, thanks! Out of curiosity, is there a dashboard somewhere where we can see aggregates of the current measurements? Thanks for your work, -Mike On Fri, Nov 9, 2018, 3:22 PM Doug Thayer Hooray for data! This is great. Thank you! > > On Fri, Nov 9, 2018 at 11:55 AM Ted Mielczarek wrote: > >

Re: Process Priority Manager enabled on Nightly for Windows (only)

Hi itielandrh, Is tab warming taken into account, so that when hovering a background tab, > its process priority will go back to normal? > Yes, this was addressed in this bug by dthayer. Love seeing your work Mike! > I'm glad this excites

Re: Process Priority Manager enabled on Nightly for Windows (only)

> > On 29/01/2019 19:32, Mike Conley wrote: > > (cross-posted to dev-platform and firefox-dev) > > > > Hi folks, > > > > Just a heads up that in bug 1476981 > > <https://bugzilla.mozilla.org/show_bug.cgi?id=1476981>, I just > > autolanded a patch

Process Priority Manager enabled on Nightly for Windows (only)

(cross-posted to dev-platform and firefox-dev) Hi folks, Just a heads up that in bug 1476981 , I just autolanded a patch that, when hopefully merged, will enable the Process Priority Manager for Firefox Desktop on Nightly on Windows. The

Re: Process Priority Manager enabled on Nightly for Windows (only)

, it might be better to be safe than sorry, and mark any background tabs that are playing media as "active" - I'll file a bug.) -Mike On 2019-01-30 11:24 a.m., Valentin Gosu wrote: > On Tue, 29 Jan 2019 at 20:33, Mike Conley <mailto:mcon...@mozilla.com>> wrote: > > (

Re: Process Priority Manager enabled on Nightly for Windows (only)

I filed bug 1523974 to track this class of problem. On 2019-01-30 11:44 a.m., Gabriele Svelto wrote: > On 30/01/19 17:26, Mike Conley wrote: >> That's a good question. I haven't yet noticed any difference yet, but >> I'm hoping people can keep an eye out to see if there's apprecia

Re: Announcing ./mach busted

\o/ Thank you for this! On 2019-04-11 12:11 p.m., Bobby Holley wrote: > 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

User-Initiated Picture-in-Picture enabled on Windows, Nightly only for now

(cross-posted to firefox-dev and dev-platform - please send public replies to the firefox-dev thread) Hello all, Just a heads up that in bug 1527925 , I've enabled User-Initiated Picture-in-Picture by default on Windows, Nightly-only for now.

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

Hey folks, For Desktop, I don't believe there are any normal conditions under which our users will have e10s disabled. [1] is where the decision gets made, and it looks like these days, the only thing that will disable e10s is if the user sets `browser.tabs.remote.autostart` to false themselves,

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

Just a quick follow-up - yzen got back to me - here's the bug that tracked disabling e10s in Firefox 60 for older screen readers: https://bugzilla.mozilla.org/show_bug.cgi?id=1489605 On Tue, 23 Apr 2019 at 16:30, Mike Conley wrote: > Hey folks, > > For Desktop, I don't believe ther

Re: Using MozPhab without Arcanist

This is great, thank you zalun! moz-phab has improved by leaps and bounds over the last few months. Great job to you and the team hacking on it - it's a critical part of my toolset. On Tue, 22 Oct 2019 at 11:26, Piotr Zalewa wrote: > Hi all, > > Since today MozPhab does not require Arcanist to

Re: Experimenting with JavaScript type safety in mozilla-central

This is a great thing to start looking into. I myself have definitely been burned in the past because something unexpected got coerced into something equally unexpected, resulting in behaviour that is without-a-doubt unexpected. So thanks to the folks getting this off the ground! On Mon, 7 Oct

Re: PSA: Dispatching background tasks just got easier!

Ahh this is great, and so refreshing. I'm so happy we're starting to bring some order to our threading situation! Thanks so much to you and your team! On Mon, 16 Dec 2019 at 11:51, Kristen Wright wrote: > Hello! > Now that Bug 1584568 just landed I wanted to >

Re: Faster compilers available in bootstrap

Yes, this is wonderful, thank you so much! Improvements to build times are a force-multiplier. 5%-15% improvements in our build times is no joke! On Thu, 9 Apr 2020 at 13:09, Botond Ballo wrote: > Thanks, compile time improvements are always good news! > > Out of curiosity, does this impact

Re: Intent to ship: -less RDM

Thanks Micah, and everybody else who's been working on this! As someone who's had to struggle at times with the special tunneling and frameloader swapping that we do for the moziframe stuff for RDM, this is a very very welcome change, and will allow us to get rid of some pretty confusing front-end

Re: Improvement to build times through cleanup of C++ include dependencies

Thank you so much for investing time and effort into this area! Improvements to build times are always always welcome. I seem to recall we collect opt-in Telemetry on things like build times. If so, have we noticed any changes in those graphs? -Mike On Mon, 14 Dec 2020 at 11:11, Botond Ballo

Re: PSA (Windows): Startup Skeleton UI Enabled on Nightly

dthayer, Congratulations to you and emalysz for getting this enabled in Nightly! I know it's been a long slog, but I think this is going to make a very perceivable improvement to our startup responsiveness. -Mike On Thu, 7 Jan 2021 at 07:20, Sebastian Zartner wrote: > On Wednesday, January 6,