Re: XULRunner future and ownership

2016-02-10 Thread Dave Townsend 
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  wrote:
> 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 automated
>> XULRunner builds and so XULRunner will probably quickly cease to work.
>> In order to keep XULRunner in the tree, we need an owner who wants to
>> keep it building and running properly. Currently, I am the nominal owner
>> of the XULRunner code, but I have no desire to do this work or even
>> really to review the necessary patches. I am looking to see whether
>> there is an alternate owner who is interested in the task of keeping
>> XULRunner building and running properly and reviewing patches to
>> XULRuner-specific code. Please contact me if you want to nominate
>> yourself or somebody else for this role.
>>
>> If I do not find a suitable owner in the next two weeks, I intend to
>> remove the XULRunner code from the mozilla-central repository on 14-August.
>>
>> --BDS
>
> Hello
>
> Is the xulrunner SDK officially deprecated now. I see that the latest 
> xulrunner version is xulrunner-41.0.2 would this be compatible wit Firefox 
> 45. If not where can I get a version that is compatible with Firefox 45. I 
> see that 
> http://ftp.mozilla.org/pub/xulrunner/nightly/latest-trunk/Deprecation_notice.txt
>  points to:
>
> XULRunner SDKs can now be downloaded from
>https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
>
> Theses are the nightly builds, but where can I get the release version for 
> Firefox 45. Also does the SDK change from Firefox 45 to Firefox 45 ESR.
>
> 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: XULRunner future and ownership

2016-02-10 Thread Devan Shah 
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 automated 
> XULRunner builds and so XULRunner will probably quickly cease to work. 
> In order to keep XULRunner in the tree, we need an owner who wants to 
> keep it building and running properly. Currently, I am the nominal owner 
> of the XULRunner code, but I have no desire to do this work or even 
> really to review the necessary patches. I am looking to see whether 
> there is an alternate owner who is interested in the task of keeping 
> XULRunner building and running properly and reviewing patches to 
> XULRuner-specific code. Please contact me if you want to nominate 
> yourself or somebody else for this role.
> 
> If I do not find a suitable owner in the next two weeks, I intend to 
> remove the XULRunner code from the mozilla-central repository on 14-August.
> 
> --BDS

Hello 

Is the xulrunner SDK officially deprecated now. I see that the latest xulrunner 
version is xulrunner-41.0.2 would this be compatible wit Firefox 45. If not 
where can I get a version that is compatible with Firefox 45. I see that 
http://ftp.mozilla.org/pub/xulrunner/nightly/latest-trunk/Deprecation_notice.txt
 points to: 

XULRunner SDKs can now be downloaded from 
   https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/

Theses are the nightly builds, but where can I get the release version for 
Firefox 45. Also does the SDK change from Firefox 45 to Firefox 45 ESR.

Thanks
Devan Shah
___
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-10 Thread William Lachance 
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

On 2016-02-09 5:25 PM, 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



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

Re: XULRunner future and ownership

2016-02-10 Thread Dave Townsend 
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/
>>
>> 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  wrote:
>> > 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 automated
>> >> XULRunner builds and so XULRunner will probably quickly cease to work.
>> >> In order to keep XULRunner in the tree, we need an owner who wants to
>> >> keep it building and running properly. Currently, I am the nominal owner
>> >> of the XULRunner code, but I have no desire to do this work or even
>> >> really to review the necessary patches. I am looking to see whether
>> >> there is an alternate owner who is interested in the task of keeping
>> >> XULRunner building and running properly and reviewing patches to
>> >> XULRuner-specific code. Please contact me if you want to nominate
>> >> yourself or somebody else for this role.
>> >>
>> >> If I do not find a suitable owner in the next two weeks, I intend to
>> >> remove the XULRunner code from the mozilla-central repository on 
>> >> 14-August.
>> >>
>> >> --BDS
>> >
>> > Hello
>> >
>> > Is the xulrunner SDK officially deprecated now. I see that the latest 
>> > xulrunner version is xulrunner-41.0.2 would this be compatible wit Firefox 
>> > 45. If not where can I get a version that is compatible with Firefox 45. I 
>> > see that 
>> > http://ftp.mozilla.org/pub/xulrunner/nightly/latest-trunk/Deprecation_notice.txt
>> >  points to:
>> >
>> > XULRunner SDKs can now be downloaded from
>> >https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
>> >
>> > Theses are the nightly builds, but where can I get the release version for 
>> > Firefox 45. Also does the SDK change from Firefox 45 to Firefox 45 ESR.
>> >
>> > Thanks
>> > Devan Shah
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>
> So xulrunner SDK version 41.0.2 will not work with FF 45 right.

