Closed Bug 42312 Opened 24 years ago Closed 24 years ago

tables rows not starting on new lines

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

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.