Re: Using rr chaos mode to find intermittent bugs

2016-02-11 Thread Robert O'Callahan 
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 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 rr. […]
>> >>
>> >
>> > Thanks Roc, I will give it a try.
>> >
>> > On the other hand, I used to rely more on the "-c" option to achieve a
>> > similar thing in the past, instead of the "-e" option.
>> >
>> > The reason I did so being that the thread I am interested in does a few
>> > syscalls compared to the rest of the program.  Thus I felt that using
>> "-e"
>> > option would give it an unfair large time slices compared to what is
>> > supposed to happen if the threads are running concurrently.
>>
>>
>> The -e option is gone now because the new scheduler (with or without chaos
>> mode) does not take system calls into account when calculating the length
>> of a timeslice. We only count conditional branches.
>>
>
> So we context switch at a syscall now only when the current thread happens
> to become unschedulable?
>

Or if any higher-priority thread has become runnable. This includes not
just a low-priority thread doing a FUTEX_WAKE to wake a high-priority
thread, but also a thread changing its priority or another thread's
priority, or even a low-priority thread writing to a pipe that a
high-priority thread is reading from. (Though in the latter case the
scheduler *might* not see the high-priority thread become runnable in time
in all cases.)

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Memory Usage on Perfherder & Memory Reduction

2016-02-11 Thread Eric Rahm 
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% drop in "Resident Memory Tabs closed [+30s]", likely due to Bug
> 990916 which expires displayports
> https://treeherder.mozilla.org/perf.html#/graphs?series=[mozilla-inbound,f9cdadf297fd409c043e8114ed0fa656334e7fad,1]=1454516622714.927,1454583882842.8733,181623181.32925725,250028978.43070653
> 
> 2. A ~2% drop across all memory tracking sometime on Feb8. Hard to pick a
> changeset, but the drop happened when inbound was merged to fx-team.
> https://treeherder.mozilla.org/perf.html#/graphs?series=%5Bmozilla-inbound,f9cdadf297fd409c043e8114ed0fa656334e7fad,1%5D
> 
> Great to see drops in memory usage!
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1233220

It's great we're tracking memory usage on Fennec again! Just to be clear, this 
data is android-only (correct me if I'm wrong). On the Linux desktop side we've 
started pushing data from AWSY to the treeherder staging instance. Hopefully 
that will get that into production shortly.

-e
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2016-02-11 Thread Eric Rahm 
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
___
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

2016-02-11 Thread Robert O'Callahan 
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 enables a chaos
>> mode for rr recording. This is designed to help reproduce intermittent
>> test
>> failures under rr. […]
>>
>
> Thanks Roc, I will give it a try.
>
> On the other hand, I used to rely more on the "-c" option to achieve a
> similar thing in the past, instead of the "-e" option.
>
> The reason I did so being that the thread I am interested in does a few
> syscalls compared to the rest of the program.  Thus I felt that using "-e"
> option would give it an unfair large time slices compared to what is
> supposed to happen if the threads are running concurrently.


The -e option is gone now because the new scheduler (with or without chaos
mode) does not take system calls into account when calculating the length
of a timeslice. We only count conditional branches.

Bugs that require very frequent fine-grained context switching are probably
still hard to find with chaos mode, because very frequent context switching
slows down recording tremendously and I didn't want chaos mode to slow down
execution by more than a bounded amount. So you may find that -c is still
needed.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
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

2016-02-11 Thread Kyle Huey 
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:
> >> 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. […]
> >>
> >
> > Thanks Roc, I will give it a try.
> >
> > On the other hand, I used to rely more on the "-c" option to achieve a
> > similar thing in the past, instead of the "-e" option.
> >
> > The reason I did so being that the thread I am interested in does a few
> > syscalls compared to the rest of the program.  Thus I felt that using
> "-e"
> > option would give it an unfair large time slices compared to what is
> > supposed to happen if the threads are running concurrently.
>
>
> The -e option is gone now because the new scheduler (with or without chaos
> mode) does not take system calls into account when calculating the length
> of a timeslice. We only count conditional branches.
>

So we context switch at a syscall now only when the current thread happens
to become unschedulable?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Memory Usage on Perfherder & Memory Reduction

2016-02-11 Thread Eric Rahm 
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 
> interface for filing bugs). For example, you can see all recently 
> detected regressions and improvements in memory usage here:
> 
> https://treeherder.allizom.org/perf.html#/alerts?status=-1=4
> 
> (there's some false positives in there I know, we could probably do with 
> some slightly better regression-detection code...)
> 
> More updates soon.
> 
> Will
> 

