25016 2009-04-02 17:59:52 -0700 max-width and max-height are not overriding the width and height properties when 'display' set to 'table' 2012-12-18 11:10:05 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) All All RESOLVED FIXED HasReduction P2 Normal --- 98455 98633 1 jasneet webkit-unassigned daniekatz eric hyatt jamesr jasneet jchaffraix jparent julo pravind.2k4 robert stephen.cantini tony oldest_to_newest 116375 0 jasneet 2009-04-02 17:59:52 -0700 I Steps: 1. Go to attached testcase II Issue: width and height are overriding max-width and max-height (max-width and max-height must override width and height) III Other Browsers: FF3: OK IE7: OK IV Nightly tested: 42138 Bug in Chromium : http://code.google.com/p/chromium/issues/detail?id=9550 116376 1 29213 jasneet 2009-04-02 18:00:37 -0700 Created attachment 29213 testcase 116393 2 daniekatz 2009-04-02 22:38:02 -0700 There is a minor mistake in 'Other browsers' section: IE7 doesn't support 'display:table' at all, so originally I've tested the test case on IE8. IE8: OK 126041 3 eric 2009-06-15 14:48:01 -0700 Hyatt? I have confirmed that our behavior does not match FF3. 126051 4 eric 2009-06-15 15:10:14 -0700 Hyatt says that tables have had this bug forever. In general our table support needs improving. Perhaps a member of the Tokyo team would be up to the task. 454420 5 julo 2011-08-21 13:43:52 -0700 Any chance that somebody will look into this? Are there any workarounds? 617119 6 stephen.cantini 2012-05-06 10:14:47 -0700 +1 Some time has passed... any news? The only workaround I have found is wrapping the table inside a div with "max-width" set...a css-only solution would be much appreciated. 617120 7 eric 2012-05-06 10:22:23 -0700 The bug is presumably in RenderBox::computeLogicalHeight: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderBox.cpp#L2025 617125 8 stephen.cantini 2012-05-06 10:49:56 -0700 DISCLAIMER: I've never looked at the webkit code before. Could it be in RenderBox::computeLogicalWidthInRegion() for the ignored "max-width" part? If this is the case, maybe it never reaches this if statement http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderBox.cpp#L1765 730676 9 stephen.cantini 2012-09-28 08:27:04 -0700 Any news from the tokyo team or anybody else on this issue? Is there anything else I can do to help solve it? Someone to contact directly? 730863 10 tony 2012-09-28 12:05:24 -0700 The bug is probably in RenderTable::updateLogicalWidth. You can see that it checks against min-width, but there's no code for max-width. http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderTable.cpp?rev=129929#L258 I'm not sure how table height gets computed, but if you look in RenderBox::computeLogicalHeight, it only calculates margins. I suspect the height is updated by it's children or something. 730913 11 jchaffraix 2012-09-28 13:01:03 -0700 > I'm not sure how table height gets computed, but if you look in RenderBox::computeLogicalHeight, it only calculates margins. I suspect the height is updated by it's children or something. The logical height computation is in RenderTable::layout(). We need to check for the min / max logical height and update |computedLogicalHeight| accordingly. Note that the effect of min / max width / height on tables is undefined in CSS 2.1 (http://www.w3.org/TR/CSS21/visudet.html#propdef-max-width) so we will need to evaluate what other browsers are doing in some corner cases (e.g. should we shrink our content if max-height is defined? (we never shrink our height currently as it would violate CSS 2.1 tables: we could make a cell smaller than the minimum height for its content)) 793846 12 jchaffraix 2012-12-18 11:10:05 -0800 After bug 98455 and bug 98633, this is fixed. 29213 2009-04-02 18:00:37 -0700 2009-04-02 18:00:37 -0700 testcase maxwidth_maxheight_chrome.htm text/html 1661 jasneet 77u/PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRp b25hbC5kdGQiPg0KDQo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCI+ DQo8aGVhZD4NCiAgICA8dGl0bGU+PC90aXRsZT4NCiAgICA8c3R5bGUgdHlwZT0idGV4dC9jc3Mi Pg0KICAgICAgICAucGFyZW50DQogICAgICAgIHsNCiAgICAgICAgICAgIGJvcmRlcjoxcHggc29s aWQgcmVkOw0KICAgICAgICAgICAgaGVpZ2h0OjEwMHB4Ow0KICAgICAgICAgICAgaGVpZ2h0OjMw MHB4Ow0KICAgICAgICAgICAgd2lkdGg6MzAwcHg7DQogICAgICAgIH0NCiAgICAgICAgDQogICAg ICAgIC5wYXJlbnQgLmNoaWxkDQogICAgICAgIHsNCiAgICAgICAgICAgIGJhY2tncm91bmQtY29s b3I6Izk5OTk5OTsNCiAgICAgICAgICAgIGJvcmRlcjoxcHggc29saWQgZGFya2dyZWVuOw0KICAg ICAgICB9DQogICAgPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KICAgIDxkaXYgY2xhc3M9InBh cmVudCI+DQogICAgICAgIDxkaXYgY2xhc3M9ImNoaWxkIiBzdHlsZT0iZGlzcGxheTp0YWJsZTsg bWF4LXdpZHRoOjIwMHB4OyB3aWR0aDoxMDAlOyI+DQogICAgICAgICAgICBBY2NvcmRpbmcgdG8g dGhlIDxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSL0NTUzIxL3Zpc3VkZXQuaHRtbCNwcm9w ZGVmLW1heC13aWR0aCI+Q2FzY2FkaW5nIFN0eWxlIFNoZWV0cyBMZXZlbCAyIFJldmlzaW9uIDEg KENTUyAyLjEpIFNwZWNpZmljYXRpb248L2E+LCB0aGUgJ21heC13aWR0aCcgbXVzdCBvdmVycmlk ZSB0aGUgJ3dpZHRoOjEwMCUnIHNldHRpbmcuIDxiciAvPg0KICAgICAgICAgICAgQW5kIGl0IGRv ZXMgYmVoYXZlcyB0aGlzIHdheSBpZiAnZGlzcGxheScgc2V0IHRvICdibG9jaycuIDxiciAvPg0K ICAgICAgICAgICAgPGJyIC8+DQogICAgICAgICAgICBUaGUgYnJvd3NlcnMgSUU4LCBGRjMgYW5k IE9wZXJhIDkuNjQgYXJlIHJlbmRlcmluZyB0aGlzIHRoZSByaWdodCB3YXkuDQogICAgICAgIDwv ZGl2Pg0KICAgIDwvZGl2Pg0KICAgIDxkaXYgY2xhc3M9InBhcmVudCI+DQogICAgICAgIDxkaXYg Y2xhc3M9ImNoaWxkIiBzdHlsZT0iZGlzcGxheTp0YWJsZTsgbWF4LWhlaWdodDoyMDBweDsgaGVp Z2h0OjEwMCU7Ij4NCiAgICAgICAgICAgIEFjY29yZGluZyB0byB0aGUgPGEgaHJlZj0iaHR0cDov L3d3dy53My5vcmcvVFIvQ1NTMjEvdmlzdWRldC5odG1sI3Byb3BkZWYtbWF4LWhlaWdodCI+Q2Fz Y2FkaW5nIFN0eWxlIFNoZWV0cyBMZXZlbCAyIFJldmlzaW9uIDEgKENTUyAyLjEpIFNwZWNpZmlj YXRpb248L2E+LCB0aGUgJ21heC1oZWlnaHQnIG11c3Qgb3ZlcnJpZGUgdGhlICdoZWlnaHQ6MTAw JScgc2V0dGluZy4gPGJyIC8+DQogICAgICAgICAgICBBbmQgaXQgZG9lcyBiZWhhdmVzIHRoaXMg d2F5IGlmICdkaXNwbGF5JyBzZXQgdG8gJ2Jsb2NrJy4gPGJyIC8+DQogICAgICAgICAgICA8YnIg Lz4NCiAgICAgICAgICAgIFRoZSBicm93c2VycyBJRTggYW5kIEZGMyBhcmUgcmVuZGVyaW5nIHRo aXMgdGhlIHJpZ2h0IHdheS4NCiAgICAgICAgPC9kaXY+DQogICAgPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo=