Re: Dump frame tree in real time
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
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
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
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
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
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
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
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
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
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). I don't follow you entirely on this: > The answer, in general, is that two nodes may not be "in front" of each other > at all. Document.elementsFromPoint() can return all nodes at a specific coordinate in 'visual order'. It returns which elements are in front of others. But this is again restricted to the viewport and I don't want it for a specific coordinate, but for all nodes within the document. On Thursday, 14 April 2016 18:03:11 UTC+2, Boris Zbarsky wrote: > 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 On Thursday, 14 April 2016 18:03:11 UTC+2, Boris Zbarsky wrote: > 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
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
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&component=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
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&component=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
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&component=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
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
On Friday, 8 April 2016 20:06:19 UTC+2, Jeff Muizelaar wrote: > 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 Hi Jeff, thanks for the reply. I did look at that page before but I could use some help with understanding it. How can I use it to dump the Frame Tree? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dump frame tree in real time
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
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