That dashboard looks great, it'll be interesting to see how reliable the AWSY 
data is for generating automatic regression detection in the long run.

-e
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2016-02-11 Thread Patrick Meenan 
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.).
> 
> - Marco.

The "Dulles" machines that look like were used for these tests are Windows 
Server 2008 VM's on VMWare ESXi with 2GB of Ram and 1 core allocated (SSD 
storage).  If you want to test on physical machines with GPU's you'll want the 
"Dulles_Thinkpad" location which runs on Thinkpad T430 laptops running Windows 
7 with Core i5's and Intel integrated GPU (there are much fewer VM's than 
physical machines though so tests will take longer).

If you want to run tests on arbitrary hardware you're also welcome to deploy 
the agent software on whatever test hardware you have available.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2016-02-11 Thread Patrick Meenan 
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 characteristics (e.g. 
> > different graphics card, different amount of RAM, etc.).
> > 
> > - Marco.
> 
> The "Dulles" machines that look like were used for these tests are Windows 
> Server 2008 VM's on VMWare ESXi with 2GB of Ram and 1 core allocated (SSD 
> storage).  If you want to test on physical machines with GPU's you'll want 
> the "Dulles_Thinkpad" location which runs on Thinkpad T430 laptops running 
> Windows 7 with Core i5's and Intel integrated GPU (there are much fewer VM's 
> than physical machines though so tests will take longer).
> 
> If you want to run tests on arbitrary hardware you're also welcome to deploy 
> the agent software on whatever test hardware you have available.

Sorry, had that backwards - much fewer physical machines than VM's - sorry for 
the confusion.  The Thinkpads also run SSD's and minimal software (really only 
Microsoft Security Essentials running/installed other than the browser).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2016-02-11 Thread Mark Hammond 

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 into improving and to clear
any prejudice that may be caused by FUD or past performance differences
that are no longer true.


Bug 1239709 seems related - it was opened in response to a recent 
article [1] which shows us as having worse page-load performance than 
chrome, particularly with flash involved.


Mark

[1] 
http://www.cio.com/article/2974303/browsers/the-best-web-browser-of-2015-firefox-chrome-edge-ie-and-opera-compared.html


We've begun this project by doing a set of performance runs on
WebPageTest.com in order to compare Firefox's performance against Chrome on
the home pages of the Alexa 100 (the top 100 web sites worldwide). We've
made a visualization tool which plots all of the runs on a graph, so we may
easily compare them:

http://valenting.github.io/presto-plot/plot.html

- click on a domain link to see results for each site.
- you are able to view the results sorted or unsorted, or filter by the
browser version
- you can also compare metrics other than load time - such as speed
Index, number of DNS queries, etc
- you can also compare the browsers on several connectivity profiles
(Cable, 3G, Dialup)
- You can click on each individual point to go to the WPT run and view
the results in greater detail

---
Initial results:

The results consistently show that Firefox is faster than Chrome for both
of our major metrics (load time and speedIndex). On a majority of domains
Firefox is faster on both first loads and reloads. When we analyze 3G
connectivity runs, Firefox's speedup less substantial, and we encounter
additional domains where Chrome has an edge.

Dial up connectivity is a bit more difficult to analyze. Because of the
large size of most websites, browsers are unable to load the website within
5 minutes, or it might time out. Chrome seems to have more successful data
points, and faster loads on dial up, but it is difficult to reach a
conclusion based on a limited data set.

