Does js-ctypes supports for nsISupports objects.

[Yonggang Luo]

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does js-ctypes supports for nsISupports objects.

[Ted Mielczarek]

No, js-ctypes does not have any support for calling methods on C++
classes. In fact, that functionality was WONTFIXed a while back:
https://bugzilla.mozilla.org/show_bug.cgi?id=505907.

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

Re: Does js-ctypes supports for nsISupports objects.

[Yonggang Luo]

OK, I've done it with my own patch, indeed, I just want to calling C APIs
with
XPCOM pointers.  So I implemented the following function to deal with my
situation:

512020db461367413e46bfeb3af8b70ed45e01f8
 xpcom/components/nsComponentManager.cpp  | 14 ++
 xpcom/components/nsIComponentManager.idl | 11 +++
 2 files changed, 25 insertions(+)

diff --git a/xpcom/components/nsComponentManager.cpp
b/xpcom/components/nsComponentManager.cpp
index c5bcd92..bef39e2 100644
--- a/xpcom/components/nsComponentManager.cpp
+++ b/xpcom/components/nsComponentManager.cpp
@@ -21,6 +21,7 @@
 #include "nsISupports.h"
 #include "nspr.h"
 #include "nsCRT.h" // for atoll
+#include "nsPrintfCString.h"

 // Arena used by component manager for storing contractid string, dll
 // location strings and small objects
@@ -1868,6 +1869,19 @@
nsComponentManagerImpl::SizeOfIncludingThis(mozilla::MallocSizeOf
aMallocSizeOf)
   return n;
 }

+NS_IMETHODIMP nsComponentManagerImpl::GetPointerForInterface(nsISupports
*aInstance, const nsIID & aIID, nsACString & _retval)
+{
+  nsQueryInterface queryInterface(aInstance);
+  void* result = nullptr;
+  nsresult rc = queryInterface(aIID, );
+  if (rc != NS_OK) {
+_retval = "";
+return NS_OK;
+  }
+  _retval = nsPrintfCString("0x%p", result);
+  return NS_OK;
+}
+
 

 // nsFactoryEntry
 

diff --git a/xpcom/components/nsIComponentManager.idl
b/xpcom/components/nsIComponentManager.idl
index 1e5693a..912e11f 100644
--- a/xpcom/components/nsIComponentManager.idl
+++ b/xpcom/components/nsIComponentManager.idl
@@ -40,6 +40,17 @@ interface nsIComponentManager : nsISupports
 in nsIIDRef aIID,
 [iid_is(aIID),retval] out nsQIResult
result);

+/**
+ * getPointerForInterface
+ *
+ * Returns string representation of the pointer for a instance of the
interface
+ *
+ * @param aInstance - The instance of the interface
+ * @param aIID - IID of interface requested
+ * @return ACString in hex format with "0x" prepended, or empty if the
instance have no aIID
+ */
+ACString getPointerForInterface(in nsISupports aInstance,
+in nsIIDRef aIID);