Correct, you must use the matching version.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

2016-02-10 Thread Devan Shah 
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
> one of the beta versions.
> 
> On Wed, Feb 10, 2016 at 7:21 AM, Devan Shah  wrote:
> > 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 automated
> >> XULRunner builds and so XULRunner will probably quickly cease to work.
> >> In order to keep XULRunner in the tree, we need an owner who wants to
> >> keep it building and running properly. Currently, I am the nominal owner
> >> of the XULRunner code, but I have no desire to do this work or even
> >> really to review the necessary patches. I am looking to see whether
> >> there is an alternate owner who is interested in the task of keeping
> >> XULRunner building and running properly and reviewing patches to
> >> XULRuner-specific code. Please contact me if you want to nominate
> >> yourself or somebody else for this role.
> >>
> >> If I do not find a suitable owner in the next two weeks, I intend to
> >> remove the XULRunner code from the mozilla-central repository on 14-August.
> >>
> >> --BDS
> >
> > Hello
> >
> > Is the xulrunner SDK officially deprecated now. I see that the latest 
> > xulrunner version is xulrunner-41.0.2 would this be compatible wit Firefox 
> > 45. If not where can I get a version that is compatible with Firefox 45. I 
> > see that 
> > http://ftp.mozilla.org/pub/xulrunner/nightly/latest-trunk/Deprecation_notice.txt
> >  points to:
> >
> > XULRunner SDKs can now be downloaded from
> >https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
> >
> > Theses are the nightly builds, but where can I get the release version for 
> > Firefox 45. Also does the SDK change from Firefox 45 to Firefox 45 ESR.
> >
> > Thanks
> > Devan Shah
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform

So xulrunner SDK version 41.0.2 will not work with FF 45 right.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

2016-02-10 Thread Devan Shah 
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 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  wrote:
> >> > 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 automated
> >> >> XULRunner builds and so XULRunner will probably quickly cease to work.
> >> >> In order to keep XULRunner in the tree, we need an owner who wants to
> >> >> keep it building and running properly. Currently, I am the nominal owner
> >> >> of the XULRunner code, but I have no desire to do this work or even
> >> >> really to review the necessary patches. I am looking to see whether
> >> >> there is an alternate owner who is interested in the task of keeping
> >> >> XULRunner building and running properly and reviewing patches to
> >> >> XULRuner-specific code. Please contact me if you want to nominate
> >> >> yourself or somebody else for this role.
> >> >>
> >> >> If I do not find a suitable owner in the next two weeks, I intend to
> >> >> remove the XULRunner code from the mozilla-central repository on 
> >> >> 14-August.
> >> >>
> >> >> --BDS
> >> >
> >> > Hello
> >> >
> >> > Is the xulrunner SDK officially deprecated now. I see that the latest 
> >> > xulrunner version is xulrunner-41.0.2 would this be compatible wit 
> >> > Firefox 45. If not where can I get a version that is compatible with 
> >> > Firefox 45. I see that 
> >> > http://ftp.mozilla.org/pub/xulrunner/nightly/latest-trunk/Deprecation_notice.txt
> >> >  points to:
> >> >
> >> > XULRunner SDKs can now be downloaded from
> >> >
> >> > https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
> >> >
> >> > Theses are the nightly builds, but where can I get the release version 
> >> > for Firefox 45. Also does the SDK change from Firefox 45 to Firefox 45 
> >> > ESR.
> >> >
> >> > Thanks
> >> > Devan Shah
> >> > ___
> >> > dev-platform mailing list
> >> > dev-platform@lists.mozilla.org
> >> > https://lists.mozilla.org/listinfo/dev-platform
> >
> > So xulrunner SDK version 41.0.2 will not work with FF 45 right.
> 
> Correct, you must use the matching version.

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

