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