/**
  * createInstance


On Wed, Dec 23, 2015 at 11:02 PM, Ted Mielczarek  wrote:

> No, js-ctypes does not have any support for calling methods on C++
> classes. In fact, that functionality was WONTFIXed a while back:
> https://bugzilla.mozilla.org/show_bug.cgi?id=505907.
>
> -Ted
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned orange by team

[Ben Kelly]

Thanks for everyone's help!

I did just want to clarify, though, that I don't think anyone should be
changing holiday plans to work these bugs.  We can address them as people
come back from PTO.  Everyone having a good break and holiday is more
important.

Sorry for any confusion and thanks again.  Happy holidays everyone!

Ben

On Tue, Dec 22, 2015 at 8:15 PM, Ben Kelly  wrote:

> Hi all,
>
> In an attempt to wrangle some of the orange plaguing the tree I've tried
> to triage the top unowned bugs by team.
>
> If you are working one of these bugs, please assign yourself to it.  If
> you're not working a bug, but are assigned, please drop it so we can see
> the status.
>
> If you see bugs in your team, please feel free to jump on it.  I'm also
> going to try to track down a manager for each team to see if they can help
> prioritize things.  Of course, the holiday will complicate things, but
> maybe we can get this sorted quickly when we get back from break.
>
> Thanks everyone!
>
> Of the top 30 orange we have only six that are clearly being owned and
> worked by someone.  The rest fall into these rough categories/teams:
>
> memory:
> 1) https://bugzilla.mozilla.org/show_bug.cgi?id=1220517
> 20) https://bugzilla.mozilla.org/show_bug.cgi?id=1218297
>
> addons:
> 4) https://bugzilla.mozilla.org/show_bug.cgi?id=1135866
>
> ateam/releng:
> 5) https://bugzilla.mozilla.org/show_bug.cgi?id=1197950
> 9) https://bugzilla.mozilla.org/show_bug.cgi?id=1198092
> 10) https://bugzilla.mozilla.org/show_bug.cgi?id=1231798
> 17) https://bugzilla.mozilla.org/show_bug.cgi?id=1073442
> 18) https://bugzilla.mozilla.org/show_bug.cgi?id=1204281
> 25) https://bugzilla.mozilla.org/show_bug.cgi?id=1231034
> 30) https://bugzilla.mozilla.org/show_bug.cgi?id=1234416
>
> necko:
> 7) https://bugzilla.mozilla.org/show_bug.cgi?id=1203430
> 12) https://bugzilla.mozilla.org/show_bug.cgi?id=1233774
>
> firefox:
> 8) https://bugzilla.mozilla.org/show_bug.cgi?id=1182072
> 9) https://bugzilla.mozilla.org/show_bug.cgi?id=1230027
>
> e10s:
> 11) https://bugzilla.mozilla.org/show_bug.cgi?id=1230978
>
> dom:
> 14) https://bugzilla.mozilla.org/show_bug.cgi?id=1197786
> 15) https://bugzilla.mozilla.org/show_bug.cgi?id=1227320
> 24) https://bugzilla.mozilla.org/show_bug.cgi?id=1203441
> 27) https://bugzilla.mozilla.org/show_bug.cgi?id=1213633
>
> layout:
> 19) https://bugzilla.mozilla.org/show_bug.cgi?id=1204897
>
> devtools:
> 21) https://bugzilla.mozilla.org/show_bug.cgi?id=992275
> 22) https://bugzilla.mozilla.org/show_bug.cgi?id=1210208
> 23) https://bugzilla.mozilla.org/show_bug.cgi?id=1230031
> 29) https://bugzilla.mozilla.org/show_bug.cgi?id=1209295
>
> android:
> 23) https://bugzilla.mozilla.org/show_bug.cgi?id=1213030
> 28) https://bugzilla.mozilla.org/show_bug.cgi?id=1118268
>
> fxos:
> 24) https://bugzilla.mozilla.org/show_bug.cgi?id=999675
>
> Thanks again for your help with this.
>
> Ben
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned orange by team

[James Graham]

On 23/12/15 01:15, Ben Kelly wrote:

Hi all,

In an attempt to wrangle some of the orange plaguing the tree I've tried to
triage the top unowned bugs by team.

ateam/releng:

[…]

10) https://bugzilla.mozilla.org/show_bug.cgi?id=1231798


This is a web-platform-tests test which is an interesting case. De-facto 
I am on point for all problems in these tests, which is fine, but in 
practice there's a limited amount I can do. If the test is broken in 
some obvious way I can fix it, or I can disable it. In some cases I know 
the feature under test well enough to do something a bit more clever. 
But, in order to get the right fix, it would be better to loop in the 
people in the team responsible for the feature under test rather than 
just considering all wpt failures to ateam's responsibility.

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

Re: unowned orange by team

[J. Ryan Stinnett]

On Tue, Dec 22, 2015 at 7:15 PM, Ben Kelly  wrote:
>
> devtools:
> 21) https://bugzilla.mozilla.org/show_bug.cgi?id=992275
> 22) https://bugzilla.mozilla.org/show_bug.cgi?id=1210208
> 23) https://bugzilla.mozilla.org/show_bug.cgi?id=1230031
> 29) https://bugzilla.mozilla.org/show_bug.cgi?id=1209295

For DevTools, I have ni?ed possible assignees for each (and 1 already
has assignee and patch up for review).

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

Re: Adding jobs to pushes having some issues

[Kartikaya Gupta]

For the record it seems like even if adding new jobs via TH fails, the
old try-extender tool at http://try-extender.herokuapp.com/ still
works (at least for try pushes).

On Tue, Dec 22, 2015 at 2:56 PM, Armen Zambrano G.  wrote:
> Hello team,
> Thanks for using the ability of adding jobs to your pushes from
> Treeherder [1].
>
> I want to point out that some of you are having a great experience and
> others not seeing anything happen or not all jobs being available.
>
> There are some bugs in the code and efforts will be made in January to
> improve the experience.
>
> Alternative you can triggerbyfilters.py from the command line [2].
>
> Until then, feel free to file bugs under Testing::General and CC me.
>
> My apologies for the issues.
>
> regards,
> Armen
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1233807
> https://bugzilla.mozilla.org/show_bug.cgi?id=1234552
>
> [1] http://explique.me/TH/
> [2]
> https://mozilla-ci-tools.readthedocs.org/en/latest/scripts.html#triggerbyfilters-py
>
> --
> Zambrano Gasparnian, Armen
> Automation & Tools Engineer
> http://armenzg.blogspot.ca
> ___
> 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: Does js-ctypes supports for nsISupports objects.

[luoyonggang]

// nsIComponentManager
exports.getPointerForInterface = (obj, iid) => {
  return components.manager.getPointerForInterface(obj, iid)
}

xul.js:
'use strict'

const { Cc, Ci } = require('chrome')

exports.types = require('./types.js')

const {
ctypes,
EnumType,
  default_abi,
  uint32_t
} = exports.types

exports.nsISupports = ctypes.voidptr_t

const xul = ctypes.open('xul.dll')

exports.nsresult = ctypes.uint32_t

exports.NSLocationType = EnumType([
  // 'NS_APP_LOCATION', For bolt 38, doesn't have this yet
  'NS_EXTENSION_LOCATION',
  'NS_SKIN_LOCATION',
  'NS_BOOTSTRAPPED_LOCATION'
], uint32_t)

/*
* XRE_API(nsresult,
* XRE_AddManifestLocation, (NSLocationType aType,
*nsIFile* aLocation))
*/
exports.XRE_AddManifestLocation = xul.declare('XRE_AddManifestLocation', 
default_abi, exports.nsresult,

  exports.NSLocationType.type, // NSLocationType aType
  exports.nsISupports // nsIFile aLocation
)

