Re: Dump frame tree in real time

[Botond Ballo]

On Wed, Apr 20, 2016 at 5:50 AM, Jip de Beer  wrote:
> Thanks. I'm aware that it's a privileged API. It seemed Botond was offering a 
> workaround.

In my testing, I used it in the Browser Console (as opposed to the Web
Console), which can access privileged APIs.

As you were the one who brought up
CanvasRenderingContext2D.drawWindow(), I assumed that it was something
you could use in spite of it being privileged (for example, that you
would be calling it from an add-on).

> I've posted my updated question in +mozilla.dev.tech.layout: 
> https://groups.google.com/forum/#!topic/mozilla.dev.tech.layout/MClwXlzk5qM

I'll answer it there.

Cheers,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Jip de Beer]

Thanks. I'm aware that it's a privileged API. It seemed Botond was offering a 
workaround.

Anyhow, because of all your help I was able to dump the Frame Tree (not in real 
time). But I also learned the frame tree doesn't contain all the information I 
need. Especially the z-order information.

The z-order information is included in the display-lists. These can already be 
dumped in real time, which is great. But they only contain the frames within 
the viewport, and I want this data on all frames within the document.

I've posted my updated question in +mozilla.dev.tech.layout: 
https://groups.google.com/forum/#!topic/mozilla.dev.tech.layout/MClwXlzk5qM

On Tuesday, 19 April 2016 15:49:40 UTC+2, Gijs Kruitbosch  wrote:
> On 19/04/2016 14:41, Jip de Beer wrote:
> > I followed your steps exactly and uses this code to add a canvas on a page 
> > with jQuery:
> >
> >  var myCanvas = document.createElement('canvas');
> >  var width = $(document).width()
> >  myCanvas.width = width;
> >  var height = $(document).height()
> >  myCanvas.height = height;
> >  var ctx = myCanvas.getContext("2d");
> >  ctx.drawWindow(window, 0, 0, width, height, "rgba(0, 0, 0, 0)");
> >  console.log(myCanvas.toDataURL());
> >
> > Result:
> > TypeError: ctx.drawWindow is not a function
> >
> > I'm currently trying to figure out how to make Firefox render the entire 
> > page the whole time.
> 
> drawWindow is a privileged API and you would need to use an add-on or 
> Firefox code to call it: 
> https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWindow
> 
> ~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Gijs Kruitbosch]

On 19/04/2016 14:41, Jip de Beer wrote:

I followed your steps exactly and uses this code to add a canvas on a page with 
jQuery:

 var myCanvas = document.createElement('canvas');
 var width = $(document).width()
 myCanvas.width = width;
 var height = $(document).height()
 myCanvas.height = height;
 var ctx = myCanvas.getContext("2d");
 ctx.drawWindow(window, 0, 0, width, height, "rgba(0, 0, 0, 0)");
 console.log(myCanvas.toDataURL());

Result:
TypeError: ctx.drawWindow is not a function

I'm currently trying to figure out how to make Firefox render the entire page 
the whole time.


drawWindow is a privileged API and you would need to use an add-on or 
Firefox code to call it: 
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWindow


~ Gijs

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Jip de Beer]

I followed your steps exactly and uses this code to add a canvas on a page with 
jQuery:

var myCanvas = document.createElement('canvas');
var width = $(document).width()
myCanvas.width = width;
var height = $(document).height()
myCanvas.height = height;
var ctx = myCanvas.getContext("2d");
ctx.drawWindow(window, 0, 0, width, height, "rgba(0, 0, 0, 0)");
console.log(myCanvas.toDataURL());

Result:
TypeError: ctx.drawWindow is not a function

I'm currently trying to figure out how to make Firefox render the entire page 
the whole time.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Jip de Beer]

Hi Botond thanks for replying,

I just checked and calling drawWindow() doesn't output the entire page in the 
display-list dumps. It's as if this operation doesn't trigger the same things a 
regular render operation does.