WPT also has Nightly builds - which default to e10s ON. The several data
points we have show similar performance to non-e10s builds (which is good,
considering Nightly builds have more checks and assertions)

---
Interesting metrics:

Load time - is measured as the time from the start of the initial
navigation until the beginning of the window load event (onload).

Speed Index - is the metric recommended PageSpeedTest.com. Speed index
measures how fast a page is displayed on screen. Details:
https://goo.gl/7ha6eE

Activity time - measured as the time from the start of the initial
navigation until there was 2 seconds of no network activity after Document
Complete.  This will usually include any activity that is triggered by
javascript after the main page loads.

For most metrics a lower score is better (faster).

--
Error sources:

Websites may return different content depending on the UA string. While
this optimization makes sense for a lot of websites, in this situation it
is difficult to determine if the browser's performance or the website's
optimizations have more impact on the page load.

Since we do not log onto any sites, the data here for sites which rely on
logins to display full data (Facebook, etc) are not representative of most
users' experience and will generally have a different (much more heavily JS
and XHR-based) profile in reality.

For several data sets we may observe a certain spike in the data points –
runs that take 3x-7x times longer than usual. This may be due to a number
of reasons: a higher load on the network in the data center, a higher load
on the VMs on which the browsers are running, or the fact that websites
serve variable content – different images, different ads.
It may be that some of the page loads don't load the website completely, or
encounter errors. WPT also saves a screenshot of the page, along with data
on all of the resources it loads, so we may look at really fast loads to
make sure they are complete.

WPT has a maximum load time of 5 minutes. Any page load that takes longer
than that will be recorded as a 0 – so while it may seem to load faster,
that is not the case. Other errors may also be recorded as a 0.

WPT only loads one tab page at a time, whereas the load time on a user's
may be affected by his activity in other tabs. e10s certainly helps in this
area.

We only tested the performance of the landing page. It would be possible to
simulate user activity and navigation once the landing page is loaded, but
for this we'd need to write separate scripts for each domain we test.

Location may be an issue, as the RTT to the server or the CDN may vary. All
of the tests we ran were made on the WPT datacenter in

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

2016-02-11 Thread mcastelluccio 
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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2016-02-11 Thread Patrick Meenan 
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 string - Windows NT 6.1; WOW64 - and the fact that we can
> run IE tests, it seems this is windows only at the moment.
> Unfortunately,  I don't think WPT tracks memory usage.
> 

Windows only for desktop agents and Android and iOS for mobile (though Android 
only supports Chrome currently, haven't had a chance to look at remote 
controlling Firefox on Android).

