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>
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 ... ).
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
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.
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> > >
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.) WONTFIX?
Keywords: qawanted → compat
Whiteboard: WONTFIX ? -- non standards compliant
Whiteboard: WONTFIX ? -- non standards compliant → WONTFIX ? -- non standards compliant [rtm-]
this bug looks very similar to bug 55545.
*** Bug 65372 has been marked as a duplicate of this bug. ***
QA contact update
QA Contact: chrisd → amar
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?
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Sure, this was bug 55545, I think. verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.