Closed Bug 42312 Opened 24 years ago Closed 24 years ago

tables rows not starting on new lines

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: morse, Assigned: rickg)

References

Details

(Whiteboard: [nsbeta2+] fix in hand)

Consider the following simplified html page. It is supposed to display a table of two rows, each row containing a text field. Instead you get the two text fields on a single line instead of on two lines. This is a regression that just started happening today. It works fine with a tree that I pulled and built on 6-10. Two observations: 1. If I remove the <p> line, it comes up fine (on two lines). 2. If I remove the first line (which was generated by 4.x composer), it comes up fine (on two lines). <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <body> <form> <p> <table> <tr> <td><input type="text"></td> </tr> <tr> <td><input type="text"></td> </tr> </table> </form> </body> </html>
strict DTD problem?
Assignee: clayton → rickg
<p> contains only inline elements in a strict HTML document, so it can't contain the <table>. However -- since the </p> is optional the <table> *should* auto-close the <p>. I'll look into this tomorrow.
Status: NEW → ASSIGNED
This bug is impacting wallet work because it destroys the layout of the wallet interview form (menu item tasks->privacy->form-manager->interview). I temporarily had to remove the first line (doctype) from that file in order to work-around this bug. But that line is generated by composer and will come back the next time I use composer to make any changes to this file (unless I remember to manually remove it after using composer).
Severity: normal → blocker
See also bug 42265 which appears to be related. Both get cleared up if you remove the initial doctype line.
Keywords: nsbeta2
And both this bug and 42265 are regressions that occured sometime between 6-10 and 6-12.
Marking nsbeta2+
Whiteboard: [nsbeta2+]
Thanks for the quick turnaround Jan. I have a fix in hand for this a few other (minor) DTD-related issues.
Whiteboard: [nsbeta2+] → [nsbeta2+] fix in hand
*** Bug 42448 has been marked as a duplicate of this bug. ***
Adding to CC, marking All All
OS: Windows NT → All
Hardware: PC → All
Blocks: 42388
*** Bug 42532 has been marked as a duplicate of this bug. ***
*** Bug 42526 has been marked as a duplicate of this bug. ***
*** Bug 42526 has been marked as a duplicate of this bug. ***
Blocks: 42699
*** Bug 42699 has been marked as a duplicate of this bug. ***
Landed fix. Please retest.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
It's certainly much better, the rows start on new lines. But now I'm getting an assertion from the parser when I display this html code. Here's the stack trace. NTDLL! 77f76274() nsDebug::Assertion(const char * 0x0165c800 ??_C@_0BG@EIKL@?$HMCharAt?$HM?5out?9of?9range?$AA@, const char * 0x0165c818 ??_C@_0BA@OBAB@aIndex?$DMLength?$CI?$CJ?$AA@, const char * 0x0165680c ??_C@_0CK@NPGP@?4?4?2?4?4?2?4?4?2dist?2include?2nsAReadabl@, int 544) line 242 + 13 bytes basic_nsAReadableString<unsigned short>::CharAt(unsigned int 0) line 544 + 42 bytes basic_nsAReadableString<unsigned short>::First() line 564 HTMLContentSink::AddDocTypeDecl(HTMLContentSink * const 0x03d07c40, const nsIParserNode & {...}, int 1) line 3122 + 11 bytes CNavDTD::HandleDocTypeDeclToken(CToken * 0x02d2a6f0) line 2139 + 35 bytes CNavDTD::HandleToken(CNavDTD * const 0x041d8170, CToken * 0x02d2a6f0, nsIParser * 0x03d25750) line 789 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x041d8170, nsIParser * 0x03d25750, nsITokenizer * 0x041db700, nsITokenObserver * 0x00000000, nsIContentSink * 0x03d07c40) line 499 + 20 bytes nsParser::BuildModel() line 1657 + 34 bytes nsParser::ResumeParse(int 1, int 0) line 1538 + 11 bytes nsParser::OnDataAvailable(nsParser * const 0x03d25758, nsIChannel * 0x03d4a500, nsISupports * 0x00000000, nsIInputStream * 0x03d1cf5c, unsigned int 0, unsigned int 305) line 1986 + 19 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03d4e5c0, nsIChannel * 0x03d4a500, nsISupports * 0x00000000, nsIInputStream * 0x03d1cf5c, unsigned int 0, unsigned int 305) line 210 + 46 bytes nsFileChannel::OnDataAvailable(nsFileChannel * const 0x03d4a508, nsIChannel * 0x03d1a8c0, nsISupports * 0x00000000, nsIInputStream * 0x03d1cf5c, unsigned int 0, unsigned int 305) line 661 + 49 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03d1ce10) line 406 + 47 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03d1cdc0) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x03d1cdc0) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x029c1ac0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x006d0668, unsigned int 49415, unsigned int 0, long 43784896) line 1032 + 9 bytes USER32! 77e71268() 029
This isn't in the parser, it's a bug in the content sink that JST introduced a few days ago. He has an open bug on this.
*** Bug 42785 has been marked as a duplicate of this bug. ***
Fixed in the June 20th build.
Status: RESOLVED → VERIFIED
*** Bug 42818 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.