1064199 - Outline on td gets padding with Verdana

Status: NEW

(Core :: Layout, defect)

Description

[bjoern.tantau]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36

Steps to reproduce:

When adding an outline and 0 padding to a td containing two spans and displaying the second span as a block element the outline seems to has gained a padding-top of about a line height.
It is for some weird reason important to set the font-family to Verdana and line-height below 1.4.

See http://jsfiddle.net/pvbmjdpg/2/embedded/result/ since Firefox 30.



Actual results:

Outline is rendered with a padding of about a line height.


Expected results:

Outline should be rendered directly above the text.

It was working as expected in Firefox 29.

Comment 1

[Boris Zbarsky [:bzbarsky]]

If I add a border to the table cell, the problem disappears.

Comment 2

[Alice0775 White]

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ac235837f6a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140216130250
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4d0f0eabea26
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140216160550
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5ac235837f6a&tochange=4d0f0eabea26


Regressed by:
4d0f0eabea26	L. David Baron — Bug 480888 patch 4: Draw outline around the union of border boxes, SVG, and text, rather than the visual overflow area. r=roc At the same time, move the handling of outlines on inlines that contain blocks earlier, so that we factor it into the stored frame property (and thus have the stored frame property) and so that we include it accurately in the overflow calculation.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, that seems related to the "inlines that contain blocks" change...

Comment 4

[Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160303134406

I have tested your issue on latest FF release (45.0), latest Nightly build(build ID: 20160317030235) and managed to reproduce it. http://jsfiddle.net/pvbmjdpg/2/embedded/result/ works correctly on Chrome and IE.

I've also performed a regression, which has different results from the one provided by Alice in comment 2:

Last good revision: 2bddbd180d2d (2014-02-17)
First bad revision: 6e3ec93efe1d (2014-02-18)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2bddbd180d2d&tochange=6e3ec93efe1d

Comment 5

[Boris Zbarsky [:bzbarsky]]

> I've also performed a regression, which has different results from the one provided by Alice in comment 2:

Your regression window is on mozilla-central.  Alice's is on mozilla-inbound.  If you look carefully, all the changesets in Alice's regression range are also in yours, as part of the "[e-mail]
Mon Feb 17 11:48:24 2014 +0000" push that has 8112ba0e9eb6 as its top commit; this was presumably the inbound-to-mc merge.

Anyway, this belongs in the same component as bug 480888.