But your reply got me thinking. If I can force Firefox to always render the 
entire page (instead of the optimized elements currently within the viewport), 
then I have all the information I need in the display-list dumps.

I haven't found a way to do this yet. Can anyone point me to the part of source 
code that chooses which elements to include in the display-list? I'd like to 
override this optimization and include all elements within the document instead.

> Op 16 apr. 2016 om 01:45 heeft Botond Ballo  het volgende 
> geschreven:
> 
>> On Fri, Apr 15, 2016 at 4:32 AM, Jip de Beer  wrote:
>> Thanks for the reply. My problem with display lists is that they only 
>> contain this information about nodes within the viewport. I'm interested in 
>> all nodes that take up space within the document.
>> 
>> I know Firefox can calculate the necessary information for nodes outside of 
>> the viewport because I can take a screenshot of the entire page with 
>> CanvasRenderingContext2D.drawWindow() and it correctly renders the entire 
>> page (also outside of the viewport).
> 
> If it renders the entire page, it must build a display list for the
> entire page. Can you get a display list dump from that operation?
> 
> Cheers,
> Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Jip de Beer]

Great to hear you got this working! I'll carefully follow your steps and see if 
I can get it to work too.

The downside of this approach seems that I can't easily filter out the dumps of 
the entire page. I'm only interested in the dumps from the whole page, not the 
ones from the viewport. But they both end up together in standard error.

I think I still need to investigate how to force rendering of the entire page 
at all times.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Botond Ballo]

On Mon, Apr 18, 2016 at 2:06 PM, Jip de Beer  wrote:
> I just checked and calling drawWindow() doesn't output the entire page in the 
> display-list dumps. It's as if this operation doesn't trigger the same things 
> a regular render operation does.

It worked for me. Here's what I did specifically:

  1. Ran Firefox Nightly.
  2. Switched to non-e10s mode (just to be able to play around with
  CanvasRenderingContext2D.drawWindow() more easily).
  3. Went to about:config and turned on the pref "layout.display-list.dump".
  4. Opened Developer Tools, and in settings, checked "Enable browser chrome
  and add-on debugging toolboxes" and "Enable remote debugging".
  5. Opened the Browser Toolbox (from Tools -> Web Developer).
  6. Loaded a page that's vertically scrollable.
  7. In the Inspector tab of the Browser Toolbox, added a canvas
element to the page.
  8. In the Console tab of the Browser Toolbox, ran
context.drawWindow(content, 0, 0, x, y, "rgba(0, 0, 0, 0)");
  where "context" was the context of the canvas element I added, and "y" was
  some height larger than my browser window's height.

The result was a display list dump for the entire rectangle (0, 0, x,
y) being printed to
standard error, including areas not visible in the browser window.

If you're seeing different behaviour, we should investigate why.

Hope that helps,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Jip de Beer]

Hi Botond thanks for replying,

I just checked and calling drawWindow() doesn't output the entire page in the 
display-list dumps. It's as if this operation doesn't trigger the same things a 
regular render operation does.

But your reply got me thinking. If I can force Firefox to always render the 
entire page (instead of the optimized elements currently within the viewport), 
then I have all the information I need in the display-list dumps.

I haven't found a way to do this yet. Can anyone point me to the part of source 
code that chooses which elements to include in the display-list? I'd like to 
override this optimization and include all elements within the document instead.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Botond Ballo]

On Fri, Apr 15, 2016 at 4:32 AM, Jip de Beer  wrote:
> Thanks for the reply. My problem with display lists is that they only contain 
> this information about nodes within the viewport. I'm interested in all nodes 
> that take up space within the document.
>
> I know Firefox can calculate the necessary information for nodes outside of 
> the viewport because I can take a screenshot of the entire page with 
> CanvasRenderingContext2D.drawWindow() and it correctly renders the entire 
> page (also outside of the viewport).

If it renders the entire page, it must build a display list for the
entire page. Can you get a display list dump from that operation?

Cheers,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Boris Zbarsky]

On 4/14/16 10:52 AM, Jip de Beer wrote:

The Frame Dump doesn't contain any information about z-order.


That information is not stored in the frame tree, really.  It's computed 
during display list construction.



How can I know which nodes are in front of other nodes?


The answer, in general, is that two nodes may not be "in front" of each 
other at all.  That is, parts of one node may be in front of parts of 
the other while other parts are behind it.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Jip de Beer]

Unfortunately Dump -> Frames using the Layout Debugger doesn't give me the 
information I'm looking for.

I would like to access the following information about all visible DOM nodes 
(nodes that take up space in the document):
- z-order
- position
- dimensions

The Frame Dump doesn't contain any information about z-order. How can I know 
which nodes are in front of other nodes?

On Saturday, 9 April 2016 09:05:09 UTC+2, Jip de Beer  wrote:
> Hi Daniel,
> 
> Thanks for the info. Thanks to your instructions I was able to find the 
> Layout Debugger Jeff mentioned. I forgot to add that I did add the debug 
> option in .mozconfig when building the nightly.
> 
> This was the full .mozconfig file
> # Define where build files should go. This places them in the directory
> # "obj-ff-dbg" under the current source directory
> mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-dbg
> 
> # -s makes builds quieter by default
> # -j4 allows 4 tasks to run in parallel. Set the number to be the amount of
> # cores in your machine. 4 is a good number.
> mk_add_options MOZ_MAKE_FLAGS="-s -j4"
> 
> # Enable debug builds
> ac_add_options --enable-debug
> 
> I probably messed things up on my second attempt to build it. So no need to 
> report a build error.
> 
> My use case for the Frame Tree is to visualize it in real time. So it would 
> be great if I can somehow dump it from the main Firefox browser (not the 
> Layout Debugger) without the need to press a button for each dump. Then I can 
> analyze these dumps in real time using Node.js listening to stdout or 
> stderror.
> 
> Another option would be to make a Firefox addon which has access to the Frame 
> Tree. But then I somehow need to make the Frame Tree accessible to addons or 
> JavaScript. Sounds more complicated then dumping to the terminal.
> 
> On Saturday, 9 April 2016 01:56:20 UTC+2, Daniel Holbert  wrote:
> > On 04/08/2016 02:55 PM, Daniel Holbert wrote:
> > > On 04/08/2016 10:38 AM, Jip de Beer wrote:
> > >> I didn't manage to dump the Frame Tree using lldb... I followed these 
> > >> guides:
> > > [...]
> > >> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran 
> > >> lldb from Terminal as well as Xcode).
> > >> I was able to attach lldb to the browser, but not output a Frame Tree 
> > >> dump.
> > >> The code for the nightly build was unmodified. When I tried to define 
> > >> DEBUG_FRAME_DUMP in layout/generic/nsFrameList.h (by uncommenting a 
> > >> block of code) the build failed.
> > > 
> > > Please report that build failure as a bug with more details!  We likely
> > > are accidentally intermixing assumptions about #ifdef DEBUG and #ifdef
> > > DEBUG_FRAME_DUMP or something
> > 
> > (BTW, I tested this locally, and I didn't hit any build failures. So I
> > may be doing something different from you, and I'm not as sure there's a
> > real build-error bug hiding here after all -- it's possible you were
> > tripping over an unrelated build error of some sort.  But, if you can
> > still reproduce this build error, please do report it (including details
> > on the change that you made and the build error output), here:
> > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Layout
> > )
> > 
> > Anyway, as noted in my previous email, even if this nsFrameList.h tweak
> > works, the better-supported interactive way to get frametree dumps is to
> > generate a build with ac_add_options --enable-debug in your mozconfig,
> > and to use the layout debugger's "Dump" menu.  We conceivably *could*
> > add instrumentation to normal builds, but this would require shipping
> > extra Gecko code that a vanishingly small subset of users would actually
> > benefit from, so it doesn't seem worth it.  Depending on the use case,
> > it might be better to just write & expose a more generic
> > element-bounding-box-dumping tool in devtools.
> > 
> > ~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Jip de Beer]

