1027310 - Window console feature to execute in chrome context w/devtools.chrome.enabled

Status: NEW

(DevTools :: General, defect)

Description

[John Schoenick [:johns]]

It would be helpful, if chrome debugging is enabled, to have a "context" selection for the per-window console to allow escalation to chrome privileges within the scope of the content window.

I often use the dev tools when hacking on gecko to inspect a page, and find myself needing chrome powers to introspect the behind-the-scenes of various things. This can be done by opening the browser console and then finding your tab -> contentWindow, but adds to the amount of redirection significantly, and doesn't integrate with the other tools (e.g. the jump-to-inspector icon for dom elements)

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

We'll soon have toolbox support to choose different frames for the toolbox to target (bug 977043), so it seems reasonable to extend this also offer chrome access if you have it enabled.

Comment 2

[Alexandre Poirot [:ochameau]]

How do we make a regular TabActor become a "chrome" one, don't we need another different kind of actor?
The frame patch from bug 977043, just change the target docshell, but it keeps the same privileges.
Speaking about that, in e10s world, that would be really great if, in the tab toolbox, we could also debug all chrome scopes of the tab process, like JSM, xpcoms and frame scripts!

Comment 3

[Alexandre Poirot [:ochameau]]

Attachment: Hack to have a chrome toolbox for child processes

So that's really something that will be helpful in e10s firefox
and is also very useful on b2g to debug child process chrome code!
But that highlights that, in order to reuse the existing "chrome" toolbox,
you have to instanciate a different TabActor and also a different target :s

This patch is just a hardcoded demo, and I don't think we want to go that way.
The different kind of target is really painful as it break support
for frame script from bug 977043.

Comment 4

[Alexandre Poirot [:ochameau]]

Ryan, Whereas I can easily see this feature implemented in the UI the same way I implemented bug 977043,
I don't see how to do that behind the scene. Especially if we want to reuse existing chromeDebugger actor and chrome target.
Do you have any implementation idea in mind? Trick to easily reuse that or easily toggle a chrome mode over the toolbox?

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Hmm, maybe not as easy as I hoped then.  I'll keep the ni? for now and see if I can think of something.

Comment 6

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I don't have any great ideas yet, but I will think more about this once Alex lands something in bug 977043.

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

On IRC, Alex mentioned:

<ochameau> jryans: I'm not sure the "chrome" flag on the target and the "ChromeDebugger" actor are really justified, it may be easier to just tune the ThreadActor and make it configurable in chrome mode and make the chrome mode less magic on the target side (today it seems to be completely different codepath everywhere :s)