"Memory Usage" is  complicated.  Specially when you try to compare 
different architectures.  Working set? Virtual memory? Accounting for shared 
pages, etc.  Optimizing for the wrong thing can have negative impacts (like 
optimizing for the working set displayed in task manager is easy by forcing a 
process to page out periodically but it's artificial and not good for anybody).

WebPageTest used to track it at one point but the data wasn't actually useful 
so I removed it. If anyone has suggestions on how to do it in a useful way I'd 
be happy to add it.

> 
> > Also just to clarify, this is WPT that runs on webpagetest.org with code
> > from https://github.com/WPO-Foundation/webpagetest?
> >
> 
> Yes

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2016-02-11 Thread Eric Rahm 
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.

Working set (RSS) and private working set (USS) are the most interesting 
numbers. This gets tricky with multi-process setups, but a reasonable baseline 
I've been looking at is |total_memory = parent_rss + sum(child_uss)|

For example with Firefox I would be interested in the RSS of the parent process 
(firefox.exe) and the USS of the child processes (plugin-container.exe). For 
Chrome it would be more along the lines of the RSS of the main chrome process, 
and the USS of the renderer/gpu/plugin processes (and probably the RSS of the 
nacl process if that's still around).

> Optimizing for the wrong thing can have negative impacts (like optimizing for 
> the working set displayed in task manager is easy by forcing a process to 
> page out periodically but it's artificial and not good for anybody).

Artificial optimizations are an unfortunate side effect of every benchmark 
(particularly in js-land), I'm not sure it's our place to not measure something 
because we think people might game it. 

> WebPageTest used to track it at one point but the data wasn't actually useful 
> so I removed it. If anyone has suggestions on how to do it in a useful way 
> I'd be happy to add it.

See above.

-e
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2016-02-11 Thread Valentin Gosu 
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 windows only at the moment.
Unfortunately,  I don't think WPT tracks memory usage.


> Also just to clarify, this is WPT that runs on webpagetest.org with code
> from https://github.com/WPO-Foundation/webpagetest?
>

Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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 *location,
uint32_t aFlags)
{
PRBool isSubFrameLoad = PR_FALSE; // Is this a subframe load
if (aWebProgress) {
nsCOMPtr  domWindow;
nsCOMPtr  topDomWindow;
aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
if (domWindow) { // Get root domWindow
domWindow->GetTop(getter_AddRefs(topDomWindow));
}
if (domWindow != topDomWindow)
isSubFrameLoad = PR_TRUE;
}
if (!isSubFrameLoad)
CWebBrowserChromeUI::UpdateCurrentURI(this);
return NS_OK;
}

On Wed, Feb 10, 2016 at 8:30 PM, Kyle Huey  wrote:

> Yes, SizeToContent is only accessible to JS now.
>
> - Kyle
>
> On Wed, Feb 10, 2016 at 5:28 PM, Devan Shah 
> wrote:
>
>> 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) {
>> nsCOMPtr  domWindow;
>> nsCOMPtr  topDomWindow;
>> aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
>> if (domWindow) { // Get root domWindow
>> domWindow->GetTop(getter_AddRefs(topDomWindow));
>> }
>> if (domWindow != topDomWindow)
>> isSubFrameLoad = PR_TRUE;
>> }
>> if (!isSubFrameLoad)
>> CWebBrowserChromeUI::UpdateCurrentURI(this);
>> return NS_OK;
>> }
>>
>> So here just changing nsCOMPtr to nsCOMPtr
>> and using QueryInterface should do the trick right?
>>
>> Also I am using a function called SizeToContent() from nsIDOMWindow which
>> I do not see exists any more in nsPIDOMWindow either was this one removed
>> completly.
>>
>> On Wed, Feb 10, 2016 at 8:24 PM, Kyle Huey  wrote:
>>
>>> 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* rootWebShell = 0;
>>>   NS_IF_RELEASE(rootWebShell);
>>> //return status;
>>> }
>>>
>>> - Kyle
>>>
>>> On Wed, Feb 10, 2016 at 5:22 PM, Devan Shah 
>>> wrote:
>>>
 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 = 0;
   if (window)
 window->GetDocShell();
   nsIWebShell* rootWebShell = 0;
   NS_IF_RELEASE(rootWebShell);
   NS_IF_RELEASE(docShell);
   NS_IF_RELEASE(window);
 //return status;
 }

 On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey  wrote:

> 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 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.
>>
>>
>

>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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
>>
>> 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
>> nsIDOMWindow a lot for all of it functions.
>>
>> Is there any way to get an alternative with the same functionality which
>> requires minimal changes or is there a way that I can get the nsIDOMWindow
>> interface and all of its functionality back by adding the interface locally
>> and implementing the functions locally.
>>
>> Thanks
>> Devan Shah
>> ___
>> dev-platform 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

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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 = 0;
  if (window)
window->GetDocShell();
  nsIWebShell* rootWebShell = 0;
  NS_IF_RELEASE(rootWebShell);
  NS_IF_RELEASE(docShell);
  NS_IF_RELEASE(window);
//return status;
}

On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey  wrote:

> 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 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.
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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 *aParent, const nsIID & iid,
void **result) = 0; from nsIPromptFactory

