Marquee issues on reflow branch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Marquee issues on reflow branch

Boris Zbarsky
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.

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Marquee issues on reflow branch

Martijn-4
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.

Regards,
Martijn

On 5/30/06, Boris Zbarsky <[hidden email]> wrote:

> 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.
>
> -Boris
> _______________________________________________
> dev-tech-layout mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-layout
>
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Marquee issues on reflow branch

Boris Zbarsky
In reply to this post by Boris Zbarsky
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.  ;)

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Marquee issues on reflow branch

Boris Zbarsky
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

     'margin-left' + 'border-left-width' + 'padding-left' + 'width' +
     'padding-right' + 'border-right-width' + 'margin-right' =
     width of containing block

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
margin....

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout