HTML and CSS provide awesome layout potential, but harnessing that potential to do your bidding can sometimes be problematic.\u00a0 I suspect all people who have written HTML documents have been in a situation where they have randomly permuted the document structure and CSS of something that should work in the hopes of evolving it into something that actually does work.\u00a0 Matching wits with a black box that is invulnerable to even pirate-grade profanity is generally not a pleasant experience.<\/p>\n
It turns out gecko has a way to let you see inside that black box.\u00a0 Well, actually, multiple ways.\u00a0 There’s a layout debugger<\/a> (that seems broken on trunk?) that can display visual overlays for box sizes\/events\/reflow counts, dump info about paints\/invalidations\/events as they happen as well as dumping the current content tree and frames.\u00a0 Even better, gecko’s frame reflow debugging mechanism<\/a> will dump most of the inputs and outputs of each stage of reflow calculations as they happen.\u00a0 With some comparatively minor patches[1] we can augment this information so that we can isolate reflow decisions to their origin presentation shell\/associated URL and so that we know the tag name, element id, and class information on HTML nodes subjected to reflow calculations.\u00a0 A reasonably sane person would want to do this if they were planning to be doing a lot of potentially complicated HTML layout work and would a) benefit from better understanding how layout actually works, b) not want to propagate layout cargo culting or its ilk from the code being replaced, c) not want to waste days of their lives later the next time this happens, d) help locate and fix layout bugs if bugs they be so that all might benefit.<\/p>\n Of course, with logs that effectively amount to execution traces, examining them by hand is frequently intractable unless you really know what you’re looking for or are dealing with a toy example.\u00a0 My non-reduced problem case resulted in 58,107 lines, for one.\u00a0 So writing a tool is a good idea, and writing it in JS using Jetpack<\/a> doubly so.<\/p>\n In any event, the problem is I am trying to use the flexible box model to create an area of the screen that takes up as much space as possible.\u00a0 In this space I want to be able to house a virtual scrolling widget so I use “overflow: hidden”.\u00a0 Regrettably, when my logic goes to populate the div, the box ends up resizing itself and now the whole page wants to scroll.\u00a0 Very sad.\u00a0 (Things work out okay with an explicitly sized box which is why my unit tests for the virtual scrolling widget pass…)<\/p>\n Let’s formulate a query on the div of interest (which I will conceal) and then see what the first little bit of output is:<\/p>\n This is the general pattern we will see to the reflows.\u00a0 The parent will ask it what size it wants to be and it will usually\u00a0 respond with “ridiculously wide but not so tall”.\u00a0 (Not in this first base case, but the next one responds with a prefsize of “1960,449”, and that’s pixels.) The parent will then perform layout and say “no, you need to be taller than you want to be”, at least until I start cramming stuff in there.<\/p>\n So we skim down the output to find out where things first went off the rails…<\/p>\n Okay, that looks pretty likely to be the area of concern.\u00a0 The parent asked it for its ideal size, so it told it, but then the parent apparently decided to enlarge itself too.\u00a0 That is not what we wanted.\u00a0 We would have been cool if just the scroll #25 enlarged itself (or its block child #26 that corresponds to the same content node but which I have elided because it always says the same thing as its parent #25) since some frame needs to end up holding the overflow coordinate space.<\/p>\n Thus concludes part 1 of our exciting saga.\u00a0 In part 2, we hopefully figure out what the problem is and how to fix it.\u00a0 Lest anyone suggest the root problem is that I am completely off base and am not remotely reasonably sane for choosing this as a strategy to solve the problem… it works in chrome.\u00a0 Which is not to say that my html\/css is correct and firefox’s layout is wrong; it’s quite possible for layout engines to err or deal with unspecified behaviour cases in my favor, after all.\u00a0 But it does make me want to understand what the layout engine is thinking and be able to do so with a minimum of effort in the future, since I doubt this is the last time I will not immediately understand the problem or that layout engines will differ in their behaviour.<\/p>\n For those who want to play along at home: the raw gzip’d \/tmp\/framedebug<\/a> file (gunzip to \/tmp\/framedebug) that is the entirety of the trunk firefox log with debug output, the spliced output just for the one window<\/a> derived from an invocation of “cfx run splice” (it will show up under the URL in \/tmp\/framedumps), and the output of the output of “cfx run summarize serial-12-0 summarize unique 22,24,25,26<\/a>.\u00a0 Those unique identifiers are deterministic but arbitrary values for the given file.\u00a0 We discovered them by using the query on the CSS class using “cfx run summarize serial-12-0 summarize class wlib-wlib-virt-wlib-virt-container-root”.\u00a0 The hg repo for the processing tool is here<\/a>, the mozilla-central patches are: first<\/a> and second<\/a>.\u00a0 A minor jetpack patch<\/a> is also required for the command line stuff to work.<\/p>\n 1: I was initially trying to avoid patching anything.\u00a0 This didn’t work out, but it did cause the initial log file splicing logic to leverage the arena allocation scheme of presentation shells to allow us to to map frames back to their URLs.\u00a0 Sadly, it turned out the arena allocation blocks requested from the upstream allocators are really small (4k or 1k) and all from the same source and so I had to instrument the allocation as well as adding debug output of the window\/docshell\/presshell linkages.\u00a0 The output adds an unacceptable additional level of noise to the default DEBUG case; the right thing to do is likely to cause the reflow log debugging to emit the document URL before each logging outburst if it is different from the last outburst.<\/p>\n","protected":false},"excerpt":{"rendered":" HTML and CSS provide awesome layout potential, but harnessing that potential to do your bidding can sometimes be problematic.\u00a0 I suspect all people who have written HTML documents have been in a situation where they have randomly permuted the document … Continue reading *** Box 24 tag:div id: classes:default-bugzilla-ui-bug-page-runBox\r\n*** scroll 25 tag:div id: classes:default-bugzilla-ui-bug-page-runs\r\nscroll 25 variant 1 (parent 24) first line 406\r\n why: GetPrefSize\r\n inputs: boxAvail: 0,UC\r\n boxLast: 0,0\r\n reflowAvailable: 0,UC\r\n reflowComputed: 0,UC\r\n reflowExtra: dirty v-resize\r\n output: prefWidth: 0\r\n minWidth: 0\r\n reflowDims: 0,0\r\n prefSize: 0,0\r\n minSize: 0,0\r\n maxSize: UC,UC\r\n parent concluded: minSize: 0,0\r\n maxSize: UC,UC\r\n prefSize: 2,0\r\nscroll 25 variant 2 (parent 24) first line 406\r\n why: Layout\r\n inputs: boxAvail: 771,1684\r\n boxLast: 0,0\r\n reflowAvailable: 771,UC\r\n reflowComputed: 771,1684\r\n reflowExtra: dirty dirty-children h-resize v-resize\r\n output: prefSize: 0,0\r\n minSize: 0,0\r\n maxSize: UC,UC\r\n reflowDims: 771,1684\r\n layout: 2,0,771,1684\r\n parent concluded: minSize: 0,0\r\n maxSize: UC,UC\r\n prefSize: 0,0\r\n layout: 0,0,773,1684\r\n<\/pre>\n
scroll 25 variant 16 (parent 24) first line 20548\r\n why: GetPrefSize\r\n inputs: boxAvail: 1960,UC\r\n boxLast: 771,1686\r\n reflowAvailable: 1960,UC\r\n reflowComputed: 1960,UC\r\n reflowExtra: dirty-children h-resize v-resize\r\n output: prefWidth: 1960\r\n minWidth: 352\r\n reflowDims: 1960,1755\r\n prefSize: 1960,1755\r\n minSize: 352,1755\r\n maxSize: UC,UC\r\n parent concluded: minSize: 0,0\r\n maxSize: UC,UC\r\n prefSize: 1962,1755\r\nscroll 25 variant 17 (parent 24) first line 20548\r\n why: Layout\r\n inputs: boxAvail: 771,1755\r\n boxLast: 1960,1755\r\n reflowAvailable: 771,UC\r\n reflowComputed: 771,1755\r\n reflowExtra: dirty-children h-resize\r\n output: prefSize: 0,0\r\n minSize: 352,1755\r\n maxSize: UC,UC\r\n reflowDims: 771,1755\r\n layout: 2,0,771,1755\r\n parent concluded: minSize: 0,0\r\n maxSize: UC,UC\r\n prefSize: 0,0\r\n layout: 0,0,773,1755\r\n<\/pre>\n