11229 - Mozilla incorrectly allows TABLE to inherit properties from P

Status: VERIFIED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P4)

Description

[Braden]

TABLE should not inherit properties from P, since P cannot contain TABLE.

NB:Both IE5 and NN4.6 get this right.

Comment 1

[harishd]

The above URL rendered the same in Mozilla, Nav4.6, and IE5.!!

Comment 2

[Braden]

???

No they do not. Both IE5 and NN4.6 correctly render the first line red and the
second line black. Mozilla renders both lines red.

Comment 3

[harishd]

ok, you're right.  I see what you saying in apprunner.  I was checking with
viewer.

Comment 4

[harishd]

The problem is that the layout is functioning in the standards mode while the
parser is inclined to the quirks mode.

BTW, work needs to be done in setting appropriate modes from document's DOCTYPE.

Assigning bug to [e-mail]

Adding hyatt, and myself to the CC list.

Comment 5

[Peter Linss]

Should go away when you finish hooking up parser mode to document DTD mode

Comment 6

[harishd]

Setting prority to P1.

Comment 7

[harishd]

DTD modes are hooked up.

The above URL should render ok.

Marking bug FIXED.

Comment 8

[Christine Hoffman]

Using 9/16 Apprunner, verified bug fixed. Table does not inherit from P.

Comment 9

[Masatoshi Kimura [:emk]]

Second line should be black even if we are in standard mode.
Because P element SHOULD close before the TABLE element in standard mode.
reopen.

Comment 10

[Masatoshi Kimura [:emk]]

Attachment: testcase for standard mode

Comment 11

[leger]

Clearing FIXED resolution due to Reopen.

Comment 12

[harishd]

Actually, you're right?  P shouldn't contain TABLE in noquirks mode.  I'll
investigate the problem.  Thanx Braden.

Comment 13

[Masatoshi Kimura [:emk]]

In quirks mode:
P may contain TABLE for compatibility, but TABLE does not inherit
properties from P for compatibility.

In standard mode:
TABLE inherit properties from parent, but P cannot contain TABLE.

Second line should be black in either case after all.
But the underlying reason is different.

Comment 14

[Hixie (not reading bugmail)]

The attachement renders ok, and the test case renders ok. What is the problem???

I'm guessing this got fixed by some of the other DOCTYPE and quirk mode fixes
that have happened these past few weeks.

Should this now be marked WORKSFORME?

Comment 15

[Masatoshi Kimura [:emk]]

This is still not fixed on latest build using cvs.
Second text in the attachment should be black, but it is red.

Comment 16

[Christine Hoffman]

Tested using 12/10 build on  Win 95. Using a 'transitional' doctype, page
renders as Nav 4. Using a 'strict' doctype, page renders the table text in red
which is incorrect for the reasons reported stated. Bug is reproduced on Win 95.
I agree with reporter.

Comment 17

[Hixie (not reading bugmail)]

Attachment: Screenshot of attachement using 1999-12-14-08 build on Win98

Comment 18

[Hixie (not reading bugmail)]

Attachment: testcase for quirks mode (transitional DTD)

Comment 19

[Hixie (not reading bugmail)]

Attachment: Screenshot of third attachement using 1999-12-14-08 build on Win98

Comment 20

[Hixie (not reading bugmail)]

I have attached screenshots for both the standard mode test case and the
quirks mode (transitional DTD) test case (also newly attached). They render
correctly AFAICT (table text is never red). This is on Win98.

Is Win95 really rendering this differently? If so I am *very* surprised and
this should be marked [PP], with the Platform/OS fields filled in correctly.

Otherwise, this bug is either WORKSFORME or I have an error in my understanding
of the issue. Can someone work out which it is?

Comment 21

[Masatoshi Kimura [:emk]]

I've also tested on Win98, but table text was red in standard mode.
I Don't know why my result is different from yours.

Comment 22

[Hixie (not reading bugmail)]

Are you using AppRunner or Viewer?

Comment 23

[Masatoshi Kimura [:emk]]

Attachment: Testcase: another compatibility mode test

Comment 24

[Masatoshi Kimura [:emk]]

I found mode detection was broken now.
I'm really confused since "You are in Compatible mode" is displayed, but table
text is red on my environment...

Comment 25

[Christine Hoffman]

Tested using 12/15 build on Win 95 and Win 98. I am testing in Apprunner with
the testcase from 12/15 (containing a 'strict' DTD). In strict (standard) mode
in Apprunner, I still see the problem. Text in the paragraph and in the table
are both red. I have attached a screenshot from Win 95 but Win 98 is the same.

Comment 26

[Christine Hoffman]

Attachment: screenshot from Win 95 - 11/15 build

Comment 27

[Masatoshi Kimura [:emk]]

Ian: If your prefs.js has the following line, please remove it.

user_pref("nglayout.compatibility.mode", 2);

 Viewer will write this line when Style/Compatibility Mode Pref menu was
selected. Apprunner would never write it, but it also affect apprunner's
behaivior.

Note: Apprunner and viewer will incorrectly display "You are in Compatible
mode" regardless of the "nglayout.compatibility.mode" pref. This is another
bug.

Comment 28

[rickg]

Pierre -- this is a css error, not a parser bug. The style is coming from CSS.

Comment 29

[Pierre Saslawsky]

We have in fact 2 problems, one in the parser, one in style:
- In standard mode, the HTML parser should close the P when reaching the TABLE.
- In quirks mode, the style system should not make TABLE inherit the style from
the parent if the parent is P.

CCing Rick, in case he wants to fix the first issue before I take care of the
second one.

Comment 30

[Pierre Saslawsky]

Moving table bugs to M15 just to see how many we have.

Comment 31

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 32

[Pierre Saslawsky]

Block-moved to attinasi the bugs related to style inside tables

Comment 33

[Marc Attinasi]

This appears to be fixed now. In standard and quirks mode the table renders
correctly (ie. P is red, table is black). Tested in Viewer and Mozilla, checked
and I have no nglayout prefs set in either case.

Marking WORKSFORME - please advise if this is not working for you.

Comment 34

[Braden]

Yup, looks good to me.

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf02c5dd4935
[fenix] For https://github.com/mozilla-mobile/fenix/issues/11229: Update onboarding ETP copy.
https://hg.mozilla.org/integration/autoland/rev/71ed28a7ab77
[fenix] For https://github.com/mozilla-mobile/fenix/issues/11229: Update settings ETP copy.
https://hg.mozilla.org/integration/autoland/rev/df1ef666e64b
[fenix] For https://github.com/mozilla-mobile/fenix/issues/11229: Update ETP cfr string and behaviour.
https://hg.mozilla.org/integration/autoland/rev/d7f3357951b0
[fenix] For https://github.com/mozilla-mobile/fenix/issues/11229: Update etp strict option title content description.