1011663 - [e10s] Make CPOWs inspectable

Status: RESOLVED WONTFIX

(DevTools :: Debugger, defect)

Description

[Allison Naaktgeboren :ally]

In multiprocess firefox, Cross Process Object Wrappers (CPOWs) are used in a number of places. I have noticed that some cpows properties are opaque to the browser toolbox.

- It would be awesome to see what those objects contain
- It would be awesome if background color or something changed to visually indicate that this object is a CPOW 
- It would be awesome if I could also attach a debugger to the child/content process. Currently it only attaches to the chrome/parent process

We'll be pushing addon developers to update their code for multiprocess firefox and I'd love for our tools to make it easier to puzzle out what's going on

Comment 1

[Tom S [:evilpie]]

I totally agree, making developers aware that they are using CPOWs is a good idea.
>- It would be awesome if I could also attach a debugger to the child/content process. Currently it only > attaches to the chrome/parent process
I opened bug 1011677 for that, because it's a bit different from the rest.

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

What kind of properties are opaque? How can I tell from chrome JS that a debuggee object is a CPOW without running debuggee code? I read that CPOWs for DOM objects have a remote="true" attribute, but what about plain JS objects?

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

We don't have a way to distinguish CPOWs from normal objects right now, but it sounds like we definitely need something for that. (CPOWs for DOM objects don't have a remote="true" attribute. That's only true for the <xul:browser> element, which is not a CPOW.)

I don't know why properties don't show up though.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Bug 1014993 should make this easier. It exposes Cu.isCrossProcessWrapper to test if something is a CPOW.

Comment 5

[Chris Peterson [:cpeterson]]

These DevTools bugs should probably block e10s from riding to Aurora.

Comment 6

[Chris Peterson [:cpeterson]]

harthur says these DevTools bugs are not Aurora blockers for e10s.

Comment 7

[Joe Walker [:jwalker]]

This is a new feature, it shouldn't block e10s.

Comment 8

[Joe Walker [:jwalker]]

Removing [e10s-m7] flag. We're agreed that this shouldn't block e10s

Comment 9

[Eddy Bruel [:ejpbruel]]

I'm curious why this was resolved as wontfix? Is it no longer necessary to inspect CPOWS?

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Eddy Bruel [:ejpbruel] from comment #9)
> I'm curious why this was resolved as wontfix? Is it no longer necessary to
> inspect CPOWS?

CPOWs are disallowed in browser code and eventually will be in add-on code, so implementing inspection of them doesn't seem to be worth the effort. However, if someone wants to work on this we can reopen it and prioritize it very low.