Hi Daniel,

Thanks for the info. Thanks to your instructions I was able to find the Layout 
Debugger Jeff mentioned. I forgot to add that I did add the debug option in 
.mozconfig when building the nightly.

This was the full .mozconfig file
# Define where build files should go. This places them in the directory
# "obj-ff-dbg" under the current source directory
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-dbg

# -s makes builds quieter by default
# -j4 allows 4 tasks to run in parallel. Set the number to be the amount of
# cores in your machine. 4 is a good number.
mk_add_options MOZ_MAKE_FLAGS="-s -j4"

# Enable debug builds
ac_add_options --enable-debug

I probably messed things up on my second attempt to build it. So no need to 
report a build error.

My use case for the Frame Tree is to visualize it in real time. So it would be 
great if I can somehow dump it from the main Firefox browser (not the Layout 
Debugger) without the need to press a button for each dump. Then I can analyze 
these dumps in real time using Node.js listening to stdout or stderror.

Another option would be to make a Firefox addon which has access to the Frame 
Tree. But then I somehow need to make the Frame Tree accessible to addons or 
JavaScript. Sounds more complicated then dumping to the terminal.

On Saturday, 9 April 2016 01:56:20 UTC+2, Daniel Holbert  wrote:
> On 04/08/2016 02:55 PM, Daniel Holbert wrote:
> > On 04/08/2016 10:38 AM, Jip de Beer wrote:
> >> I didn't manage to dump the Frame Tree using lldb... I followed these 
> >> guides:
> > [...]
> >> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran 
> >> lldb from Terminal as well as Xcode).
> >> I was able to attach lldb to the browser, but not output a Frame Tree dump.
> >> The code for the nightly build was unmodified. When I tried to define 
> >> DEBUG_FRAME_DUMP in layout/generic/nsFrameList.h (by uncommenting a block 
> >> of code) the build failed.
> > 
> > Please report that build failure as a bug with more details!  We likely
> > are accidentally intermixing assumptions about #ifdef DEBUG and #ifdef
> > DEBUG_FRAME_DUMP or something
> 
> (BTW, I tested this locally, and I didn't hit any build failures. So I
> may be doing something different from you, and I'm not as sure there's a
> real build-error bug hiding here after all -- it's possible you were
> tripping over an unrelated build error of some sort.  But, if you can
> still reproduce this build error, please do report it (including details
> on the change that you made and the build error output), here:
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Layout
> )
> 
> Anyway, as noted in my previous email, even if this nsFrameList.h tweak
> works, the better-supported interactive way to get frametree dumps is to
> generate a build with ac_add_options --enable-debug in your mozconfig,
> and to use the layout debugger's "Dump" menu.  We conceivably *could*
> add instrumentation to normal builds, but this would require shipping
> extra Gecko code that a vanishingly small subset of users would actually
> benefit from, so it doesn't seem worth it.  Depending on the use case,
> it might be better to just write & expose a more generic
> element-bounding-box-dumping tool in devtools.
> 
> ~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Daniel Holbert]

On 04/08/2016 02:55 PM, Daniel Holbert wrote:
> On 04/08/2016 10:38 AM, Jip de Beer wrote:
>> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
> [...]
>> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran 
>> lldb from Terminal as well as Xcode).
>> I was able to attach lldb to the browser, but not output a Frame Tree dump.
>> The code for the nightly build was unmodified. When I tried to define 
>> DEBUG_FRAME_DUMP in layout/generic/nsFrameList.h (by uncommenting a block of 
>> code) the build failed.
> 
> Please report that build failure as a bug with more details!  We likely
> are accidentally intermixing assumptions about #ifdef DEBUG and #ifdef
> DEBUG_FRAME_DUMP or something

(BTW, I tested this locally, and I didn't hit any build failures. So I
may be doing something different from you, and I'm not as sure there's a
real build-error bug hiding here after all -- it's possible you were
tripping over an unrelated build error of some sort.  But, if you can
still reproduce this build error, please do report it (including details
on the change that you made and the build error output), here:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Layout
)

