Forms in tables produce 'ghost' buttons when table is in an inline container

RESOLVED WORKSFORME

Status

()

Core
Layout
P3
minor
RESOLVED WORKSFORME
16 years ago
14 years ago

People

(Reporter: Thomas Nilsson, Assigned: Marc Attinasi)

Tracking

({compat, regression, testcase})

Trunk
mozilla1.1alpha
compat, regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

16 years ago
When having a few forms in a table, it can in some cases result in the rendering
of several 'ghost' buttons with no labels on them. This 'bug' might be related
to poor html, but the way it manifests itself would suggest there is something
wrong with the layout engine. I've verified it with Mozilla 0.9.5 and Mozilla
0.9.6 in both Linux and Windows 98.

Comment 1

16 years ago
Reporter, nesting in example isn't IMHO correct in HTML.
The whole _point_ is that this is a misnesting case that we fail to deal with. 
Over to parser -- I see the bug clearly in a current linux build.  The problem
seems to be partly due to the inline element that contains the <table>.

Great testcase, by the way!
Assignee: attinasi → harishd
Status: UNCONFIRMED → NEW
Component: Layout → Parser
Ever confirmed: true
OS: Windows 98 → All
QA Contact: petersen → moied
Hardware: PC → All
Keywords: compat, testcase

Comment 4

16 years ago
This looks ugly. |Should| get fixed.
--> 0.9.8
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8

Comment 5

16 years ago
Created attachment 61599 [details]
Testcase [ Note: Removing </b> fixes the problem ]

Apparently the problem happens when an inline element is allowed to contain
TABLE. Parser allows this when the inline element is wellformed ( eeeks! ).
Therefore if you remove </inline element> the problem should go away. 

Note: Fixing this bug would cost performance! ( refer bug 100397 ).

Comment 6

16 years ago
Created attachment 61600 [details]
Testcase [ with </b> present ]

Comment 7

16 years ago
This is a regression. I don't see the problem in N6.2. 

Note: Parser's behavior hasn't changed w.r.t. wellformed inline element
containing TABLE. 

--> Layout.
Assignee: harishd → attinasi
Status: ASSIGNED → NEW
Component: Parser → Layout
Keywords: regression
QA Contact: moied → petersen
(Assignee)

Comment 8

16 years ago
Yet Another Block In Inline bug...
Status: NEW → ASSIGNED
Summary: Forms in tables produce 'ghost' buttons → Forms in tables produce 'ghost' buttons when table is in an inline container
(Assignee)

Comment 9

16 years ago
Bulk push to next milestone
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Updated

16 years ago
Priority: P2 → P3
Target Milestone: mozilla0.9.9 → mozilla1.1

Comment 10

16 years ago
I 'm not seeing this on Win98, 2002021503. Testcases and url rendered in the
same way in Moz as in IE 5.5. Fixed?

Comment 11

16 years ago
Also tested with RC2 (2002051006) on Win2k and everything works well.
(Looks like IE5 and NS4.7 - no ugly ghost buttons)
Might really be WFM?

Comment 12

16 years ago
Created attachment 88131 [details]
Mozilla Alpha 1 Screenshot of Bad Table layout

I'm not sure if this is the same problem or not, but I think it might be.
Mozilla 1.1 Alpha mis-handles tables when form information is embedded. Neither
a strict nor loose DTD declaration affect this behavior in any way.

A screen shot of the correct behavior under mozilla 1.0 rc3 can be seen here:

http://www.furinkan.net/moz1.0rc3.png

A screen shot of the incorrect behavior under mozilla 1.1 alpha can be seen
here:

http://www.furinkan.net/moz1.1a1.png

The page both these screenshots reference is:

http://www.furinkan.net/display.php?command=gallery&directory=ranma/screencap

Comment 13

16 years ago
Created attachment 90625 [details]
Tables containing form results in empty cells

Test code which display a two columns table on IE (and Mozilla 1.0, I believe) 

but displays three columns with mozilla 1.1a

Comment 14

16 years ago
To comment #13: I can confirm it with 1.1a on Win2k, but 2002070813 (post-1.1a
trunk build) does only display 2 columns here.
The same for comment #12: wrong in 1.1a, but correct in later trunk build (today's).
Martin, cjones and others, can you try it with a up-to-date trunk build?
Is there anything left of this bug, then?
This is worksforme in a current build.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.