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.
If I add a border to the table cell, the problem disappears.
Keywords: regression, regressionwindow-wanted
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.
Ah, that seems related to the "inlines that contain blocks" change...
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
Status: UNCONFIRMED → NEW
Component: General → CSS Parsing and Computation
Ever confirmed: true
> 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 "email@example.com 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.
Component: CSS Parsing and Computation → Layout
You need to log in before you can comment on or make changes to this bug.