45365 - Inline(!) DIV element silently ignored, if parent is an A/anchor.

Status: VERIFIED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Matthias Kerkhoff]

From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (WinNT; U)
BuildID:    2000071220

There are some problems with block-level elements (like DIV), when they placed 
inside an inline element (in this case, inside an A). 
The testcase demonstrates three aspects of this problems with the following 
setup. The document contains three A elements. Each of these elements contains a 
DIV child, which in turn is parent for an IMG.


Reproducible: Always
Steps to Reproduce:
1. Load the attached testcase


Actual Results:  a) DIV#1 is silently ignored (the parentNode of IMG#1 is the A 
element). This DIV has style="display:inline".
b) DIV#2 - it is inserted via DOM/JavaScript in window.onload() is _not_ 
ignored. This DIV has style="display:inline".
c) DIV#3 - it is inserted via DOM/JavaScript in window.onload() is _not_ 
ignored. This DIV has a default (block-level) style.

Expected Results:  a) As the DIV is explicitly marked as INLINE, it should of 
course be accessible via DOM. Compare to HTML4-Spec #7.5.3.
b) The only difference between DIV#2 and DIV#1 is, that DIV#2 is dynamically 
inserted. This should not make a difference. Either DIV#1 and DIV#2 should be 
ignored, or none of them. I would say, none of them should.
c) DIV#3 is illegal. A inline element, like an A, may not contain a block 
element (like DIV#3). I'm not totally sure, what the DOM-spec says to the 
attempt to build such trees, but I would think, a HIERARCHY_REQUEST_ERR 
exception would be a possible solution.

Comment 1

[Matthias Kerkhoff]

Added keywords.

Comment 2

[Matthias Kerkhoff]

Attachment: Added testcase.

Comment 3

[Matthias Kerkhoff]

Attachment: testcase for standard mode (same behaviour)

Comment 4

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

Are you sure the DOCTYPE parsing code is working correctly in the quirks-mode
testcase below?  I suspect it's not.  See bug 44340.

When the parser uses the Transitional DTD, it drops any tags that are out of
place, so the <DIV> and </DIV> should be dropped.  See
http://www.people.fas.harvard.edu/~dbaron/mozilla/modes .

Comment 5

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

BTW, CSS display properties have no affect on the validity of HTML, which is
defined by the DTD.

Comment 6

[Matthias Kerkhoff]

David: Of course, you're right with display vs. DTD. I mixed up inline-box from 
CSS with the inline elements of HTML.

Comment 7

[Matthias Kerkhoff]

David: Of course, you're right with display vs. DTD. I mixed up inline-box from 
CSS with the inline elements of HTML. But wat's about the other situation - 
manipulating the tree via DOM/JavaScript. Is it the expected behaviour of 
Mozilla to allow illegal HTML element trees ? If yes, this bug could be set to
INVALID.

Comment 8

[Marc Attinasi]

Distribution of Clayton's bugs: please triage these and share the joy...

Comment 9

[Marc Attinasi]

Sending to Johnny - it appears the DOM is allowing an illegal content tree to be 
created, whereas the parser is disallowing the same element heirarchy. Is this 
already a known bug? I remember Rick G. and myself discussing it at one time but 
I could not find an existing bug on it.

Comment 10

[Johnny Stenback (:jst)]

The DOM code simply can not police what the content model looks like beased on
what style happens to be applied for any given element. Something like that
could possibly be done for HTML but in XML there's no way mozilla can say that
one element all of a sudden is not allowed in some place in the tree. The layout
code needs to deal with this, reassigning to buster.

Comment 11

[gerardok]

massive update for QA contact.

Comment 12

[rickg]

The first case is illegal. You have a transitional document, in which <a> cant 
contain blocks (<div>). The other cases show flaws in the dom. I don't think the 
DOM should allow you to construct illegal documents. Over to vidur.

Comment 13

[vidur (gone)]

A DOM Level 2 implementation is not expected to validate a model relative to a 
schema. The tree manipulation methods in the DOM, in fact, do not specify 
exception conditions for invalid documents. Well-formedness is enforced in most 
cases, however. This bug is not a DOM issue - Johnny is right, the layout system 
has to be robust enough to deal with these cases. Similar cases can be created 
in CSS with a perfectly valid content model.

BTW, [e-mail] is the DOM owner now, not me.

Comment 14

[rickg]

This is the classic document algebra problem. In most algebra's, it's typical to 
be able to create atomic invariance that gets resolved upon the completion of a 
transaction. (Validity checks are run when the transaction finishes, not after 
each atomic action).

My question is: when does the dom enforce wellformedness?

For example, can I do this via the DOM:
1. create table with 1 row
2. get row-node
3. delete table
4. insert row-node into arbitrary location in document?

This would be well-formed but invalid, and (if allowable) would likely crash our 
table implementation.

Comment 15

[Hixie (not reading bugmail)]

no it would not, since CSS2 defines very clear rules for coping with that exact
case (namely, wrap that table-row and all adjacent table rows in an anonymous
table).

Comment 16

[buster]

all P3 bugs are Future, will not make RTM of NS6.

Comment 17

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Nominating.

Comment 19

[Marc Attinasi]

Somebody seems to have fixed something that has fixed this bug.

I loaded the testcase (id=11334) into Viewer and dumped the content: the divs
are there, as they should be. Also, in Mozilla, mousing over the images I get
the alert indicating that the IMG has a parent of DIV in all three testcases.

From what I can grasp of the comments in this bug, this bug is now WORKSFORME.

For evidence, here is a content dump of the page showing that the DIV is indeed
the child of the A and the IMG is the child of the DIV in all cases.

    h3@01439430 refcount=3<
      Text@01439580 refcount=3<Problem #1: DIV element silently ignored>
    >
    Text@01439C00 refcount=3<\n>
    p@01438090 refcount=3<
      Text@01438660 refcount=4<The first A contains a DIV with display:inline.
The DIV contains an IMG. Moving the mouse over the first image reports that it's
parent is the A element! >
      b@01438930 refcount=3<
        Text@01438C00 refcount=3<It should be the DIV.>
      >
    >
    Text@0143AD60 refcount=3<\n>
    br@01438210 refcount=3<>
    a@01438500 href=# onmouseover=alert('I am the ' + event.target.tagName + '
and my parent is' + event.target.parentNode); refcount=4<
      div@0143F170 style=display: inline;  refcount=4<
        img@0143C5E0 src=http://www.mozilla.org/status/tree.gif refcount=4<>
      >
    >
    Text@01439D60 refcount=3<\n>
    h3@01438390 refcount=3<
      Text@0143BC10 refcount=3<Problem #2: Shows that JavaScript/DOM behaves
differently>
    >
    Text@0143BB30 refcount=3<\n>
    p@0143F220 refcount=3<
      Text@0143BAC0 refcount=4<Same setup as above: A->DIV->IMG. The only
exception now is, that the DIV is inserted in onload. Again, move the mouse over
the IMG and see the (different) report.>
      b@0143E670 refcount=4<
        Text@0143B980 refcount=4<Both ways should result in the same report.>
      >
    >
    Text@0143BC80 refcount=3<\n>
    br@0143B770 refcount=3<>
    a@0143B6A0 href=# onmouseover=alert('I am the ' + event.target.tagName + '
and my parent is' + event.target.parentNode); refcount=4<
      div@01431170 style=display: inline; border-top-width: 5px;
border-top-style: solid; border-top-color: green; border-right-width: 5px;
border-right-style: solid; border-right-color: green; border
-bottom-width: 5px; border-bottom-style: solid; border-bottom-color: green;
border-left-width: 5px; border-left-style: solid; border-left-color: green;
refcount=4<
        img@0143B560 id=img2 src=http://www.mozilla.org/status/tree.gif refcount=4<>
      >
    >
    Text@0142E040 refcount=3<\n>
    h3@0142B030 refcount=3<
      Text@01428400 refcount=4<Problem #3: Shows that with JavaScript/DOM it's
easy to build an illegal tree (block element inside an inline element)>
    >
    Text@0142C6D0 refcount=3<\n>
    p@0142F440 refcount=3<
      Text@0142C810 refcount=4<Usual setup: A->DIV->IMG. Again, the DIV is
inserted in onload. This time, it doesn't have a display:inline - it uses the
default. Move the mouse over the IMG and see th
e report.>
    >
    Text@0142C950 refcount=3<\n>
    br@0142CAA0 refcount=3<>
    a@0142CD40 href=# onmouseover=alert('I am the ' + event.target.tagName + '
and my parent is' + event.target.parentNode); refcount=6<
      div@014EECD0 style=border-top-width: 5px; border-top-style: solid;
border-top-color: green; border-right-width: 5px; border-right-style: solid;
border-right-color: green; border-bottom-width: 5p
x; border-bottom-style: solid; border-bottom-color: green; border-left-width:
5px; border-left-style: solid; border-left-color: green;  refcount=4<
        img@0142AF70 id=img3 src=http://www.mozilla.org/status/tree.gif refcount=4<>
      >
    >
    Text@0142FAF0 refcount=3<\n>

If needed I can attach screen shots of the alert as well, but just try it.

Comment 20

[bsharma]

qa contact updated.

Comment 21

[vectro]

Second attachment works OK for me in Moz 0.8 linux.

Comment 22

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.

Comment 23

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 24

[Christopher Hoess (gone)]

Closing WORKSFORME.

Comment 25

[Moied]

Verfied Worksforme on buildID 20011213