If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[e10s] Expose process information in nsITabParent

RESOLVED FIXED in Firefox 51

Status

()

Core
DOM
P4
normal
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: snorp, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
mozilla51
Points:
---

Firefox Tracking Flags

(e10s+, firefox51 fixed)

Details

(Whiteboard: [e10s-multi:M1])

Attachments

(1 attachment)

It might be nice to know which tabs are in which content processes. It seems like nsITabParent would be a good way to expose that to the frontend.
tracking-e10s: --- → +
I think a nice way to do this would be to link the frame message manager with the process message manager. That fits well with our existing abstractions.

Comment 2

2 years ago
How could you link fmm to pmm?
There are process specific process mms underneath global process message manager, and frame mms are children of window level mm.

Do you mean there would be fmm.processManager or some such ?
Yes. If |fmm| is a leaf-level frame message manager, then fmm.processMessageManager would link to a leaf-level process message manager.
Hey snorp, I'm not sure what your end-game is here, but it might be sufficient to know the "child ID" for each tab, as opposed to the process ID.

You can access the childID off of the frameloader: https://dxr.mozilla.org/mozilla-central/rev/8cb42e7a16b42162c9930f37b9e1f820c2eb126b/dom/base/nsIFrameLoader.idl#187

Accessed like so:

tab.linkedBrowser.frameLoader.childID

Updated

2 years ago
Priority: -- → P4
Blocks: 1207306
Whiteboard: [e10s-multi:M1]
I'd like this API so I could figure out which plugin-container to debug when a tab is hung. I've got a hung tab right now and I don't know how to map that to a process. (I also mused a while back that I'd like an API so I could write a "restart this tab's process" extension.)
Created attachment 8775589 [details] [diff] [review]
expose processId on nsITabParent. v1

(In reply to Bill McCloskey (:billm) from comment #1)
> I think a nice way to do this would be to link the frame message manager
> with the process message manager. That fits well with our existing
> abstractions.

I'm not sure why would we need to do that here... It seems like we just need the process ID of the child on the parent side which is already available, or am I missing something?
Attachment #8775589 - Flags: review?(wmccloskey)
Comment on attachment 8775589 [details] [diff] [review]
expose processId on nsITabParent. v1

Review of attachment 8775589 [details] [diff] [review]:
-----------------------------------------------------------------

I guess this solves Ted's problem. I don't really like using OS PIDs because they can be reused. But that's the only way we're going to solve Ted's problem.

::: dom/interfaces/base/nsITabParent.idl
@@ +53,5 @@
>    void suppressDisplayport(in bool aEnabled);
>  
>    readonly attribute uint64_t tabId;
>  
> +  readonly attribute int32_t processId;

Let's call this osPid.
Attachment #8775589 - Flags: review?(wmccloskey) → review+

Comment 8

a year ago
Pushed by gkrizsanits@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3db67e31e84d
Expose OS Pid in nsITabParent. r=billm

Comment 9

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/3db67e31e84d
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.