[webkit-help] Debugging Layout issues with DRT

[SravanKumar Sandela]

Hi ,

Am not sure if some one among you already know this way of debugging, but i
got this idea all of a sudden recently in one of my debugging, and it
helped me a lot. So, sharing this hoping, it helps(especially newbies to
webkit).

I might be wrong in some of the below points, so any one can please feel
free to correct.

The most common part of our debugging effort and some times time consuming
is trying to figure out X,Y and Width and Height of element under test.

Following are the steps:
1.First zero-in on the buggy html element that is creating the problem.
2.Create a small test case demoing the buggy behavior.
3.Now simply copy this in to any of the lay-out test folder and run the
test with following options
Ex: ./Tools/Scripts/new-run-webkit-tests --debug --no-build --no-http
LayoutTests/fast/forms/fieldset-legend-label-style.html
 4.This will run the test and will generate the test result as following

  fast/forms/fieldset-legend-label-style.html -> unexpected text diff
mismatch

Retrying 1 unexpected failure(s) ...

  fast/forms/fieldset-legend-label-style.html -> unexpected text diff
mismatch
0 tests ran as expected, 1 didn't:


Regressions: Unexpected text diff mismatch : (1)
  fast/forms/fieldset-legend-label-style.html = TEXT

5. Dont worry much about mistmatch and all you need to focus on is the
results.html (
file:///C:/cygwin/home/ssandela/WebKit/WebKitBuild/Debug/bin/layout-test-results/results.html)
file that opens automatically.
6. It will have test case and results link, click on the results link
7. All you need now is just understanding the results file. For above
example the result will be in following manner.


layer at (0,0) size 800x600
  RenderView at (0,0) size 800x600
layer at (0,0) size 800x600
  RenderBlock {HTML} at (0,0) size 800x600
    RenderBody {BODY} at (8,8) size 784x576
      RenderBlock {FORM} at (0,0) size 784x19
        RenderFieldSet {FIELDSET} at (2,0) size 780x19 [border: (2px
groove #C0C0C0)]
          RenderBlock {LEGEND} at (14,1) size *86x0*
            RenderBlock (floating) {LABEL} at (2,0) size 82x22
              RenderBlock {INPUT} at (2,6) size 12x13
              RenderText {#text} at (16,0) size 66x20
                text run at (16,0) width 66: "LEGEND".

Note: I have marked problem area in RED Color exclusively and it not by DRT.

8. Following are the tips to understand RenderTree. ( layout information)
RenderTree is self explanatory and position of its child/sub elements is
relative to its parent/container box. Tabbing is used to understand
parent/container box- child relation-ship.
For Ex: {LEGEND} in the following tree is a child of {FIELDSET} Element and
its co-ordinates are (14,1) w.r.t its parent but not origin(0,0), that
means its absolute position is sum of all x-coordinates of its parents,
till we reach no Tab space element(14+2+0+8+0+0).

Note: This height is cumulative height (client height + border + margin)
and some times may not match with the values you see in "size" argument of
RenderBox::setLogicalHeight function.

9. As it is pretty clear that height of {LEGEND} element is 0, the problem
is in computing the height of {LEGEND} element. This should atleast give
you a scope of area to start debugging with.

Width and Height of LEGEND element are at end of line


RenderBlock {LEGEND} at (14,1) size 86x0

  w*h=86*0   i.e, Width = 86, Height =0 and its X and Y are 14,0 relative
to its container box.
I tried running the test removing the element under doubt and i got its
width and height as 86*22 .
(RenderBlock {LEGEND} at (14,0) size 86x22)
 Now i know that the height calculation is buggy, since its height is 0 and
it is not being displayed :).

10. This may not be answer for all the layout problems that you are facing,
but you can now reverse-engineer to find out what ever u want.

You can take away more information from render tree like,

1. We dont have to refer to specifications if an element is InLine or
Block, First word is clearly shouting what it is.
2. We can easily draw a RenderTree based on it
3. Firstword also helps us to find out which class and which file it
belongs to.

Hope all this helps, and if there is mis-interpretation, please correct it
and re-broadcast it to the community.


The only Concern i see in using this method is it is a short cut, and is
not encouraged to use it all the time. Use it to pin point the issue, and
from there try to understand the flow.

-Sravan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-help/attachments/20120303/45f32ed2/attachment.html>