Re: Using rr chaos mode to find intermittent bugs

On Fri, Feb 12, 2016 at 8:39 AM, Kyle Huey wrote: > On Thu, Feb 11, 2016 at 11:35 AM, Robert O'Callahan > wrote: > >> On Thu, Feb 11, 2016 at 11:55 PM, Nicolas B. Pierron < >> nicolas.b.pier...@mozilla.com> wrote: >> >> > On 02/10/2016 08:04 PM, Robert

Re: Memory Usage on Perfherder & Memory Reduction

On Tuesday, February 9, 2016 at 2:25:42 PM UTC-8, Mark Finkle wrote: > Hi All, > > Recently Geoff Brown landed an AWSY-like system [1] for tracking memory > usage on Perfherder. This is awesome. It's one of my pinned tabs. > > I was happy to see two recent "drops" in memory usage: > > 1. A ~3%

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

Really interesting project, is this currently Windows only? It would be great if we could get memory usage as well. Also just to clarify, this is WPT that runs on webpagetest.org with code from https://github.com/WPO-Foundation/webpagetest? -e ___

Re: Using rr chaos mode to find intermittent bugs

On Thu, Feb 11, 2016 at 11:55 PM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > On 02/10/2016 08: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

Re: Using rr chaos mode to find intermittent bugs

On Thu, Feb 11, 2016 at 11:35 AM, Robert O'Callahan wrote: > On Thu, Feb 11, 2016 at 11:55 PM, Nicolas B. Pierron < > nicolas.b.pier...@mozilla.com> wrote: > > > On 02/10/2016 08:04 PM, Robert O'Callahan wrote: > > > >> Background: > >>

Re: Memory Usage on Perfherder & Memory Reduction

On Wednesday, February 10, 2016 at 7:46:11 AM UTC-8, William Lachance wrote: > 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 >

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

On Thursday, February 11, 2016 at 7:12:07 PM UTC-5, mcaste...@mozilla.com wrote: > It would be interesting to know the specifications of the system running the > tests and to run them on systems with differing characteristics (e.g. > different graphics card, different amount of RAM, etc.). > >

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

On Thursday, February 11, 2016 at 7:57:57 PM UTC-5, Patrick Meenan wrote: > On Thursday, February 11, 2016 at 7:12:07 PM UTC-5, mcaste...@mozilla.com > wrote: > > It would be interesting to know the specifications of the system running > > the tests and to run them on systems with differing

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

On 11/02/2016 11:38 AM, Valentin Gosu wrote: 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

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

It would be interesting to know the specifications of the system running the tests and to run them on systems with differing characteristics (e.g. different graphics card, different amount of RAM, etc.). - Marco. ___ dev-platform mailing list

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

On Thursday, February 11, 2016 at 6:37:40 PM UTC-5, Valentin Gosu wrote: > On 11 February 2016 at 19:46, Eric Rahm wrote: > > > Really interesting project, is this currently Windows only? It would be > > great if we could get memory usage as well. > > > > > Judging by the UA

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

On Thursday, February 11, 2016 at 5:03:05 PM UTC-8, Patrick Meenan wrote: > "Memory Usage" is complicated. Specially when you try to compare > different architectures. Sure, but this is all Windows for desktop at least. > Working set? Virtual memory? Accounting for shared pages, etc.

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

On 11 February 2016 at 19:46, Eric Rahm wrote: > Really interesting project, is this currently Windows only? It would be > great if we could get memory usage as well. > > Judging by the UA string - Windows NT 6.1; WOW64 - and the fact that we can run IE tests, it seems this is

Re: nsIDOMWindow is deprecated now is there an alternative?

In the below code i use aWebProgress to and then GetDOMWindow on that, however GetDOMWindow only allows nsIDOMWindow, would the QueryInterface accommodate for this for this NS_IMETHODIMP WebBrowserChrome::OnLocationChange(nsIWebProgress* aWebProgress, nsIRequest* aRequest, nsIURI

Re: nsIDOMWindow is deprecated now is there an alternative?

I am using it from c++ On Wed, Feb 10, 2016 at 7:38 PM, Kyle Huey wrote: > 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 >> >>

Re: nsIDOMWindow is deprecated now is there an alternative?

I was using the xulrunner SDK, but that is no longer created any more so using the firefox SDK. I am using it to create a plugin which can be used to launch a web browser which communicates with a proxy server which can be used to capture all the http traffic.

Re: nsIDOMWindow is deprecated now is there an alternative?

Do you happen to have a QueryInterface example, Would something like the following work: void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow) { nsPIDOMWindow* window = 0; nsresult status = aDOMWindow->QueryInterface(NS_GET_IID(nsPIDOMWindow), (void**)); nsIDocShell* docShell =

Re: nsIDOMWindow is deprecated now is there an alternative?

Currently I just want to get it up and running again on FF 45 again, with out making too much changes because we plan to deprecate this feature mid this year or so. Just need to get it working on Firefox 45, currently works perfectly on Firefox 38. ___

Re: nsIDOMWindow is deprecated now is there an alternative?

I tried to use nsPIDOMWindow, but issues is that functions like: Function GetContentDOMWindow in nsIWebBrowser is expecting: NS_IMETHOD GetContentDOMWindow(nsIDOMWindow * *aContentDOMWindow) = 0; (firefox-45.0b4\firefox-sdk\include\nsIWebBrowser.h) Function: NS_IMETHOD GetPrompt(nsIDOMWindow

Re: nsIDOMWindow is deprecated now is there an alternative?

So Something like: NS_IMETHODIMP WebBrowserChrome::OnLocationChange(nsIWebProgress* aWebProgress, nsIRequest* aRequest, nsIURI *location, uint32_t aFlags) { PRBool isSubFrameLoad = PR_FALSE; // Is this a subframe load if (aWebProgress) { nsCOMPtr domWindow;

Re: nsIDOMWindow is deprecated now is there an alternative?

yep This is how I was using nsIDOMWindow before: NS_IMETHODIMP WebBrowserChrome::OnLocationChange(nsIWebProgress* aWebProgress, nsIRequest* aRequest, nsIURI *location, uint32_t aFlags) { PRBool isSubFrameLoad = PR_FALSE; // Is this a subframe load if (aWebProgress) {

Re: nsIDOMWindow is deprecated now is there an alternative?

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 /* void getPrompt (in nsIDOMWindow aParent, in nsIIDRef iid, [iid_is (iid), retval] out nsQIResult result); */ NS_IMETHOD

Re: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

Yes, these are two different objects, so As* seems not right here. Unfortunately,WidgetEventPtr is already used as the name of a pointer in this IDL. So far, WidgetEventRef is selected. On Thu, Feb 11, 2016 at 10:23 AM, Bobby Holley wrote: > IMO, As* generally implies a

Re: Using rr chaos mode to find intermittent bugs

On 02/10/2016 08: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 intermittent test failures under