So makes it all not compatible.

Is there any way I can rebuild the Firefox SDK with the old nsIDOMWindow

On Wed, Feb 10, 2016 at 7:51 PM, Kyle Huey  wrote:

> 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
>>
>>   /* void getPrompt (in nsIDOMWindow aParent, in nsIIDRef iid, [iid_is
>> (iid), retval] out nsQIResult result); */
>>   NS_IMETHOD GetPrompt(nsIDOMWindow *aParent, const nsIID & iid, void
>> **result) = 0;
>>
>>
>>
>> 
>>
>> On Wed, Feb 10, 2016 at 7:43 PM, Kyle Huey  wrote:
>>
>>> 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, which is a base interface of nsPIDOMWindowOuter.  You
>>> can look at
>>> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsPIDOMWindow.h
>>> to see what's there.  Some methods on nsIDOMWindow that were unused were
>>> removed completely, though I don't think there were many.
>>>
>>> - Kyle
>>>
>>> On Wed, Feb 10, 2016 at 4:40 PM, Devan Shah 
>>> wrote:
>>>
 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
>>
>> 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
>> nsIDOMWindow a lot for all of it functions.
>>
>> Is there any way to get an alternative with the same functionality
>> which requires minimal changes or is there a way that I can get the
>> nsIDOMWindow interface and all of its functionality back by adding the
>> interface locally and implementing the functions locally.
>>
>> Thanks
>> Devan Shah
>> ___
>> dev-platform 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

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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;
nsCOMPtr  topDomWindow;
aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
if (domWindow) { // Get root domWindow
topDomWindow = do_QueryInterface(domWindow);
topDomWindow->GetTop();
}
if (domWindow != topDomWindow)
isSubFrameLoad = PR_TRUE;
}
if (!isSubFrameLoad)
CWebBrowserChromeUI::UpdateCurrentURI(this);
return NS_OK;
}

On Wed, Feb 10, 2016 at 8:37 PM, Kyle Huey  wrote:

> 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, would the QueryInterface
>> accommodate for this for this
>>
>> 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;
>> nsCOMPtr  topDomWindow;
>> aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
>> if (domWindow) { // Get root domWindow
>> domWindow->GetTop(getter_AddRefs(topDomWindow));
>> }
>> if (domWindow != topDomWindow)
>> isSubFrameLoad = PR_TRUE;
>> }
>> if (!isSubFrameLoad)
>> CWebBrowserChromeUI::UpdateCurrentURI(this);
>> return NS_OK;
>> }
>>
>> On Wed, Feb 10, 2016 at 8:30 PM, Kyle Huey  wrote:
>>
>>> Yes, SizeToContent is only accessible to JS now.
>>>
>>> - Kyle
>>>
>>> On Wed, Feb 10, 2016 at 5:28 PM, Devan Shah 
>>> wrote:
>>>
 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) {
 nsCOMPtr  domWindow;
 nsCOMPtr  topDomWindow;
 aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
 if (domWindow) { // Get root domWindow
 domWindow->GetTop(getter_AddRefs(topDomWindow));
 }
 if (domWindow != topDomWindow)
 isSubFrameLoad = PR_TRUE;
 }
 if (!isSubFrameLoad)
 CWebBrowserChromeUI::UpdateCurrentURI(this);
 return NS_OK;
 }

 So here just changing nsCOMPtr to nsCOMPtr
 and using QueryInterface should do the trick right?

 Also I am using a function called SizeToContent() from nsIDOMWindow
 which I do not see exists any more in nsPIDOMWindow either was this one
 removed completly.

 On Wed, Feb 10, 2016 at 8:24 PM, Kyle Huey  wrote:

