Last Comment Bug 224633 - quirks mode text-decoration "inherits" differently into tables in IE and Mozilla
: quirks mode text-decoration "inherits" differently into tables in IE and Mozilla
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: Trunk
: All All
: P4 normal with 1 vote (vote)
: mozilla2.0b8
Assigned To: David Baron :dbaron: ⌚️UTC-7 (busy September 14-25)
:
:
Mentors:
Depends on: 572713
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-03 15:14 PST by Jonas Sicking (:sicking) No longer reading bugmail consistently
Modified: 2011-08-10 17:35 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (350 bytes, text/html)
2003-11-03 15:24 PST, Jonas Sicking (:sicking) No longer reading bugmail consistently
no flags Details
testcase 2 (772 bytes, text/html)
2003-11-03 16:10 PST, Jonas Sicking (:sicking) No longer reading bugmail consistently
no flags Details
good testcase 2 (768 bytes, text/html)
2003-11-03 16:11 PST, Jonas Sicking (:sicking) No longer reading bugmail consistently
no flags Details
proposed patch (9.02 KB, patch)
2007-04-25 18:18 PDT, Mathieu Fenniak
no flags Details | Diff | Splinter Review

Description Jonas Sicking (:sicking) No longer reading bugmail consistently 2003-11-03 15:14:12 PST
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 2003-11-03 15:24:58 PST
Created attachment 134723 [details]
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 2003-11-03 16:10:18 PST
Created attachment 134726 [details]
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 2003-11-03 16:11:48 PST
Created attachment 134727 [details]
good testcase 2

Sorry, the text in the last attachment was wrong.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2003-11-03 17:15:51 PST
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] 2003-11-04 12:59:31 PST
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 2004-04-01 02:14:08 PST
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 [:bz] (still a bit busy) 2004-04-01 05:45:49 PST
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 2007-04-25 18:18:05 PDT
Created attachment 262828 [details] [diff] [review]
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-7 (busy September 14-25) 2007-04-26 12:57:18 PDT
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 2007-05-18 07:45:40 PDT
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-7 (busy September 14-25) 2011-08-10 17:35:56 PDT
This was fixed by http://hg.mozilla.org/mozilla-central/rev/4847e1cf6cf4 on bug 572713 , which added this quirk.

Note You need to log in before you can comment on or make changes to this bug.