Re: XULRunner future and ownership

I'm not sure why that page links to the nightly builds but the release versions are here: http://archive.mozilla.org/pub/firefox/releases/ Note that Firefox 45 hasn't been released yet so the latest SDK is for one of the beta versions. On Wed, Feb 10, 2016 at 7:21 AM, Devan Shah

Re: XULRunner future and ownership

On Wednesday, July 29, 2015 at 2:30:54 PM UTC-4, Benjamin Smedberg wrote: > The Mozilla project no longer sees XULRunner as a priority project. It's > not core to advancing the open web or any of our current or planned > products. > > As Ben Hearsum noted a couple weeks ago, we are turning off

Re: Memory Usage on Perfherder & Memory Reduction

Incidentally, the automatic regression detection dashboard has been coming together recently with Perfherder, which should let you track such things as this much more easily (as well as providing a convenient interface for filing bugs). For example, you can see all recently detected

Re: XULRunner future and ownership

On Wed, Feb 10, 2016 at 8:39 AM, Devan Shah wrote: > On Wednesday, February 10, 2016 at 10:43:44 AM UTC-5, Dave Townsend wrote: >> I'm not sure why that page links to the nightly builds but the release >> versions are here: http://archive.mozilla.org/pub/firefox/releases/

Re: XULRunner future and ownership

On Wednesday, February 10, 2016 at 10:43:44 AM UTC-5, Dave Townsend wrote: > I'm not sure why that page links to the nightly builds but the release > versions are here: http://archive.mozilla.org/pub/firefox/releases/ > > Note that Firefox 45 hasn't been released yet so the latest SDK is for >

Re: XULRunner future and ownership

On Wednesday, February 10, 2016 at 11:48:24 AM UTC-5, Dave Townsend wrote: > On Wed, Feb 10, 2016 at 8:39 AM, Devan Shah wrote: > > On Wednesday, February 10, 2016 at 10:43:44 AM UTC-5, Dave Townsend wrote: > >> I'm not sure why that page links to the nightly builds but

Using rr chaos mode to find intermittent bugs

Background: http://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html I just landed on rr master support for a "-h" option which enables a chaos mode for rr recording. This is designed to help reproduce intermittent test failures under rr. We already have a few reports of people using

Re: Using rr chaos mode to find intermittent bugs

On Thu, Feb 11, 2016 at 9:32 AM, Ted Mielczarek wrote: > BenWa tried doing some work on this but kept getting hung up > on hitting test failures unrelated to the ones we see in production, possibly due to environment issues. > Yes. In this vein, it's possible that in some

Re: Using rr chaos mode to find intermittent bugs

On Wed, Feb 10, 2016, at 03:04 PM, Robert O'Callahan wrote: > Background: > http://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html > > I just landed on rr master support for a "-h" option which enables a > chaos > mode for rr recording. This is designed to help reproduce

Re: Using rr chaos mode to find intermittent bugs

On 2016/02/11 5:47, Robert O'Callahan wrote: On Thu, Feb 11, 2016 at 9:32 AM, Ted Mielczarek wrote: BenWa tried doing some work on this but kept getting hung up on hitting test failures unrelated to the ones we see in production, possibly due to environment issues. Yes.

Re: Using rr chaos mode to find intermittent bugs

rr should work fine with c-c xpcshell tests (and most other Linux programs). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Using rr chaos mode to find intermittent bugs

On 2016/02/11 7:04, Robert O'Callahan wrote: rr should work fine with c-c xpcshell tests (and most other Linux programs). This sounds great! CI ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: nsIDOMWindow is deprecated now is there an alternative?

Are you using it from JS or C++? If you're using it from JS, nothing has changed. - Kyle On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah wrote: > Hello > > nsIDOMWindow is deprecated now according to: >

Re: nsIDOMWindow is deprecated now is there an alternative?

Ok ... ignoring the question of how you're using it from C++ since binary addons are gone, many of the methods on nsIDOMWindow moved to nsPIDOMWindow and then to nsPIDOMWindowInner/Outer, depending on what version of Gecko you're using. Today on trunk nsIPromptFactory takes a mozIDOMWindowProxy,

nsIDOMWindow is deprecated now is there an alternative?

Hello nsIDOMWindow is deprecated now according to: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow is there an alternative for this interface. I am using a lot of functions from this interface and also using nsIPromptFactory which relies on

Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

TL;DR - Firefox does pretty well when compared to Chrome. The Presto project is a Mozilla platform initiative that intends to look into any performance differences between Firefox and other UserAgents in order to highlight areas that we should look into improving and to clear any prejudice that

