table-layout:fixed fixed width col should win over pct width?

ASSIGNED
Assigned to

Status

()

Core
Layout: Tables
ASSIGNED
11 years ago
8 years ago

People

(Reporter: Amitava Bhattacharyya, Assigned: Saint Wesonga)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6

The ExtJS DatePicker doesn't render properly. It only shows a very wide table-type structure (the title bar etc.) but no text/buttons, i.e., there are no dates to pick. It works correctly in FireFox 2, IE 6/7, Opera etc., so I suspect this is a bug with Gran Paradiso. 

Reproducible: Always

Steps to Reproduce:
1. Goto http://extjs.com/deploy/ext/docs/index.html and select 'Examples and Demos' > 'Toolbar and Menus' > 'Toolbar and Menus'
2. Click on 'Button w/ Menus' > 'Choose a Date'

Actual Results:  
A very wide table structure is rendered. The rows (title bar, footer bar, etc) are styled properly, but no text anywhere. No dates, no buttons, nothing.

Expected Results:  
Should display a calendar date picker component.

Default Install w/ Adblock Plus.

Comment 1

11 years ago
Yes, i can cofirm this works on Branch, not on Trunk
Status: UNCONFIRMED → NEW
Component: General → Layout: Tables
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout.tables
Version: unspecified → Trunk
Could you find out when this regressed, using the builds at http://archive.mozilla.org/pub/firefox/nightly and/or http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly ?
Keywords: regression

Comment 3

11 years ago
it regressed between 04 December 2006 (works) and 10 December 2006 (don't work)

is this enough?
Seems likely to be a regression from the reflow branch landing, in that case. A minimized testcase would be nice :). You might also want to look through the dependency list for that bug to see if there are any duplicates.
Blocks: 300030

Comment 5

11 years ago
there seem to be an issue with

table-layout:fixed;

removing it from the css solves the problem...

Comment 6

11 years ago
Created attachment 272022 [details]
not-so reduced testcase

this is not so reduced, but it's at least self-contained

the only thing i could reproduce in another way is that table-layout:fixed; has different behaviuor between brach & trunk, in trunk it expands to 100% width, in branch it does not

Comment 7

10 years ago
Created attachment 284718 [details]
fx_ie_menu_button.png

I dont know this is also same issue.
There is a problem in Menu Button 
See 'Action Menu' button at
http://extjs.com/deploy/dev/examples/menu/actions.html

Comment 8

10 years ago
Here's an additional, reduced example.  I'm an Ext JS core developer, so if you need any assistance, please let me know.

http://localhost/ext/playpen/browser-bugs/FF/Beta4/datepicker.html
Um, localhost?  ;-)

Comment 10

10 years ago
D'oh!  Wrong tab ;)

http://extjs.com/playpen/browser-bugs/FF/Beta4/datepicker.html

Comment 11

9 years ago
I went to http://extjs.com/playpen/browser-bugs/FF/Beta4/datepicker.htmland the firebug shows that there is width set on the table style as on the containing div.

I am skeptical that is valid.

Comment 12

9 years ago
we need a reduced testcase to judge this.
Keywords: testcase-wanted
(Assignee)

Comment 13

9 years ago
Created attachment 389851 [details]
Reduced Testcase

Renders differently only on Firefox (in comparison to IE6-8, Safari, Opera)

Updated

9 years ago
Keywords: testcase-wanted → testcase
Summary: ExtJS DatePicker doesn't render → table-layout:fixed fixed width col should win over pct width?

Comment 14

9 years ago
Created attachment 389867 [details]
same testcase with reference redenring
(Assignee)

Comment 15

8 years ago
Created attachment 416514 [details] [diff] [review]
Patch
Assignee: nobody → wesongathedeveloper
Status: NEW → ASSIGNED
Attachment #416514 - Flags: review?(dbaron)
I think this is going to behave badly if a table-layout:fixed table has a column with a percentage width, and perhaps other cases as well.  In those cases the GetMinWidth code is designed to return only a minimum, and not a preferred width, which would need to be different.  That said, for the percentage case, we could probably fix it using a similar approach to the one we use for BasicTableLayoutStrategy, but I'm not sure (after a quick glance) if the other cases are things we can ever hit.
Comment on attachment 416514 [details] [diff] [review]
Patch

It might also be possible to do something that returns fixed widths when possible and otherwise returns nscoord_MAX.

But I don't think we want to do what this patch does.
Attachment #416514 - Flags: review?(dbaron) → review-
You need to log in before you can comment on or make changes to this bug.