55780 - Table not properly layed out (due to an <INPUT type="hidden">?)

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P3)

Description

[John Morrison]

Overview Description:
  Part of the form for an order entry form at Ticketmaster is not
  properly layed out. Part of the inner table is displayed outside
  of the border of the outer table that contains it, and form controls
  (text inputs) are not displayed correctly, or in some case, at all.

Steps to Reproduce:
1) Load the attachment

Reproducibility: 100%

Build Date & Platform Bug Found:
  2000100808 win2k MN6 branch build, and on a current trunk build
  2000100808 Linux
  2000100609 mac

Oddly, the glitch is triggered by the the presence of an <input
type="hidden"> placed between the second <table> tag and the first
<tr> tag following it. If you move that element to any other place in
the document, the initial page layout is fine.

e.g.   <table>
         <input type="hidden">
         <tr>
           <td>

Comment 1

[John Morrison]

Nom. RTM given one high-profile example, and that this would be a fairly easy
hole for developers to fall into (and users to get non-functioning forms.

(Although, it is bogus to place that element there, and there is a workaround,
so if the fix is complicated then ... ).

Comment 2

[karnaze (gone)]

Adding qawanted (a test case would be nice). Without looking at the content 
model, my guess is that the parser is throwing out the input element. 
Reassigning to Harish.

Comment 3

[John Morrison]

Ack! I made the test case before I filed the bug report, but failed to attach it
to the bug report. Here it is now.

Comment 4

[John Morrison]

Attachment: simplified table showing the problem.

Comment 5

[harishd]

Attachment: Further Reuuced...

Comment 6

[harishd]

Content model for attachment # 2 [details] [diff] [review]:

docshell=00C84290
html@0106E238 refcount=6<
  head@00FB4FC8 refcount=2<
  >
  Text@02E082D0 refcount=3<\n\n>
  body@02E08188 refcount=3<
    Text@02E2D8E0 refcount=3<\n>
    form@02E2D7BC action=linkme method=Post refcount=3<
      Text@02E2D5C0 refcount=3<\n\n>
      table@02E2D498 border=1 width=480 refcount=8<
        Text@02E2BFB0 refcount=2<\n >
        tbody@02E2BEB8 refcount=3<
          tr@02E2BDB8 refcount=3<
            Text@02E2BD40 refcount=2<\n  >
            td@02E2BC1C refcount=4<
              Text@02E2BBA0 refcount=3<XXX>
            >
            Text@02E2BA70 refcount=2<\n   >
            td@02E2B9DC refcount=4<
              Text@02E2B960 refcount=3<\n    >
              input@02E295DC type=hidden name=add value=yes refcount=6<>
              Text@02E28130 refcount=3<\n      >
              table@02E2B8B8 refcount=7<
                Text@02E2B5C0 refcount=2<\n     >
                tbody@02E280C8 refcount=3<
                  tr@02E28058 refcount=3<
                    Text@02E29A50 refcount=2<\n       >
                    td@02E299EC colspan=2 refcount=4<
                      Text@02E298C0 refcount=12<\n         There should be text 
input widgets in the
                    >
                    Text@02E0A280 refcount=2<\n     >
                  >
                  Text@02E08CD0 refcount=2<\n    >
                >
              >
              Text@02E31210 refcount=3<\n   >
            >
            Text@02E311A0 refcount=3<\n  >
            td@02E310DC refcount=4<
              Text@02E31060 refcount=3<YYY>
            >
            Text@02E30FB0 refcount=3<\n >
          >
          Text@02E30A30 refcount=3<\n>
        >
      >
      Text@02E304C0 refcount=3<\n\n>
    >
    Text@02E33E60 refcount=3<\n\n>
  >
>

Comment 7

[harishd]

I do see the hidden INPUT!! Chris??

If you see the content model the hidden INPUT has been moved inside TD, right 
above the inner TABLE. I think that's the correct behavior because if I place 
the hidden INPUT within the TD, above inner TABLE, to begin with, everything 
renders okay. This is definitely a layout issue not parser. Back to karnaze.

Comment 8

[Hixie (not reading bugmail)]

I'm tempted to recommend Futuring this bug, since it is invalid markup. And any
compat bugs that we Future might as well be marked WONTFIX since fixing them 
won't help authors (they won't be able to use the bad markup anyway, since N6
will have it broken already.)

WONTFIX?

Comment 9

[karnaze (gone)]

Marking rtm-.

Comment 10

[Jesse Ruderman]

this bug looks very similar to bug 55545.

Comment 11

[hirata masakazu]

*** Bug 65372 has been marked as a duplicate of this bug. ***

Comment 12

[Amarendra Hanumanula]

QA contact update

Comment 13

[Christian Mattar]

Both testcases look ok to me and look identical in Moz and IE5.
This seems to have been fixed.
jrgm or amar, could you either verify or reopen?

Comment 14

[John Morrison]

Sure, this was bug 55545, I think. verified.