/*
*
* XRE_API(nsresult,
* XRE_AddJarManifestLocation, (NSLocationType aType,
* nsIFile* aLocation))
*/
exports.XRE_AddJarManifestLocation = 
xul.declare('XRE_AddJarManifestLocation', default_abi, exports.nsresult,

  exports.NSLocationType.type, // NSLocationType aType
  exports.nsISupports // nsIFile aLocation
)

exports.MozFile = (path) => {
  let file = Cc['@mozilla.org/file/local;1']
.createInstance(Ci.nsILocalFile)
  file.initWithPath(path)
  return file.QueryInterface(Ci.nsILocalFile)
}



  const appFile = xul.MozFile(path.join(AppInfo.appCodePath, 
'chrome.manifest'))

  const appFilePtr = getPointerForInterface(appFile, Ci.nsIFile)
  const appFileCtypePointer = 
xul.types.voidptr_t(xul.types.UInt64(appFilePtr))
xul.XRE_AddManifestLocation(xul.NSLocationType.NS_EXTENSION_LOCATION, 
appFileCtypePointer)


在 2015/12/24 00:27, Cameron Kaiser  写道:

   On 12/23/15 8:09 AM, 罗勇刚(Yonggang Luo)  wrote:

>No, js-ctypes does not have any support for calling methods on C++
>classes. In fact, that functionality was WONTFIXed a while back:
>https://bugzilla.mozilla.org/show_bug.cgi?id=505907.

OK, I've done it with my own patch, indeed, I just want to calling
C APIs
with
XPCOM pointers.  So I implemented the following function to deal
with my
situation:

   [...]

+/**
+ * getPointerForInterface
+ *
+ * Returns string representation of the pointer for a
instance of the
interface
+ *
+ * @param aInstance - The instance of the interface
+ * @param aIID - IID of interface requested
+ * @return ACString in hex format with "0x" prepended, or
empty if the
instance have no aIID
+ */
+ACString getPointerForInterface(in nsISupports aInstance,
+in nsIIDRef aIID);


   Interesting. How does your code work in practice?

   Cameron Kaiser

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


- Send from WPS Mail -
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned orange by team

[Johnny Stenback]