> 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* rootWebShell = 0;
>   NS_IF_RELEASE(rootWebShell);
> //return status;
> }
>
> - Kyle
>
> On Wed, Feb 10, 2016 at 5:22 PM, Devan Shah 
> wrote:
>
>> 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 = 0;
>>   if (window)
>> window->GetDocShell();
>>   nsIWebShell* rootWebShell = 0;
>>   NS_IF_RELEASE(rootWebShell);
>>   NS_IF_RELEASE(docShell);
>>   NS_IF_RELEASE(window);
>> //return status;
>> }
>>
>> On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey  wrote:
>>
>>> 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 making too much changes because

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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) {
nsCOMPtr  domWindow;
nsCOMPtr  topDomWindow;
aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
if (domWindow) { // Get root domWindow
domWindow->GetTop(getter_AddRefs(topDomWindow));
}
if (domWindow != topDomWindow)
isSubFrameLoad = PR_TRUE;
}
if (!isSubFrameLoad)
CWebBrowserChromeUI::UpdateCurrentURI(this);
return NS_OK;
}

So here just changing nsCOMPtr to nsCOMPtr and
using QueryInterface should do the trick right?

Also I am using a function called SizeToContent() from nsIDOMWindow which I
do not see exists any more in nsPIDOMWindow either was this one removed
completly.

On Wed, Feb 10, 2016 at 8:24 PM, Kyle Huey  wrote:

> 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* rootWebShell = 0;
>   NS_IF_RELEASE(rootWebShell);
> //return status;
> }
>
> - Kyle
>
> On Wed, Feb 10, 2016 at 5:22 PM, Devan Shah 
> wrote:
>
>> 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 = 0;
>>   if (window)
>> window->GetDocShell();
>>   nsIWebShell* rootWebShell = 0;
>>   NS_IF_RELEASE(rootWebShell);
>>   NS_IF_RELEASE(docShell);
>>   NS_IF_RELEASE(window);
>> //return status;
>> }
>>
>> On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey  wrote:
>>
>>> 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 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.


>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-11 Thread Devan Shah 
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 GetPrompt(nsIDOMWindow *aParent, const nsIID & iid, void
**result) = 0;




On Wed, Feb 10, 2016 at 7:43 PM, Kyle Huey  wrote:

> 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,
> which is a base interface of nsPIDOMWindowOuter.  You can look at
> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsPIDOMWindow.h to
> see what's there.  Some methods on nsIDOMWindow that were unused were
> removed completely, though I don't think there were many.
>
> - Kyle
>
> On Wed, Feb 10, 2016 at 4:40 PM, Devan Shah 
> wrote:
>
>> 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

 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
 nsIDOMWindow a lot for all of it functions.

 Is there any way to get an alternative with the same functionality
 which requires minimal changes or is there a way that I can get the
 nsIDOMWindow interface and all of its functionality back by adding the
 interface locally and implementing the functions locally.

 Thanks
 Devan Shah
 ___
 dev-platform 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

Re: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

2016-02-11 Thread Aidin Gharibnavaz 
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 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. For
> example, both Document::AsRootElement or nsDocShell::AsOuterWindow seem
> like misleading names given how the data structures are set up.
>
> I'm assuming here that Aidin is dealing with two different objects. If
> not, As* is clearly fine.
>
> On Wed, Feb 10, 2016 at 10:02 PM, Kyle Huey  wrote:
>
>> 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
>> > 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.
>> > * GetWidgetEvent() is good, but may suggests that method can return
>> > nullptr.
>> > * AsWidgetEvent() don't have this ambiguousness, but is not a good name.
>> >
>> > Any other ideas?
>> > ___
>> > dev-platform 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
>>
>
>
___
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

2016-02-11 Thread Nicolas B. Pierron 

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 rr. […]


Thanks Roc, I will give it a try.

On the other hand, I used to rely more on the "-c" option to achieve a 
similar thing in the past, instead of the "-e" option.


The reason I did so being that the thread I am interested in does a few 
syscalls compared to the rest of the program.  Thus I felt that using "-e" 
option would give it an unfair large time slices compared to what is 
supposed to happen if the threads are running concurrently.


--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform