Re: Project Stockwell (reducing intermittents) - March 2017 update

On Tue, Mar 07, 2017 at 06:26:28AM -0800, jma...@mozilla.com wrote: In March, we want to find a way to disable the teststhat are causing the most pain or are most likely not to be fixed, without unduly jeopardizing the chance that these bugs will be fixed. We propose: 1) all high frequency

Re: All the processes

On Tue, Mar 07, 2017 at 09:12:55AM +1100, 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

Re: All the processes

On Sat, Mar 04, 2017 at 11:15:29AM +1100, Nicholas Nethercote wrote: Hi, I want to understand all the different processes that we can and will have in Firefox. Here's a list I constructed off the top of my head. - main process - content process(es): 1 on release for most users; 2 on Nightly

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

On Wed, Feb 22, 2017 at 01:18:33PM +0200, smaug wrote: Preferences::GetBool is a slow hashtable lookup and has been showing up in performance profiles in many places. Please use Preferences::AddBoolVarCache. Same with other pref types. Or if the pref needs to be read just once, store the value

Re: Deprecating XUL in new UI

On Tue, Jan 17, 2017 at 02:51:47PM -0600, J. Ryan Stinnett wrote: I am not very familiar with the details of XUL prototype cache, but my understanding of bug 1286082[1] is that currently the XUL prototype cache is not actually working correctly (and possibly has been broken since bug 592943[2]

Re: Some recent Treeherder improvements

On Wed, Jan 04, 2017 at 01:06:25PM -0500, William Lachance wrote: * As of today, we have a completely rewritten logviewer which (among other things) has vastly improved scrolling behaviour, making it much faster to diagnose the cause of a failing job. Many thanks to Eli Perelman and Hassan

Re: Introducing mozilla::Result for better error handling

. In isolation, I might worry more about it leading to new early return errors, but in context, I think it's clearly a step in the right direction. On Wed, Dec 21, 2016 at 10:59 PM, Kris Maglione <kmagli...@mozilla.com> wrote: On Wed, Dec 21, 2016 at 10:53:45PM -0800, Eric Rahm wrote:

Re: Introducing mozilla::Result for better error handling

rm mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Firefox Add-ons Engineer Mozilla Corp

Re: File() constructor with a string argument no longer works since Firefox 52a?

See https://bugzil.la/1303518 On Wed, Nov 23, 2016 at 01:48:43PM +0800, 段垚 wrote: Hi, In Firefox 51 chrome code, this code works: `new File(path_to_file)` , if `path_to_file` exists. However in Firefox 52a (2016-11-22)，an execption is thrown: "TypeError: Not enough arguments to File". I

Re: Retrieving all bookmarks using WebExtensions API

atform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Firefox Add-ons Engineer Mozilla Corporation Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each

Re: So, what's the point of Cu.import, these days?

On Sun, Sep 25, 2016 at 12:13:41AM +0200, David Teller wrote: So, can anybody think of good reason to not do this? One major problem I see with this is that we currently lazily import most modules the first time that a symbol they export is referenced. If we move to CommonJS or ES6 modules,

Re: How badly out of date is this?

On Wed, Jun 01, 2016 at 11:23:58AM -0400, Kartikaya Gupta wrote: On Wed, Jun 1, 2016 at 10:06 AM, Mike Hoye wrote: On 2016-06-01 5:02 AM, L. David Baron wrote: So I tend to think it's worth keeping, but with a preface that clearly labels it as historical and no longer good

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Wed, Apr 20, 2016 at 10:02:47PM -0700, Kyle Huey wrote: On Wed, Apr 20, 2016 at 9:52 PM, Kris Maglione <kmagli...@mozilla.com> There isn't a strict guarantee of non-nullness for reference parameters. This is an extreme example, but technically valid: T th(*(nsresult*)0);

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 02:10:59PM +1000, Nicholas Nethercote wrote: On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione <kmagli...@mozilla.com> wrote: If we do this, can we please use |nsresult*| rather than |nsresult&|? I prefer a reference because of the guarantee of non-nullness. B

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 11:07:21AM +1000, Nicholas Nethercote wrote: Instead, we would do this: nsresult rv; T ts(rv); if (NS_FAILED(rv)) { return rv; } T* th = new T(rv); if (NS_FAILED(rv)) { delete th; return rv; } If we do this, can we please use |nsresult*| rather than

Re: Setting property on the element is no longer working on Firefox 45

On Thu, Mar 10, 2016 at 10:44:24AM -0800, Devan Shah wrote: This happens in side extension only (works fine on web standalone), i will try to extract a simple reproducible scenario. Is there any way to simulate a extension env on web? If your problem is happening in an extension, then filing

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

On Tue, Feb 02, 2016 at 01:39:00AM +0300, Dmitry Gutov wrote: On 02/02/2016 12:29 AM, Kris Maglione wrote: That falls into the category of "unless it is calling browser code and making it do something unsafe". That's too bad. I'm just reusing a querying function from there, and

Re: nsIProtocolHandler in Electrolysis?

On Mon, Jan 04, 2016 at 06:29:26PM -0800, Kris Maglione wrote: I think that doing this in an add-on is asking for trouble. I don't think I've ever seen nsIChannel implemented in JavaScript. I take that back. I see Overbite is indeed implemented this way. It still seems like asking for trouble

Re: nsIProtocolHandler in Electrolysis?

still open a modal from the parent process, but probably not without running into problems. -- Kris Maglione Firefox Add-ons Engineer Mozilla Corporation Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great complime

Re: nsIProtocolHandler in Electrolysis?

On Mon, Jan 04, 2016 at 08:27:59PM -0500, Jason Duell wrote: In the child we hand out a stub channel (HttpChannelChild) that looks and smells like an nsIHttpChannel, but actually uses IPDL (our C++ cross-platform messaging language) to essentially shunt all the real work to the parent. When

Re: ESLint is now available in the entire tree

On Fri, Nov 27, 2015 at 02:53:35PM -0800, Dave Townsend wrote: Going forwards we'd like to enable it in more directories and turn on more rules. You can help! If there is a directory you work in a lot try removing it from the top-level .eslintignore file and see what fails, then fix it. Mostly

Re: Startup cache and resource:// urls

On Tue, Nov 24, 2015 at 02:22:44PM +0900, Mike Hommey wrote: Note the startup cache only matters on the first startup for a given build, and that might be a reason why we fail to track its performance impact. Presumably also when we flush the startup cache for changes in add-ons? Most

Re: Startup cache and resource:// urls

On Tue, Nov 24, 2015 at 04:08:56PM +0900, Mike Hommey wrote: ... which seems to be a *very* old thing because: - resource://app might have pointed to the plain Firefox directory where you could find the omnijar a long time ago (I don't remember if that ever was actually true), but it points

Re: Where can i download firefox-sdk

't use it for anything that requires running in the same address space as Firefox. Even if that remains possible for the foreseeable future (hopefully it won't), I can more or less guarantee you it won't be accepted if you submit your add-on for signing. -- Kris Maglione Firefox Add-ons Engineer M

<    1   2   3