Anyway, as noted in my previous email, even if this nsFrameList.h tweak
works, the better-supported interactive way to get frametree dumps is to
generate a build with ac_add_options --enable-debug in your mozconfig,
and to use the layout debugger's "Dump" menu.  We conceivably *could*
add instrumentation to normal builds, but this would require shipping
extra Gecko code that a vanishingly small subset of users would actually
benefit from, so it doesn't seem worth it.  Depending on the use case,
it might be better to just write & expose a more generic
element-bounding-box-dumping tool in devtools.

~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Daniel Holbert]

On 04/08/2016 10:38 AM, Jip de Beer wrote:
> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
[...]
> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran lldb 
> from Terminal as well as Xcode).
> I was able to attach lldb to the browser, but not output a Frame Tree dump.
> The code for the nightly build was unmodified. When I tried to define 
> DEBUG_FRAME_DUMP in layout/generic/nsFrameList.h (by uncommenting a block of 
> code) the build failed.

Please report that build failure as a bug with more details!  We likely
are accidentally intermixing assumptions about #ifdef DEBUG and #ifdef
DEBUG_FRAME_DUMP or something

Anyway -- as it seems you noticed, our frametree-dumping code is guarded
by that exact #define -- DEBUG_FRAME_DUMP -- which means the code is not
present in any of the builds that you tested. (Firefox, Nightly,
DevEdition.)  So, the code is only present in debug builds, or builds
with MOZ_DUMP_PAINTING enabled at compile-time.

Your best bet is probably to:
 (1) Build or download a debug version of Firefox. (If you build it
yourself, put ac_add_options --enable-debug in your .mozconfig. Or, you
can download a debug build from today at
http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-macosx64-debug/1460109722/
)

 (2) Start the layout debugger (Tools|Layout Debugger) -- this menu
option is only present in debug builds.

 (3) Load whatever site you want in the tiny layout-debugger browser
that appears (with minimal-UI)

 (4) Dump the frame tree (to your terminal) using Dump|Frames in the
layout debugger window.

~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dump frame tree in real time

[Jeff Muizelaar]

Check out 
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Layout_Debugger.
I expect it gets the information that you're looking for.

-Jeff

