1279244 - First-letter styling adds empty space to end of inline-block or floated element

Status: RESOLVED DUPLICATE of bug 385615

(Core :: Layout, defect)

Description

[Florens Verschelde :fvsch]

Attachment: firstletter-spacing-test-case.html

For display:inline-block and floated elements which have a :first-letter style, Firefox computes the box's width incorrectly, adding some (or sometimes a lot of) empty space at the end.

Bug seen in Firefox 47, 48 (devedition) and 50 (Nightly), on Windows 10 and OSX 10.11. This bug was apparently not present in Firefox 46, so this looks like a regression.

See the attached test case with several examples.
Simpler test case:

<div class="test">oh noes</div>
<style>
.test { display: inline-block; border: solid; }
.test:first-letter { font-size: 200%; }
</style>

Comment 1

[:Gijs (he/him)]

I *think* I can't reproduce this on my mac - I wonder if it's OS-dependent, in which case it might be either graphics-architecture or font-dependent.

Florens, can you add a screenshot comparing 46 and 47 so I'm sure I'm seeing what I think I'm supposed to be seeing?

Milan, any chance this is graphics?

Jonathan, any idea if this is a known regression and/or expected and/or potentially related to what fonts we end up using?

Comment 2

[:Gijs (he/him)]

Reporter: also, if this was indeed a regression, it might be quite useful to use https://mozilla.github.io/mozregression/ to find out exactly when it broke - we committed literally tens of thousands of changes between 46 and 47, so narrowing it down is super valuable. Thank you!

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

I'd guess more on the layout side.

Comment 4

[Jonathan Kew [:jfkthame]]

Yes, this is a layout bug. It seems to be reflow-related; I'm seeing incorrect layout (wrong width of the test div) when first loaded, but if I use the Inspector to disable and then re-enable whatever CSS property is being applied to the first-letter, the layout then appears correct.

A regression range would be really helpful here.

Comment 5

[Florens Verschelde :fvsch]

Attachment: first-letter-inline-block-rendering.png

Comment 6

[Florens Verschelde :fvsch]

I'm using mozregression-gui on Windows 10 and I'm seeing this bug going all the way back to Firefox 5. So it's not a regression.

At the same time, we've had reports from a client that for their site http://www.toursdemerle.fr/ they started seeing this bug after they updated Firefox today (to Firefox 37 stable). (To try to reproduce the bug on this site, load the home page then one of the subpages and look at the menu.)

We tried to reproduce this bug internally, and two coworkers who were on Firefox 36 did not see it. Then they updated to Firefox 37 and we could see the bug (that was on Windows 10 and on Linux).

My theory is that this bug was impacting this site all along, but the exact sequence of reflows (some due to JS scripts modifying the DOM) would correct the bad calculations while rendering the page. On Firefox 37, the sequence or particularities of the reflows must have changed, so this bug is not auto-corrected anymore.

On the limited test case, on the other hand, there is less chance for reflows, so the bug shows up all the way down to Firefox 5 (I tried a dozen builds in between).

If I use the main navigation of http://www.toursdemerle.fr/ as a test case:
2016-01-25: good
2016-03-07: bad

I'm going to try to run a more detailed bisection for that more complex test case, but it might be an unrelated and non-buggy change anyway.

Comment 7

[Florens Verschelde :fvsch]

I think the bisection worked. I'm not sure what info I should copy here.
Last good: 8ab285f0
First bad: 37aa3937

Log view ends with:

INFO : Narrowed inbound regression window from [cddaa4af, 37aa3937] (3 revisions) to [8ab285f0, 37aa3937] (2 revisions) (~1 steps left)
DEBUG : Starting merge handling...
DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=37aa3937fca8b4826e95c598baec1ec22fc3f00c&full=1
DEBUG : Found commit message:
Bug 1188802 - only rebuild local webfont rules when needed. r=heycam
INFO : The bisection is done.

That was fun :) Though I'm not sure it's relevant in this case.

Comment 8

[Jonathan Kew [:jfkthame]]

OK, I think that makes sense. It's not that bug 1188802 introduced this bug, but it helps us avoid extra reflows in certain cases, and that extra reflow happened to mask the underlying bug here.

Comment 9

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #8)
> OK, I think that makes sense. It's not that bug 1188802 introduced this bug,
> but it helps us avoid extra reflows in certain cases, and that extra reflow
> happened to mask the underlying bug here.

Adding 'testcase', which is clearly here, and tentatively removing 'regression' per this and previous comments, as well as the needinfo?.

Thanks!

Comment 10

[Florens Verschelde :fvsch]

Could this be a duplicate of bug 385615?

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to Florens Verschelde from comment #10)
> Could this be a duplicate of bug 385615?

Yes, looks like it.