224633 - quirks mode text-decoration "inherits" differently into tables in IE and Mozilla

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect, P4)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

In both IE and Mozilla we don't inherit certain CSS-properties into tables, such
as font-weight and font-family. IE similarly blocks text-decoration of parents
from affecting text inside tables, however mozilla does not.

Will attach a testcase

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: testcase

In mozilla the top table is underlined, in IE not. Neither browser makes the
bottom table bold.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: testcase 2

This tests all other textdecorations. For the first three textdecorations,
underline, overline and line-through, IE does not apply the style inside the
tables.

IE doesn't support blinking so i guess we can do whatever we want there.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: good testcase 2

Sorry, the text in the last attachment was wrong.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is this a problem on any real sites to the point that we should be creating a
quirk for this?

Comment 5

[Mike Kaply [:mkaply]]

This issue came to my team from one of our server products - WebSphere Portal
Server.

The issue was that when using the rich text editing facility of Mozilla, you get
inconsistent results between IE and Mozilla.

So for that group, this was rated as an important issue.

Comment 6

[Pascal Chevrel:pascalc (PTO until April 26)]

This issue was raised in a forum today, in quirks mode text-decoration is
inherited from body to table cells while it is not in NS4/IE/Opera. It is also
referenced as a specific mozilla bug in several places like
http://www.richinstyle.com/bugs/mozillademo.html

Comment 7

[Boris Zbarsky [:bzbarsky]]

Please don't even bother bringing Richinstyle up in bug reports.  It's notorious
for making incorrect claims and has been unmaintained for years now.

Comment 8

[Mathieu Fenniak]

Attachment: proposed patch

Attached patch fixes this bug by stopping text-decoration from inheriting inside tables in quirks mode.  It is right next to the code that sets text color inside a table, in quirks mode, to be the body's text color (nsHTMLStyleSheet::RulesMatching), which is similar in style.

With the test case, attachment 134727 [details], this patch makes the "In Table" text not underlined, not overlined, and not struck out.  This matches IE's quirks-mode behavior.

Before this patch, it was possible for text decorations to be a different color than the text inside a table, since the text decoration drawing code would gotten it's color from the "defining" element, which could be (but shouldn't have been) outside the table.  Red text with an underline surrounding the table would result in black text with a red underline inside the table.  Pretty funky, but not actually desired.

If anyone has suggestions for better approaches to moving this information around (currently an nsCSSValue(eCSSUnit_Initial) is used, in addition to a new NS_STYLE_TEXT_DECORATION_ABORT define), I'd be happy to incorporate a better approach in the patch.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So eCSSUnit_Initial means something else; it happens to not be implemented yet for text-decoration, but it should be.

I also don't think the fix should need to be this complicated, but I may not have time to come up with a better one immediately.

Comment 10

[Mathieu Fenniak]

David, you're probably right that the fix for this doesn't need to be so complicated.

The first solution I had in mind would have been restricted to nsTextFrame::PaintTextDecorations.  If it was possible to determine the responsible element from an nsStyleContext, I would have suggested checking for a table and breaking out of the "while (hasDecorations) { ... }" loop.  But I couldn't determine a way to do that.

If you could point me in the direction that you have in mind for a simpler approach, I'd be happy to pursue it.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This was fixed by http://hg.mozilla.org/mozilla-central/rev/4847e1cf6cf4 on bug 572713 , which added this quirk.