936936 - A -moz-box frame does not resize properly when font-size is dynamically changed

Status: NEW

(Core :: XUL, defect, P5)

Description

[Simon Montagu :smontagu]

See the patch and try results at https://tbpl.mozilla.org/?tree=Try&rev=fd114bd93960

This problem is also exposed by the patch in bug 936935 but the try run shows that it can happen in other cases as well.

Comment 1

[Simon Montagu :smontagu]

needinfo=mats since it's your testcase originally. Do you have any idea what is happening here?

Comment 2

[Simon Montagu :smontagu]

Attachment: xulscroll-min.html

Minimized testcase for the Windows version of the bug

Comment 3

[Jonathan Kew [:jfkthame]]

I don't think this is necessarily linked to webfonts; experimenting with the testcase on OS X, I see unwanted red in some cases when using various standard platform fonts, but it depends both on the particular font chosen and on the font size. Times and Helvetica seem particularly bad.

(Using a specific web font may be the best way to have a consistently-reproducible example, though, especially across platforms.)

Comment 4

[Simon Montagu :smontagu]

My impression was that the bug was showing up after the reflow after loading the webfont. When creating and debugging the minimized testcase, I didn't see the bug when using a local version of the same font, nor if I reloaded the testcase a second time (i.e. with the font cached)

Comment 5

[Jonathan Kew [:jfkthame]]

Interesting. I tried using the Inspector to change the font-family on the .mozbox class (e.g. to times or helvetica), and I see significant amounts of red with both of these.

It may well be related to partial reflows, though; I expect having the Inspector open and modifying stuff there triggers reflow in different ways to a simple page load.

Comment 6

[Mats Palmgren (inactive)]

On Windows 7, if I modify the original test like so:
  <div style="float:right;" dir="rtl"></div>
that is, I removed the part that you moved to -rtl.html except I kept the wrapper
float, then I get I different result than if I remove that float entirely.
Furthermore, removing its dir attribute gives the same result as removing it entirely.
So it seems a rtl float is needed there for some reason.

Comment 7

[Mats Palmgren (inactive)]

... then again, that doesn't really explain the Try failure since your removed
that float in both the test and reference.  But, as Jonathan suggests, it might
be that we have an incremental reflow bug here that is covered up by the
presence of that rtl float.  Does the test pass if you add that dummy float
in both the test and reference files (for -ltr)?

Comment 8

[Simon Montagu :smontagu]

Having anything rtl in the testcase masks the bug because it triggers bidi resolution which marks the line dirty and causes another reflow (more about this in bug 936935)

Comment 9

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Here's a test without downloadable fonts that shows the incremental reflow
bug on all platforms.

Comment 10

[Mats Palmgren (inactive)]

(In reply to Simon Montagu :smontagu from comment #8)
> Having anything rtl in the testcase masks the bug because it triggers bidi
> resolution which marks the line dirty and causes another reflow (more about
> this in bug 936935)

Ah, good to know.  It should be easy to change the test to not depend on that
bug by toggling document.body.display:none/block or something.