Closed Bug 962314 Opened 6 years ago Closed 6 years ago

Create nsIXULAppinfo.processID for obtaining Firefox PID

Categories

(Toolkit :: General, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: mikeperry, Assigned: Brade)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tor])

Attachments

(1 file)

The Tor Launcher addon (which we use for Tor process management in Tor Browser) needs to know the current process ID of Firefox in a cross platform way. We created a getter for this purpose and exported it from nsIXULAppInfo.

Patch against FF24ESR is attached.
Product: Firefox → Toolkit
Comment on attachment 8363285 [details] [diff] [review]
0001-Add-processID-API-to-nsXULAppInfo.patch

In theory nsIProcess already exposes a pid, but I'm not we have any way to get such a representation for a Gecko process. Seems reasonable to me, but over to Benjamin.
Attachment #8363285 - Flags: review?(benjamin)
Assignee: nobody → brade
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
Comment on attachment 8363285 [details] [diff] [review]
0001-Add-processID-API-to-nsXULAppInfo.patch

The NS_ENSURE_ARG_POINTER is silly for an outparam, please remove it. r=me with that change
Attachment #8363285 - Flags: review?(benjamin) → review+
Whiteboard: [tor]
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> Comment on attachment 8363285 [details] [diff] [review]
> 0001-Add-processID-API-to-nsXULAppInfo.patch
> 
> The NS_ENSURE_ARG_POINTER is silly for an outparam, please remove it. r=me
> with that change


bsmedberg:  Can you clarify?  I prefer to keep NS_ENSURE_ARG_POINTER in case callers pass NULL (as is done in GetProcessType()).  Lots of existing code has these checks.
Because this is an attribute in the IDL, JS callers can't pass NULL and it's a programming error for c++ callers to pass null. If somebody does this they should crash.
https://hg.mozilla.org/mozilla-central/rev/0086975029c3
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Is there a reason this had to land directly on m-c?
Flags: needinfo?(brade)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #6)
> Is there a reason this had to land directly on m-c?

Probably not.  Should I have pushed it to mozilla-inbound instead?
Flags: needinfo?(brade)
Duplicate of this bug: 939336
Blocks: meta_tor
You need to log in before you can comment on or make changes to this bug.