Closed
Bug 1234583
Opened 8 years ago
Closed 8 years ago
[e10s] Expose process information in nsITabParent
Categories
(Core :: DOM: Core & HTML, defect, P4)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla51
People
(Reporter: snorp, Unassigned)
References
Details
(Whiteboard: [e10s-multi:M1])
Attachments
(1 file)
3.87 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•8 years ago
|
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•8 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.
Comment 4•8 years ago
|
||
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•8 years ago
|
Priority: -- → P4
Updated•8 years ago
|
Blocks: e10s-multi
Updated•8 years ago
|
Whiteboard: [e10s-multi:M1]
Comment 5•8 years ago
|
||
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.)
Comment 6•8 years ago
|
||
(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+
Pushed by gkrizsanits@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/3db67e31e84d Expose OS Pid in nsITabParent. r=billm
Comment 9•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3db67e31e84d
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox51:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•