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




18 years ago
18 years ago


(Reporter: jrgmorrison, Assigned: karnaze)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: WONTFIX ? -- non standards compliant [rtm-], URL)


(2 attachments)



18 years ago
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">

Comment 1

18 years ago
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 ... ).
Keywords: rtm

Comment 2

18 years ago
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.
Assignee: karnaze → harishd
Keywords: qawanted

Comment 3

18 years ago
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

18 years ago
Created attachment 16496 [details]
simplified table showing the problem.

Comment 5

18 years ago
Created attachment 16519 [details]
Further Reuuced...

Comment 6

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

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

18 years ago
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.
Assignee: harishd → karnaze
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.)

Keywords: qawanted → compat
Whiteboard: WONTFIX ? -- non standards compliant

Comment 9

18 years ago
Marking rtm-.
Whiteboard: WONTFIX ? -- non standards compliant → WONTFIX ? -- non standards compliant [rtm-]

Comment 10

18 years ago
this bug looks very similar to bug 55545.

Comment 11

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

Comment 12

18 years ago
QA contact update
QA Contact: chrisd → amar

Comment 13

18 years ago
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?
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 14

18 years ago
Sure, this was bug 55545, I think. verified.
You need to log in before you can comment on or make changes to this bug.