Using rr chaos mode to find intermittent bugs

2016-02-10 Thread Robert O'Callahan 
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 this
successfully to find difficult bugs. Even though rr works only on desktop
Linux (including VMs), I've reproduced a bug that only showed up in
automation on Android, and khuey reproduced a bug that only showed up on
OSX 10.6.

I'm continuing to do experiments to try to reproduce more of our top
intermittents, but you may already find rr chaos mode useful. I recommend
running a single test or a small group of tests continuously; one of my
bugs only had a few failing runs out of a thousand. I'm sure there are
still bugs rr can't reproduce, and I'm very interested in hearing about
bugs that eventually get fixed but that rr was not able to reproduce. By
studying such bugs we can improve rr chaos mode so it can find them.

Obviously, once rr chaos mode has proved itself, we should get some
automation around it. I'd like a bit more experience with it before we have
that discussion.

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-10 Thread Robert O'Callahan 
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 cases rr chaos mode might
trigger bugs that don't normally happen, that one way or another block you
from finding the bug you care about.

However, bugs found by rr chaos mode should all be "real bugs". I'd
certainly love to hear about any cases where that's not true.

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-10 Thread Ted Mielczarek 


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 intermittent
> test
> failures under rr. We already have a few reports of people using this
> successfully to find difficult bugs. Even though rr works only on desktop
> Linux (including VMs), I've reproduced a bug that only showed up in
> automation on Android, and khuey reproduced a bug that only showed up on
> OSX 10.6.
> 
> I'm continuing to do experiments to try to reproduce more of our top
> intermittents, but you may already find rr chaos mode useful. I recommend
> running a single test or a small group of tests continuously; one of my
> bugs only had a few failing runs out of a thousand. I'm sure there are
> still bugs rr can't reproduce, and I'm very interested in hearing about
> bugs that eventually get fixed but that rr was not able to reproduce. By
> studying such bugs we can improve rr chaos mode so it can find them.
> 
> Obviously, once rr chaos mode has proved itself, we should get some
> automation around it. I'd like a bit more experience with it before we
> have
> that discussion.

This is great! I've kept holding out hope that rr can help us fix
intermittent test failures, but so far we've failed to actually prove
this out. 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. jmaher and armenzg and others have
been doing some great work lately standing up Linux tests in
Taskcluster, as a side effect of which means we now have a Docker image
for running Linux tests. If anyone wants to prototype reproducing
failures from CI running rr inside that image would be a good place to
start.

-Ted
___
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-10 Thread ISHIKAWA,chiaki 

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. In this vein, it's possible that in some cases rr chaos mode might
trigger bugs that don't normally happen, that one way or another block you
from finding the bug you care about.

However, bugs found by rr chaos mode should all be "real bugs". I'd
certainly love to hear about any cases where that's not true.

Rob


This scheduling change causing rare to reproduce bugs to occur more 
often sounds interesting.


I have found that running C-C TB (sorry it is not the browser here)
under valgrind/memcheck which slows down the operation dramatically
have helped me to find a few issues.
From the top of my head:
 - incremental GC gets re-entered before it finishes the previous 
invocation.

   This was not handled properly until I noticed the issue, but it is
   now handled OK.
 - there are some issues in threading.
   For one, at start up, some threads incorrectly assume that window as 
on screen is

   already there, but due to the slowdown, it is not created yet.
   I see some disturbing warning messages printed on the invoking tty 
window.
   I have not filed a bug yet since this is relatively new. I don't 
