In this document there is a table with an absolutely positioned table with absolutely specified dimiensions. The table frame bottom edge is wrong. (works fine in IE).

Note to bug reporter: please do not submit bugs like this. Instead, narrow it down to simple test case. Here is the simple test case for this bug: It appears the absolutely positioned DIV inside the last cell is causing the problem. This looks like malformed content, but I didn't see the DIV being rendered anywhere. Source code is below. Adding Steve to the cc: list becuase I'm not sure if this is a layout thing or a tables thing. <TABLE border=1 cellSpacing=0 style="LEFT: 74pt; POSITION: absolute; TOP: 128pt; WIDTH: 464pt"> <TR style="HEIGHT: 17pt"> <TD align=left style="WIDTH: 114pt" vAlign=top> Feature</TD> <TD align=middle style="WIDTH: 116pt" vAlign=top> 1970s</TD> <TD align=middle style="WIDTH: 115pt" vAlign=top> 1980s</TD> <TD align=left style="WIDTH: 115pt" vAlign=top> 1990s <DIV class=f4 style="LEFT: 533pt; POSITION: absolute; TOP: 130pt">foo</DIV></TD></TR> </TABLE> Changing summary to reflect problem.

This is indeed malformed HTML. sorry for your trouble. (IE does seem to be better at recovering from it though).

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

troy: this is crashing in an assertion in the nsFrameList code because the expected parent of the absolute item being appended != the actual parent. Maybe the assertion is wrong? However, since I don't see any (obvious) code in nsAreaFrame for reparenting the absolute children, I'm guessing its a frame construction bug...

Chris, the table related frame construction code seems to be doing the wrong thing for absolutely positioned elements inside of tables which is why the parent frame is wrong. Here's the stack trace for the assert: NTDLL! 77f76148() nsDebug::Assertion(const char * 0x00730a44, const char * 0x00730a30, const char * 0x00730a04, int 343) line 140 + 13 bytes nsFrameList::VerifyParent(nsIFrame * 0x01065620) line 343 + 34 bytes nsFrame::AppendFrames(nsFrame * const 0x01065620, nsIPresContext & {...}, nsIPresShell & {...}, nsIAtom * 0x01084090 {"Absolute-list"}, nsIFrame * 0x0106ec50) line 260 nsBlockFrame::AppendFrames(nsBlockFrame * const 0x01065620, nsIPresContext & {...}, nsIPresShell & {...}, nsIAtom * 0x01084090 {"Absolute-list"}, nsIFrame * 0x0106ec50) line 3287 + 25 bytes nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x01059d10, nsIPresContext * 0x010842b0, nsIContent * 0x0106686c, int 0) line 3150 StyleSetImpl::ContentAppended(StyleSetImpl * const 0x0105c120, nsIPresContext * 0x010842b0, nsIContent * 0x0106686c, int 0) line 739 PresShell::ContentAppended(PresShell * const 0x01059138, nsIDocument * 0x01086980, nsIContent * 0x0106686c, int 0) line 1605 + 33 bytes nsDocument::ContentAppended(nsDocument * const 0x01086980, nsIContent * 0x0106686c, int 0) line 1242 nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x01086980, nsIContent * 0x0106686c, int 0) line 684 HTMLContentSink::WillInterrupt(HTMLContentSink * const 0x010863f0) line 1507 CNavDTD::WillInterruptParse(CNavDTD * const 0x01058d50) line 2719 + 27 bytes nsParser::ResumeParse(nsIDTD * 0x00000000) line 766 nsParser::OnDataAvailable(nsParser * const 0x01086564, nsIURL * 0x01084610, nsIInputStream * 0x01086d10, unsigned int 583) line 968 + 17 bytes nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x01085b40, nsIURL * 0x01084610, nsIInputStream * 0x01086d10, unsigned int 583) line 1783 + 24 bytes OnDataAvailableProxyEvent::HandleEvent(OnDataAvailableProxyEvent * const 0x01084ab0) line 632 StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x01084ab4) line 471 + 12 bytes PL_HandleEvent(PLEvent * 0x01084ab4) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00f9ebf0) line 437 + 9 bytes _md_EventReceiverProc(HWND__ * 0x6f6b009a, unsigned int 49436, unsigned int 0, long 16378864) line 799 + 9 bytes USER32! 77e71250() 00f9ebf0()

