Bug 68100 – REGRESSION (r78846): Text misaligned vertically within table cell with valign="top" attribute and <sup> tags

• Component: Layout and Rendering
• Status: RESOLVED CONFIGURATION CHANGED

[David Kilzer (:ddkilzer)]

* SUMMARY
Commit r78846 for Bug 54244 caused a regression when a table cell has a valign="top" attribute, the superscript tag (<sup></sup>) is used in the text in the cell, and other text in the cell has any other kind of tag.

* STEPS TO REPRODUCE
1. Load attached test case.

* EXPECTED RESULTS
The text (with the exception of the &reg; symbol) should all have the same baseline.

* ACTUAL RESULTS
The text that's outside of any tag (except <TD></TD> tags) has the wrong baseline.

* REGRESSION
This is a regression from r78846.  The autospade script said r78842 worked and r78846 failed, but the only commit in that range that makes sense is r78846.

* NOTES
Compare attached screenshots by switching between tabs to see which text should be lower.  (The text of the test case is a bit misleading.)

[David Kilzer (:ddkilzer)]

<rdar://problem/10117982>

[David Kilzer (:ddkilzer)]

Created attachment 107367 [details]
Test case

The changes to InlineFlowBox::adjustMaxAscentAndDescent() (consulting verticalAlign() instead of logicalTop()) are possiblly at fault here.

[David Kilzer (:ddkilzer)]

Created attachment 107368 [details]
Expected results

[David Kilzer (:ddkilzer)]

Created attachment 107369 [details]
Actual results

[Tom Ace]

This is still unfixed two years later.
It was recently reported at 
 https://code.google.com/p/chromium/issues/detail?id=135657
and I've added a comment there linking to this page.

Created attachment 214973 [details]
screenshot attached

There seem to be two bugs present:

- the incorrect baseline rendering of the majority of fonts in a table td with vertically-aligned bold or italic content;

- the amplification of such baseline errors, for any font, when superscript tags are used.

The bug is not apparent in Internet Explorer, Opera or Firefox, but does occur in Safari 5.1. The bug is partially present in Safari 6 on Mac and Chrome 30 on Unix. The bug appears to be dependent on operating system.

I attach a screenshot.

[rick luna]

just adding a note that I run into this on occasion as i do a lot of html emails using table-based layouts for use in exact target, campaigner, etc.

This bug now seems to be fully resolved with Chrome 46. See https://code.google.com/p/chromium/issues/detail?id=135657

[Ahmad Saleem]

I am unable to reproduce this bug in Safari 15.6.1 and Safari Technology Preview 152 using attached test case and it shows similar behavior as "EXPECTED RESULT" and matching both Chrome Canary 107 and Firefox Nightly 106. It seems to be something fixed along the way.

I am going to mark this as "RESOLVED CONFIGURATION CHANGED". Please reopen with updated test case in case if it is still present. Thanks!