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