Suggesting new name for nsIDOMEvent::GetInternalNSEvent

In Bug 1235830 , I'm going to rename this method to something more meaningful. I need suggestion about what the name should be. Summary of the discussion so far: * WidgetEvent() can't be used, since it's also the name of a type. *

Re: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

I tend to use the WidgetEventPtr() or WidgetEventRef() for situations where I need a decorator to avoid colliding with the type name. Maybe try that? bholley On Wed, Feb 10, 2016 at 8:57 PM, Aidin Gharibnavaz wrote: > In Bug 1235830

Re: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

IMO, As* generally implies a cast between two different types for the same underlying object, or at least a reflexive conversion between two different "view" (for some fuzzy definition of that). Even in cases where we have two objects with a 1-to-1 correspondence, As* feels inappropriate to me.

Re: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

What's wrong with AsWidgetEvent? We do AsFoo a fair bit. - Kyle On Feb 10, 2016 8:58 PM, "Aidin Gharibnavaz" wrote: > In Bug 1235830 , I'm > going to rename this method to something more meaningful. I need suggestion >

Re: To bump mochitest's timeout from 45 seconds to 90 seconds

On 09/02/16 19:51, Marco Bonardo wrote: On Tue, Feb 9, 2016 at 6:54 PM, Ryan VanderMeulen wrote: I'd have a much easier time accepting that argument if my experience didn't tell me that nearly every single "Test took longer than expected" or "Test timed out" intermittent

Re: To bump mochitest's timeout from 45 seconds to 90 seconds

On Wed, Feb 10, 2016 at 10:30 AM, James Graham wrote: > FWIW I think it's closer to the truth to say that these tests are not set > up to be performance regression tests > Right, but this was just one of the aspects that was pointed out. I think the performance analysis

Re: MozReview/Autoland in degraded state

And autoland to inbound is now enabled as well. On Tue, Feb 9, 2016 at 11:40 AM, Daniel Minor wrote: > Try integration is now restored. > > Autoland to inbound will be available pending some further testing. > > On Fri, Feb 5, 2016 at 5:34 PM, Gregory Szorc

Re: nsIDOMWindow is deprecated now is there an alternative?

Yes, you need to QueryInterface between nsIDOMWindow and nsPIDOMWindow. What are you actually doing with the Firefox SDK? - Kyle On Wed, Feb 10, 2016 at 5:03 PM, Devan Shah wrote: > I tried to use nsPIDOMWindow, but issues is that functions like: > > Function

Re: nsIDOMWindow is deprecated now is there an alternative?

Right, that will work, although you could nsCOMPtr to make it a lot prettier: void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow) { nsCOMPtr window = do_QueryInterface(aDOMWindow); nsCOMPtr docShell; if (window) window->GetDocShell(getter_AddRefs(docShell)); nsIWebShell*

Re: nsIDOMWindow is deprecated now is there an alternative?

Yeah, Firefox 41 and later don't support binary XPCOM components in extensions. ctypes is still supported and so are binary plugins. On Wed, Feb 10, 2016 at 5:12 PM, Kyle Huey wrote: > Ok. I thought we killed binary components in extensions ... > > There will be a lot of

Re: nsIDOMWindow is deprecated now is there an alternative?

Yeah, ok, nsPIDOMWindow then. - Kyle On Wed, Feb 10, 2016 at 4:49 PM, Devan Shah wrote: > Version 45, I am using the SDK from > https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip. > Which I still see the nsIPromptFactory has > > /*

Re: nsIDOMWindow is deprecated now is there an alternative?

Ok. I thought we killed binary components in extensions ... There will be a lot of changes around windows and their XPIDL interfaces in Gecko over the next while so you should expect to have to update this code fairly frequently if you're actually calling methods on nsIDOMWindow. - Kyle On

Re: nsIDOMWindow is deprecated now is there an alternative?

Alright, just QueryInterface between nsIDOMWindow and nsPIDOMWindow when you have one and need the other and you should be fine. - Kyle On Wed, Feb 10, 2016 at 5:15 PM, Devan Shah wrote: > Currently I just want to get it up and running again on FF 45 again, with > out

Re: nsIDOMWindow is deprecated now is there an alternative?

You get the nsIDOMWindow, and then QueryInterface to nsPIDOMWindow to call GetTop on it. - Kyle On Wed, Feb 10, 2016 at 5:35 PM, Devan Shah wrote: > In the below code i use aWebProgress to and then GetDOMWindow on that, > however GetDOMWindow only allows nsIDOMWindow,