I'm inserting some comments from Troy for future use. The table code should behave the same as the other code (e.g., block). Sort of. :-) Assuming that the table itself isn't absolutely positioned (ignore that issue for a second), then yes you should check if you have children that are absolutely positioned and then give them a different parent (the one passed in to the function) and return that child back in the list of absolutely positioned children. Don't add it to your list of flowed children, because it's being moved out of the flow. However (there's always a 'however'), you probably don't want to let people absolutely position (or float) row groups, rows, or cells; and certainly not col groups or cols. The CSS2 spec discourages this as well.

Moving to M8

[TESTCASE] CSS2 discourages this, but it *certainly* doesn't say you cannot do it. In fact, it specifically says you can. (It also says you can float cells, but I have had that revoked. The change should appear in a future errata). See section 17.5 I have created a self-explanatory test case for this: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/tablepos.html [Note. The original URI is now a 404, so I have changed it to the test case.] [dbaron: I have cced you on this bug, since you have done a lot with absolute positioning and may be interested in how this develops.]

You can relatively position table elements, but you *CANNOT ABSOLUTELY POSITION ANY TABLE ELEMENT*, because CSS2, section 9.7 ( http://www.w3.org/TR/REC-CSS2/visuren.html#q24 ) says: Otherwise, 'position' has the value 'absolute' or 'fixed', 'display' is set to 'block' and 'float' is set to 'none'.

(...sorry about splitting this comment. NN4.x decided not to let me type in the text box...) Therefore, the position:absolute on any table-type element makes it a block, which means it is handled according to the rules on implied table elements, which then recreates the appropriate missing element in the structure. So it's not quite as messy as it seems. Considering the current serious problems with implied table elements, I'm going to mark this bug as depending on bug 2479. I don't think it's really worth trying to make sense of this until implied table elements make sense.

Problem still occurs with the June 28th Build (1999062809)

Moving to M9.

David has convinced me that floating a table cell _does_ make sense. A floated cell becomes a block box, and by CSS2's table creation rules, the block box is assimilated into an anonymous cell. See CSS2 for the exact rules.

Moving to M12

mass move to m14.

Migrating from {css2} to css2 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...

Changing [NOTESTCASENEEDED] code to new donttest keyword. Sorry for the spam!

moving to M16.

I have changed the anonymous table construction code and have another local change that renders the following, but I'm not sure if it is correct. How should the following be rendered? Can the <div> be absolutely positioned even if it gets wraped in an anonymous table cell? <ul style="display:table; border:1px solid black; padding:0px; LEFT: 100px; POSITION: absolute; TOP: 150px; WIDTH: 200px"> <li style="display:table-row; padding:2px"> <div>foo</div> </li> <li style="display:table-row; padding:0px"> <DIV style="LEFT: 300px; POSITION: absolute; TOP: 100px">bar</DIV> </li> </ul>

The DIV should be absolutely positioned relative to the UL element (which is its containing block). (Note that the UL element is not the anonymous table element generated inside the UL element.)

Moving to M17.

Nom. nsbeta3. Recc. nsbeta3+. Want CSS2 positioning to work correctly; here it would be broken for DIVs within TABLEs if not fixed.

Encountered the following problem in M16 - is it related to this discussion?: Unable to establish TABLE as a containing block with respect to which descendents may be positioned absolutely. The following HTML (with or without style="position:relative" in either the TABLE or TD tags), will not cause the "absolute" DIV, or any other element, to be absolutely positioned with respect to the TABLE. <HTML> outer<br> <TABLE style="position:relative"> <tr><td> inner<br> <DIV id="absolute" style="position:absolute; top:0; left:0"> overwrite </DIV> </td></tr> </TABLE> </HTML> Contents of DIV overwrite 'outer' text rather than 'inner', showing that the absolutely positioned DIV is positioned with respect to initial containing block rather than the TABLE.

As per meeting with ChrisD today, taking QA.

Denying beta3 nomination for absolute positioning problems in tables.

this is probably my bug, not chris'

The comment Val Sharp mentioned above is bug 63895.

Build reassigning Buster's bugs to Marc.

reducing priority

Reconfirmed using FizzillaCFM/2002071208 to view testcase URL. Setting All/All.

qawanted?

Yes. What does this bug really cover? The comments mention a wide variety of issues; the testcase does as well. Is this a tracking bug?

attinasi will probably not work on those bugs :-(

I think this bug is actually now INVALID. Here's why: 1) The listed URL is now a 404. 2) As bz mentioned above in comment 33, the bug addresses multiple issues. 3) The reporter admitted that the original test HTML was malformed. 4) Angus submitted a test case, but didn't attach it as an actual testcase attachment (maybe this wasn't possible in 1998?). This makes it difficult for QA to confirm the problem. 5) The issue mentioned by Val Sharp is another bug, as stated by dbaron. If somebody wishes to reopen this bug... actually you probably shouldn't. Instead, file a new bug that has a clear summary stating the specific problem and an attached testcase, and CC me if you want it confirmed. -M