Looking at the frame model, the div with display:table seems to have a different
width. I'm not sure whether this is a bug in the reflow branch code or a bug in
the expectations of the marquee binding... A somewhat minimized testcase that
shows the layout difference would be great.
I don't have a build with the reflow branch (yet), so I can't really
help, I'm afraid.
I don't think this is a bug in the expectations of the marquee binding.
This is more or less an unxbl-ised example:
http://wargers.org/mozilla/margin_100_percent.html Do you experience any difference here between a normal build and the
reflow branch build?
I'm not sure, but I think I've heard someone say (bernd?), that
percentage margins are working quite buggy (in combination with
tables?). It just happens to work accidently here, but not when the
margin is added dynamically.
> The testcase at https://bugzilla.mozilla.org/attachment.cgi?id=200664 seems to
> behave oddly on the reflow branch -- the green table ends up pinned to the right
> hand side of the window during the whole time when it would normally scroll
> right to left.
> Looking at the frame model, the div with display:table seems to have a different
> width. I'm not sure whether this is a bug in the reflow branch code or a bug in
> the expectations of the marquee binding... A somewhat minimized testcase that
> shows the layout difference would be great.
> dev-tech-layout mailing list
> [hidden email] > https://lists.mozilla.org/listinfo/dev-tech-layout >
Boris Zbarsky wrote:
> Martijn wrote:
>> This is more or less an unxbl-ised example:
>> http://wargers.org/mozilla/margin_100_percent.html >> Do you experience any difference here between a normal build and the
>> reflow branch build?
> Ah, indeed. A reflow branch build doesn't seem to have a right margin.
> OK, that's what we should look into. ;)
Hmm... So the left and right margins are both set to "100%" on a box that has
auto width and is doing shrink-wrap sizing. The box is a table.
We end up computing the intrinsic width of the table, and then enforcing the
equality that holds for blocks. But in this case, that makes the situation
overconstrained, so we set the right margin to negative the width (since
direction is ltr). This happens in
nsHTMLReflowState::CalculateBlockSideMargins, which we call for tables to handle
auto margins correctly.
Perhaps we shouldn't do that if we're using the shrink-to-fit width (as opposed
to having a width style specified)?
Note that what happens on trunk is that the computed width is unconstrained when
we hit CalculateBlockSideMargins, so we just bail out without resetting the