On Fri, Apr 8, 2016 at 1:38 PM, Jip de Beer  wrote:
> Hi all,
>
> I would like to inspect the Frame Tree (or Render Tree: 
> http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#Render_tree_construction)
>  in real time while browsing with Firefox.
>
> I first tried to access this tree with JavaScript or a browser addon. It 
> seems that this information is not accessible at this level. With 
> document.elementFromPoint() or document.elementsFromPoint() in Chrome it may 
> be possible to re-construct the Frame Tree but this is not optimal. Another 
> way I tried to approach this is the re-implement the CSS stacking mechanism 
> in JavaScript (https://github.com/Jip-Hop/visuallyOnTop). But this is slow, 
> redundant and needs to be maintained as behavior changes.
>
> I looked around in about:config. The closest thing I found was enabling 
> layout.display-list.dump. With Firefox launched from the Terminal, the 
> display-list is dumped in real time. It's almost what I need except that this 
> is only output for elements visible in the viewport. I need to inspect the 
> entire Frame Tree.
>
> The next thing I tried was installing FirefoxDeveloperEdition, hoping this 
> version would somehow have extra tools to access this data. But it seems this 
> version of Firefox is oriented towards debugging websites. Dumping the Frame 
> Tree is probably possible when debugging the browser itself (Debugging Gecko 
> Core).
>
> I read here: 
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Debugging_a_Performance_Problem#Layout_Debugging
>  that I could enable this functionality by defining DEBUG_FRAME_DUMP in 
> layout/generic/nsFrameList.h. So I downloaded the Firefox source (nightly), 
> built Firefox Nightly and tried to dump the Frame Tree.
>
> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
> http://mcc.id.au/blog/2014/01/lldb-gecko
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_on_Mac_OS_X
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_Mozilla_with_lldb
> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran lldb 
> from Terminal as well as Xcode).
> I was able to attach lldb to the browser, but not output a Frame Tree dump.
> The code for the nightly build was unmodified. When I tried to define 
> DEBUG_FRAME_DUMP in layout/generic/nsFrameList.h (by uncommenting a block of 
> code) the build failed.
> I noticed when debugging with lldb, the browser hangs until I quit lldb. I 
> want to dump and inspect the Frame Tree in real time. So locking the browser 
> with a debugger like lldb may not be the way to go after all.
>
> So what are the possibilities for dumping the Frame Tree in real time? It 
> would be awesome if it could be done from JavaScript in the browser (without 
> being super slow), but logging to a file or outputting to the Terminal in 
> real time are also acceptable solutions. Also it would be great if it's 
> available from the default Firefox or FirefoxDeveloperEdition apps, as it 
> feels like a lot of trouble to make custom builds and edits to enable this 
> functionality.
>
> I'm using the latest versions of Firefox on Mac OS X 10.10.
>
> Looking forward to your replies.
>
> Thanks in advance.
> Jip
> ___
> 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

Dump frame tree in real time

[Jip de Beer]

Hi all,

I would like to inspect the Frame Tree (or Render Tree: 
http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#Render_tree_construction)
 in real time while browsing with Firefox.

I first tried to access this tree with JavaScript or a browser addon. It seems 
that this information is not accessible at this level. With 
document.elementFromPoint() or document.elementsFromPoint() in Chrome it may be 
possible to re-construct the Frame Tree but this is not optimal. Another way I 
tried to approach this is the re-implement the CSS stacking mechanism in 
JavaScript (https://github.com/Jip-Hop/visuallyOnTop). But this is slow, 
redundant and needs to be maintained as behavior changes.

I looked around in about:config. The closest thing I found was enabling 
layout.display-list.dump. With Firefox launched from the Terminal, the 
display-list is dumped in real time. It's almost what I need except that this 
is only output for elements visible in the viewport. I need to inspect the 
entire Frame Tree.

The next thing I tried was installing FirefoxDeveloperEdition, hoping this 
version would somehow have extra tools to access this data. But it seems this 
version of Firefox is oriented towards debugging websites. Dumping the Frame 
Tree is probably possible when debugging the browser itself (Debugging Gecko 
Core).

I read here: 
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Debugging_a_Performance_Problem#Layout_Debugging
 that I could enable this functionality by defining DEBUG_FRAME_DUMP in 
layout/generic/nsFrameList.h. So I downloaded the Firefox source (nightly), 
built Firefox Nightly and tried to dump the Frame Tree.

I didn't manage to dump the Frame Tree using lldb... I followed these guides:
http://mcc.id.au/blog/2014/01/lldb-gecko
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_on_Mac_OS_X
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_Mozilla_with_lldb
I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran lldb 
from Terminal as well as Xcode).
I was able to attach lldb to the browser, but not output a Frame Tree dump.
The code for the nightly build was unmodified. When I tried to define 
DEBUG_FRAME_DUMP in layout/generic/nsFrameList.h (by uncommenting a block of 
code) the build failed.
I noticed when debugging with lldb, the browser hangs until I quit lldb. I want 
to dump and inspect the Frame Tree in real time. So locking the browser with a 
debugger like lldb may not be the way to go after all.

So what are the possibilities for dumping the Frame Tree in real time? It would 
be awesome if it could be done from JavaScript in the browser (without being 
super slow), but logging to a file or outputting to the Terminal in real time 
are also acceptable solutions. Also it would be great if it's available from 
the default Firefox or FirefoxDeveloperEdition apps, as it feels like a lot of 
trouble to make custom builds and edits to enable this functionality.
 
I'm using the latest versions of Firefox on Mac OS X 10.10.

Looking forward to your replies.

Thanks in advance.
Jip
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform