1180178 - Add writing-mode and logical coordinate info to frame dumps

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Simon Montagu :smontagu]

This makes life easier when debugging layouts with orthogonal flows

Comment 1

[Simon Montagu :smontagu]

Attachment: Patch

Comment 2

[Jonathan Kew [:jfkthame]]

Comment on attachment 8629325 [details] [diff] [review]
Patch

Review of attachment 8629325 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks; I've often thought of doing something like this, but never got around to it.

I'd suggest a slightly different approach in nsFrame, though:

::: layout/generic/nsFrame.cpp
@@ +5672,5 @@
> +    aTo += nsPrintfCString(" {%s-%s: %d,%d,%d,%d}",
> +                           wm.IsVertical()  ? wm.IsVerticalLR() ? "vlr" : "vrl"
> +                                            : "htb",
> +                           wm.IsBidiLTR() ? "ltr" : "rtl",
> +                           IStart(0), BStart(0), ISize(), BSize());

It seems rather fishy to pass 0 to IStart() and BStart() here... it's not clear what the dumped values will really signify.

In fact, I think we should remove these IStart(containerWidth) and BStart(containerWidth) methods from nsIFrame altogether (they're currently unused AFAICT), as it's really only meaningful to consider the logical-coord position of a frame in terms of its parent's writing mode (and width).

Then what I'd like to dump would be the frame's WM and logical size; and its parent's WM, width, and the child's logical rect according to that coordinate system.

Comment 3

[Simon Montagu :smontagu]

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Then what I'd like to dump would be the frame's WM and logical size; and its
> parent's WM, width, and the child's logical rect according to that
> coordinate system.

The parent's width isn't necessarily the container width which was used when positioning the frame, but I suppose it's the best we can do.

Comment 4

[Simon Montagu :smontagu]

Attachment: Patch v.2

Comment 5

[Jonathan Kew [:jfkthame]]

Comment on attachment 8630436 [details] [diff] [review]
Patch v.2

Review of attachment 8630436 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. It's true the parent width won't always be correct (especially in the midst of reflow), but it seems like the most useful thing we can reasonably show here.

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3ff251da4dae

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3ff251da4dae