Relative width value of "*" used with COL element produces unexpected results

VERIFIED FIXED in M18

Status

()

P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: mozilla, Assigned: attinasi)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fix in hand] [nsbeta3+], URL)

Attachments

(4 attachments)

(Reporter)

Description

19 years ago
As the test case illustrates setting WIDTH to "*" and "1*" in the COL tag
produces different results, which is in breach of HTML 4.01 specification,
section 6.6 (<http://www.w3.org/TR/html4/types.html#type-multi-length>).
I'm running M13 on Windows NT with IE 5.01.
(Reporter)

Comment 1

19 years ago
Created attachment 5688 [details]
Test case for the bug

Updated

19 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: M15

Comment 2

19 years ago
In the testcase, the first table is rendering correctly. In the first table, the 
width of the first column should span 1/4 of the window and the width of the 
second column should span 3/4 of the window. 

The problem occurs when "*" or "0*" relative width values are used. The first 
column should span the minimum width necessary to hold the column's contents - 
which it does. I'm not sure what the behavior for the second column should be - 
I would assume it should span the remainder of the window. If there is only 1 
column with a relative width value of "0*", the column spans the entire window. 
Providing another testcase with 3 examples.

Revising the summary somewhat.
Summary: %MultiLength values of "*" and "1*" are not equivalent → Relative width value of "*" or "0*" used with muCOL element produces

Updated

19 years ago
Summary: Relative width value of "*" or "0*" used with muCOL element produces → Relative width value of "*" or "0*" used with COL element produces unexpected results

Comment 3

19 years ago
Created attachment 5726 [details]
expanded testcase

Comment 4

19 years ago
mass move to m16
Target Milestone: M15 → M16

Comment 5

19 years ago
Moving to M18.
Target Milestone: M16 → M18

Comment 6

19 years ago
Mark, the style system is converting "*" to a proportional value of 0 which is 
accounting for the problem in the 1st attachment. After that is fixed there may 
still be a table problem when dealing with the 2nd attachment. 
Assignee: karnaze → attinasi
Status: ASSIGNED → NEW
Target Milestone: M18 → ---
(Assignee)

Comment 7

19 years ago
Actually, it is the GenericHTMLElement that is making * == 0* instead of 1*

The method nsGenericHTMLElement::ParseValueOrPercentOrProportional needs to 
check for the special case of a proportional value '*' and set the value to 1, 
not 0. Easy fix, in my tree, I'll attach the patch. 

How important is this? Does anybody want to nominate it? The (first part of the) 
fix is simple enough, any remainder needs to go back to karnaze.
Status: NEW → ASSIGNED
(Assignee)

Comment 8

19 years ago
The patch I'm about to attach makes testcase 1 look correct (note that IE and 
Nav4 both get it wrong, differently). The second testcase shows layout problems 
in tables, not a parsing problem in attributes.
(Assignee)

Comment 9

19 years ago
Created attachment 9771 [details] [diff] [review]
Patch to fix the incorrect parsing of width value '*'
(Assignee)

Comment 10

19 years ago
Sending back to karnaze to deal with the remaining problems with table layout. 
Use the attached patch to fix the first problem.
Assignee: attinasi → karnaze
Status: ASSIGNED → NEW

Comment 11

19 years ago
I'm changing the summary from "Relative width value of "0*" used with COL 
element produces unexpected results" to "Relative width value of "*" used with 
COL element produces unexpected results" and reassigning back to attinasi. I'll 
spawn a new bug to deal with the "0*" issues. 

Marc, I think this bug should make it into FCS because it is low risk.
Assignee: karnaze → attinasi
Summary: Relative width value of "*" or "0*" used with COL element produces unexpected results → Relative width value of "*" used with COL element produces unexpected results

Comment 12

19 years ago
I just filed bug 42033 to deal with "0*"
(Assignee)

Comment 13

19 years ago
Nominating for nsbeta3: fix is in attached patch and is extremely low risk, 
simple, etc.
Status: NEW → ASSIGNED
Keywords: nsbeta3
Whiteboard: [fix in hand]
(Assignee)

Comment 14

19 years ago
Setting milestone and updating platform / OS / priority fields.
Severity: major → normal
OS: Windows NT → All
Hardware: PC → All
Target Milestone: --- → M18
(Assignee)

Updated

19 years ago
Keywords: correctness, patch
(Assignee)

Comment 15

19 years ago
Approved for beta3: low risk, correctness of HTML4.01 impl. and already fixed.
Whiteboard: [fix in hand] → [fix in hand] [nsbeta3+]
(Assignee)

Comment 16

19 years ago
Fix checked in. (nsGenericHTMLElement.cpp)
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 17

18 years ago
Using 8/25 build, bug is not fixed. If you look at the first testcase, the 
second table's col width's are not distributed correctly. It should be identical 
to the first table. 

Reopening bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 18

18 years ago
nsGenericHTMLElement::ParseValueOrPercentOrProportional has been changed and now 
it parses the '*' and tries to convert it to an integer and gets and error. This 
was part of jst and vidur's big string change, and it doesn;t quite work here.

The fix is simple: allow the error NS_ERROR_ILLEGAL_VALUE since that is actually 
valid in some cases. Patch to be attached...
Status: REOPENED → ASSIGNED
(Assignee)

Comment 19

18 years ago
Created attachment 13631 [details] [diff] [review]
New patch for the new string semantic: allow illegal-integer values in ParseValueOrPercentOrProportional
(Assignee)

Comment 20

18 years ago
Fix checked in (nsGenericHTMLElement.cpp)
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED

Comment 21

18 years ago
Tested across platform on 9/7 builds. Verifying bug fixed in regards to the "*" 
issue. Acknowledge that problems with "0*" still exist and have been written up 
in bug #42033.  
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.