163838 - painful assertion "Parser and editor disagree on blockness" for DT elements

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

win2k build 20020820

1. launch composer
2. type some chars
3. choose Format > List > Term

This fires a large number of the following assertion

  "Parser and editor disagree on blockness dt: '*aIsblock'"

a) Parser and editor should not disagree here ; a DT *is* a block
b) that's VERY painful
c) does it come from nsParserService::IsBlock() not testing
   gHTMLElements[aId].IsMemberOf(kDLChild) ?

Comment 1

[Akkana Peck]

I saw this too, yesterday, and hadn't seen it previously.  Did something change
to make this start happening?

We could add dt to the list of "Nodes we know we want to treat as block even
though the parser says they're not" and cure the assertion that way; but if the
parser service should be returning block and is not, perhaps it would be better
to  fix the problem on that end?  Harish?

If the fix is in the editor, or there's a straightforward fix in the parser and
Harish doesn't have time, I can take the bug, but let's make sure we all agree
on which end needs to be fixed.

Comment 2

[Akkana Peck]

Am I misreading http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.3
thinking it specifies dt as inline?  Hmm, that's 4.0 (time to update that
bookmark) but surely that didn't change?

Comment 3

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

> Am I misreading http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.3
> thinking it specifies dt as inline?  Hmm, that's 4.0 (time to update that
> bookmark) but surely that didn't change?

Akkana, saying that the contents of a DT are inline-level does not imply that
DT is inline-level. The contents of H1 are also %inline; but H1 is clearly a block.
From a box model point of view, there is **no doubt** DT is a block.

Comment 4

[Joe Francis]

snarf

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Harish, is that something you can fix in the parser w/o breaking anything or
do we have to hack editor to consider blockness regardless of parser's answer ?
I need this bug to be fixed for CSS in Composer.

Comment 6

[harishd]

The html spec. does not explain it very clearly ( but that's no news! ). In any
case, I strongly believe ( yes I really do! ) that DT is a block-level tag and
should be treated as one without breaking the existing world. I'll attach a
patch soon.

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

From a CSS point of view, there is no ambiguity : DT and DD have 'display:block'.

Comment 8

[Joe Francis]

Assuming right thing to do is give to Harish.  Bounce back to me if this is wrong.

Comment 9

[Kathleen :Brade]

Harish--are you working on this bug?  I'm seeing problems with DT/DD that may or
may not be related to this assertion.  It'd be nice if the assertion issue were
cleared up before addressing the issue of not being able to press return while
the caret is in it.

Comment 10

[timeless]

###!!! ASSERTION: Parser and editor disagree on blockness: caption: '*aIsBlock',
file i:/build/mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 641

Comment 11

[Jesse Ruderman]

###!!! ASSERTION: Parser and editor disagree on blockness: legend: '*aIsBlock', file mozilla/editor/libeditor/html/nsHTMLEditor.cpp, line 612

Comment 12

[Mats Palmgren (inactive)]

Attachment: Testcase #1, legend

Loading this testcase in a browser window triggers:
ASSERTION: Parser and editor disagree on blockness: legend: '*aIsBlock'

Comment 13

[Jesse Ruderman]

Attachment: testcase 2, caption

Comment 14

[Makoto Kato [:m_kato]]

no hit assertion now.