On Wed, Dec 23, 2015 at 6:58 AM, James Graham  wrote:
> On 23/12/15 01:15, Ben Kelly wrote:
[...]
>> 10) https://bugzilla.mozilla.org/show_bug.cgi?id=1231798
>
>
> This is a web-platform-tests test which is an interesting case. De-facto I
> am on point for all problems in these tests, which is fine, but in practice
> there's a limited amount I can do. If the test is broken in some obvious way
> I can fix it, or I can disable it. In some cases I know the feature under
> test well enough to do something a bit more clever. But, in order to get the
> right fix, it would be better to loop in the people in the team responsible
> for the feature under test rather than just considering all wpt failures to
> ateam's responsibility.

I would certainly not expect the ateam or yourself to be responsible
for fixing all wpt failures. You should feel empowered to reach out to
engineering leads for areas where you've identified the underlying
implementation most likely being the cause of the failure as opposed
to the test itself or the harness!

And thanks for helping shepherd all these tests, highly valuable work!

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

Re: Emulating WebExtensions

[Bill McCloskey]

On Wed, Dec 23, 2015 at 4:37 AM, Marcello Stanisci <
marcello.stani...@inria.fr> wrote:

> Hi list,
>
> Would it be possible to emulate what the 'backgroud' page does
> in the context of a "normal" Firefox extension by using Web workers?
>
> In detail, WebExtensions dictates that each extension has a background
> thread which runs independently of its foreground counterpart, and that
> they notify each other by sending messages.
>

There are a couple different contexts in which WebExtensions run code:
1. background page
2. popups for things like browser actions and page actions
3. content scripts

#1 and #2 run on the same thread; they can access each other's global
variables directly via functions like getBackgroundPage and getViews. #3
potentially runs in a different process from #1 and #2, so it's a bit
different.


> Web workers are quite the same thing: independent threads which can
> send/receive messages to/from their creators.
>
> So it seems "natural" to have a Web worker active for the extension's
> lifetime which behaves the same way a WebExtension's background script
> does.
>

You could create a Web worker in a WebExtension. But it would be different
from a background page. For one thing, a background page has a normal DOM
even though it's not displayed. So it has access to the full set of DOM
APIs rather than the restricted set available to workers.


> Which kind of problems may arise in implementing the WebExtension's
> semantics in a traditional Firefox extension?
>

Everything WebExtensions do is available to legacy extensions. Our
implementation of WebExtensions is entirely JS code using XPCOM. If you're
interested in how background pages are created, you might look at the
createWindowlessBrowser API:
https://dxr.mozilla.org/mozilla-central/source/xpfe/appshell/nsIAppShellService.idl#56


> Is there any exmple to look at which already does that?
>

You can look at our implementation of background pages:
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/ext-backgroundPage.js#22

I'm not sure if this answers your question. I hope it helps.

-Bill


>
> Thanks
> Marcello
> ___
> 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: Does js-ctypes supports for nsISupports objects.

[Cameron Kaiser]

On 12/23/15 8:09 AM, 罗勇刚(Yonggang Luo)  wrote:

>No, js-ctypes does not have any support for calling methods on C++
>classes. In fact, that functionality was WONTFIXed a while back:
>https://bugzilla.mozilla.org/show_bug.cgi?id=505907.

OK, I've done it with my own patch, indeed, I just want to calling C APIs
with
XPCOM pointers.  So I implemented the following function to deal with my
situation:

[...]

+/**
+ * getPointerForInterface
+ *
+ * Returns string representation of the pointer for a instance of the
interface
+ *
+ * @param aInstance - The instance of the interface
+ * @param aIID - IID of interface requested
+ * @return ACString in hex format with "0x" prepended, or empty if the
instance have no aIID
+ */
+ACString getPointerForInterface(in nsISupports aInstance,
+in nsIIDRef aIID);


Interesting. How does your code work in practice?

Cameron Kaiser

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

Emulating WebExtensions

[Marcello Stanisci]

Hi list,

Would it be possible to emulate what the 'backgroud' page does
in the context of a "normal" Firefox extension by using Web workers?

In detail, WebExtensions dictates that each extension has a background
thread which runs independently of its foreground counterpart, and that
they notify each other by sending messages.

Web workers are quite the same thing: independent threads which can
send/receive messages to/from their creators.

So it seems "natural" to have a Web worker active for the extension's
lifetime which behaves the same way a WebExtension's background script
does.

Which kind of problems may arise in implementing the WebExtension's
semantics in a traditional Firefox extension?

Is there any exmple to look at which already does that?

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