Wow, this is great! I just ran into this problem a week ago and it was
quite annoying to work around. Thanks for fixing it. :-)

bholley

On Tue, Oct 3, 2017 at 4:15 PM, Matthew N. <ma...@mozilla.com> wrote:

> With bug 1401343 <https://bugzilla.mozilla.org/show_bug.cgi?id=1401343>
> fixed, `TabChildGlobal`s for the attached content process are exposed via a
> `tabs` getter in the Browser Content Toolbox's console tab. This makes it
> much easier to inspect a remote tab's state or to access privileged APIs
> related to remote tab content. The motivation for this change is to make it
> less tedious to inspect remote tab state with e10s, especially without
> add-on shims/CPOWs.
>
> For those of you who don't know, when the "devtools.chrome.enabled" pref is
> true the Web Developer > Browser Content Toolbox opens a toolbox targeting
> the content process that the selected tab is loaded in. From there you can
> access `tabs` in the Console tab to get an array of the `TabChildGlobal`s
> (which have access to the content Window object via `content`).
>
> Examples:
> 1) Access a ChromeOnly property on an element: `tabs[0].content.document.
> querySelector("#myEl").nodePrincipal`
> 2) Add an event listener to a tab child:
> `tabs[3].addEventListener("change", tabs[3].console.log)`
>
> Bug 1346316 <https://bugzilla.mozilla.org/show_bug.cgi?id=1346316> tracks
> giving easier access to the selected tab's TabChildGlobal and making the
> frame picker work (to more easily change between `TabChildGlobal`s by URL).
>
> Happy debugging!
> Matthew Noorenberghe (:MattN)
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to