think I saw

   such messages early last year.

   For the other, at shutdown, C-C TB has a problem of incorrect 
ordering of

   thread shutdown: some threads seem to request services during shutdown
   from service providers, but threads that provide the services have 
already
   shutdown. So proper shutdown does not happen. There may even be a 
cyclic

   dependency. Who knows?
   With the slowdown due to valgrind/memcheck, the issue
   gets more pronounced. Well, right now, though, there is
   a timer that monitors the shtudown process and the prolonged timeout of
   some operations due to the thread missing and the slowdown caused by
   valgrind/memcheck automatically triggers the assertion of permanent 
hung at
   shutdown and so it is difficult to figure out what are going on. But 
one can

   hope that the check for permanent hung gets removed temporarily to
   investigate the issue further.
   Crashes at C-C TB are something I experienced several times in the last
   couple of years in real life.


Another thing this rr framework or similar approach will be useful for 
C-C TB xpcshell testing (and I think it is useful for FF xpcshell 
testing as well.)


There seem to be a few intermittent test failures in xpcshell tests.
This rr approach may make the test fail more often.

*HOWEVER*, I am going to file a bugzilla about
OVEREAGER ASYNC approach of the current test xpcshell script introducing
spurious errors at least under Windows (a previous test which still have 
some files open has not completely shut down before the next test that 
seems to use

THOSE files get started. Under windows, opening such a file may result in
file locked error (under linux/OSX, I think it is OK to open such files 
unless the first program explicitly calls |flock| or something.)


So whether ALL the intermittent failures in C-C TB xpcshell tests are 
something that can be investigated better with rr approach is anyone's 
guess, but

I think it does have a potential to trigger more dormant bugs just as
valgrind/memcheck uncovered a few timing issues.

But one other post suggested that it is not applicable right now outside 
Gecko, meaning C-C TB xpcshell testing cannot directly benefit from rr?

(The approach, of course, can be emulated, I suppose.)

TIA


___
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-10 Thread Robert O'Callahan 
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

2016-02-10 Thread ISHIKAWA,chiaki 

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

Re: nsIDOMWindow is deprecated now is there an alternative?

2016-02-10 Thread Kyle Huey 
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-10 Thread Kyle Huey 
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

nsIDOMWindow is deprecated now is there an alternative?

2016-02-10 Thread Devan Shah 
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

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

2016-02-10 Thread Valentin Gosu 
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.

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

--

The stats are merely informative. All of the data is is publicly available
to anyone who has an inclination towards statistics.

Setup:
webpagetest.meteor.com - an api that returns a list of IDs in JSON
form, representing all the WPT tests run for a given domain (source and API:
https://github.com/valenting/webpagetest )

Suggesting new name for nsIDOMEvent::GetInternalNSEvent

2016-02-10 Thread Aidin Gharibnavaz 
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

Re: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

2016-02-10 Thread Bobby Holley 
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 , 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

Re: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

2016-02-10 Thread Bobby Holley 
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: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

2016-02-10 Thread Kyle Huey 
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

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

2016-02-10 Thread James Graham 

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 ends with a RequestLongerTimeout as the fix



this sounds equivalent to saying "Since we don't have enough resources (or
a plan) to investigate why some tests take so long, let's give up"... But
then maybe we should have that explicit discussion, rather than assuming
it's a truth.


FWIW I think it's closer to the truth to say that these tests are not 
set up to be performance regression tests and as such they are difficult 
to use as incidential tests for that use case. For example we don't run 
them on machines with well-defined performance characteristics, don't 
make any effort to keep the tests themselves unchanged over time, and 
don't track the test runtime carefully in order to notice regressions. 
Using the test timeout as a threshold is a poor substitute because we 
will miss large regressions that nevertheless allow the test to finish 
inside the timeout, but be indirectly alerted (via intermittency) to 
smaller regressions, or test changes, for tests that were already close 
to the limit.


This isn't to say that we should never care if tests get slower, but 
that isn't a thing that we can reliably determine in our current setup, 
except in very coarse ways that are ineffective at directing engineering 
time onto the most important issues.


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

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

2016-02-10 Thread Marco Bonardo 
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 is not much about catching regressions (even if
that can effectively happen), rather figuring why a test takes 90 seconds
instead of 10, is that a problem that may affect end users too?
The larger we set the threshold, the less people are likely to investigate
the reasons the test takes so much, cause there will be no bugs filed about
the problem. It will just go unnoticed.
Other reasons are bound to costs imo. Developers time is a cost, if
everyone starts writing tests taking more time, cause now the timeout is
much larger, we may double the time to run tests locally or to get results
out of Try.
Finally, bumping timeouts isn't a final solution, that means in a few years
we may be back rediscussing another bump.

I'm not saying bumping the timeout is wrong, I'm saying we should also
evaluate a long term strategy to avoid the downsides. Maybe we should have
something like the orange factor tracking tests runtime (in all the
harnesses) and automatically filing bugs in the appropriate component when
some test goes over a threshold?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MozReview/Autoland in degraded state

2016-02-10 Thread Daniel Minor 
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  wrote:
>
>> r+ carry forward/"status" column is now working again.
>>
>> Autoland / Try integration is still offline.
>>
>> On Fri, Feb 5, 2016 at 12:13 PM, Mark Côté  wrote:
>>
>> > And a little longer than planned, but we're back.  All users, regardless
>> > of level, can once again push code to MozReview.
>> >
>> > As noted, Autoland and r+ carry forward/"status" column will remain
>> > disabled a little while longer, as there are some unrelated issues to
>> > sort out.  We'll report back here when they're back, hopefully Monday.
>> >
>> > Mark
>> >
>> >
>> > On 2016-02-05 1:42 PM, Mark Côté wrote:
>> > > We will be deploying a fix for the ssh-level restrictions to MozReview
>> > > shortly, around 2:30 pm EST/11:30 am PST.  MozReview will be down for
>> > > about 10 minutes if all goes smoothly.  We'll be able to rollback not
>> > > long after that if there are unresolvable issues.  You can follow
>> along
>> > > in #mozreview.
>> > >
>> > > Other fixes to LDAP and Autoland will follow Mondayish.
>> > >
>> > > Thank you for your patience.
>> > >
>> > > Mark
>> > >
>> > >
>> > > On 2016-02-03 3:02 AM, Gregory Szorc wrote:
>> > >> MozReview and Autoland are currently in a degraded state:
>> > >>
>> > >> * HTTP pushes are disabled
>> > >> * SSH pushes require LDAP SCM Level 3 access
>> > >> * Autoland is disabled
>> > >> * r+ carry forward has been disabled / the overall "status" column in
>> > the
>> > >> commits list may not turn green
>> > >>
>> > >> The last bullet point is particularly troubling, as we had to disable
>> > >> something that wasn't designed to be disabled. There may be some
>> weird
>> > >> fallout with review flag / state as a result.
>> > >>
>> > >> Bug 1244835 tracks restoring push access. Bug 1245412 tracks the
>> other
>> > >> issues.
>> > >>
>> > >> Please understand that additional technical details cannot be
>> provided
>> > at
>> > >> this time.
>> > >>
>> > >> We apologize for the inconvenience and hope to have full service
>> > restored
>> > >> as soon as possible.
>> > >>
>> > >
>> >
>> > ___
>> > 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: nsIDOMWindow is deprecated now is there an alternative?

2016-02-10 Thread Kyle Huey 
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 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-10 Thread Kyle Huey 
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-10 Thread Dave Townsend 
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 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 Wed, Feb 10, 2016 at 5:10 PM, Devan Shah  wrote:
>
>> 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
___
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-10 Thread Kyle Huey 
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-10 Thread Kyle Huey 
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 Wed, Feb 10, 2016 at 5:10 PM, Devan Shah  wrote:

> 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-10 Thread Kyle Huey 
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-10 Thread Kyle Huey 
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 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