23248 2009-01-12 02:07:50 -0800 CSS class change result in inconsistent layout 2022-07-11 16:38:53 -0700 1 1 1 Unclassified WebKit CSS 525.x (Safari 3.2) All All RESOLVED CONFIGURATION CHANGED P2 Normal --- 1 Adam_5Wu webkit-unassigned bfulgham robert stalcup oldest_to_newest 105315 0 Adam_5Wu 2009-01-12 02:07:50 -0800 As shown in the sample html: The element <label> initially has a class name "Top", which is associated to style "display: block"; this makes the label displayed above the text input; Then, by clicking on the "Right" button, the class name of the label is reassigned to "Right", which is associated to style "float: right". The label now should be displayed on the same line with the text input, to the right; but on Safari 3.2.1, the label is still displayed above the text input, and become right aligned. However, again on Safari 3.2.1, if the "Left" button (which has no style associated to it) is clicked first (essentially removes style "display: block"), then the "Right" button, the label's layout is rendered as expected. 105316 1 26628 Adam_5Wu 2009-01-12 02:10:00 -0800 Created attachment 26628 Sample html 105317 2 Adam_5Wu 2009-01-12 02:14:02 -0800 Google Chrome (1.0.154) also has the problem. 110351 3 ap 2009-02-19 23:11:09 -0800 Confirmed with r41058; this is not a regression from Safari/WebKit 3.2.1. 110405 4 hyatt 2009-02-20 10:19:34 -0800 This bug is tricky. The layout issue is basically caused by our inability to compute the correct m_maxPrefWidth for a rendering like this: <div style="position:absolute"> <div style="float:right">Hello</div> <div><input type=text></div> </div> It's hard for us to tell whether the float is going to fit into the next block in calcBlockPrefWidths. In the real test case attached to the bug, the initial display:block on the first div causes us to create an anonymous block to wrap the input field. When the first div is switched to just being floating instead, we could technically revert back to being inline again and remove the anonymous block (pulling its kids back up). So either trying to fix maxPrefWidth or trying to make anonymous blocks go away properly when float/position changes would fix the bug. 111127 5 neelima.web 2009-02-25 23:55:25 -0800 I have done some analysis on this bug. 1)I found issue in Node::Diff() I have done some changes in Node::Diff () by adding one more condition, which will detach the previous node with their respective properties and again attach with new properties to the node. Node::StyleChange Node::diff( RenderStyle *s1, RenderStyle *s2 ) { ......... ......... else if (*s1 != *s2) ch = Detach; OR else if (display1 == display2 || fl1 == fl2 || (s1 && s2 && s1->contentDataEquivalent(s2))) ch = Detach; ......... ......... } I have tested and the fix seems to be working fine. Kindly let me know whether this is a correct approach? 2)Need Clarification: I tried with another approach to resolve the same issue. Whenever select from left to right or Right to Top, the style is setting to Block level in CSSStyleSelectos::adjustRenderStylefunction() of CSSStyleSelector.cpp, I had tried to change ‘setDisplay’ value to inline for the ‘case :Top to Right’ but it’s not working. I found that in CSSStyleSelectos::adjustRenderStylefunction() , they are forcefully setting inline-level roots to be block-level , if someone attempts to float an inline. See the below code: void CSSStyleSelector::adjustRenderStyle(RenderStyle* style, Element *e) { // Mutate the display to BLOCK or TABLE for certain cases, e.g., if //someone attempts to position or float an inline, compact, or run-in. //Cache the original display, since it may be needed for positioned //elements that have to compute their static normal flow positions. //We also force inline-level roots to be block-level. if (style->display() != BLOCK && style->display() != TABLE && style->display() != BOX && (style->position() == AbsolutePosition || style->position() == FixedPosition || style->floating() != FNONE || (e && e->document()->documentElement() == e))) { if (style->display() == INLINE_TABLE) style->setDisplay(TABLE); else if (style->display() == INLINE_BOX) style->setDisplay(BOX); else if (style->display() == LIST_ITEM) { // It is a WinIE bug that floated list items lose their //bullets, so we'll emulate the quirk, but only in quirks mode. if (!m_checker.m_strictParsing && style->floating() != FNONE) style->setDisplay(BLOCK); } else style->setDisplay(BLOCK); // This part of code is getting hit when I // change from left to right or right to top } Please let me know why it has been done like this? 379154 6 stalcup 2011-04-04 15:53:01 -0700 this bug appears to be fixed now 732888 7 robert 2012-10-02 11:43:28 -0700 (In reply to comment #6) > this bug appears to be fixed now No, it's still valid. 1882215 8 bfulgham 2022-07-11 16:38:53 -0700 Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains. 26628 2009-01-12 02:10:00 -0800 2009-01-12 02:10:00 -0800 Sample html Test.html text/html 1025 Adam_5Wu PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0Ly9FTiIg Imh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXN0cmljdC5kdGQiPg0KPGh0 bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbDpsYW5nPSJlbiIgbGFu Zz0iZW4iPg0KICA8aGVhZD4NCiAgICA8dGl0bGU+RmxvYXQgY2xhc3MgdGVzdDwvdGl0bGU+DQog ICAgPHN0eWxlPg0KICAgICAgbGFiZWwuVG9wIHsNCiAgICAgICAgZGlzcGxheTogYmxvY2s7DQog ICAgICB9DQoNCiAgICAgIGxhYmVsLkxlZnQgew0KICAgICAgfQ0KDQogICAgICBsYWJlbC5SaWdo dCB7DQogICAgICAgIGZsb2F0OiByaWdodDsNCiAgICAgIH0NCiAgICA8L3N0eWxlPg0KICA8L2hl YWQ+DQogIDxib2R5Pg0KICAgIDxkaXYgc3R5bGU9InBvc2l0aW9uOiBhYnNvbHV0ZSI+DQogICAg ICA8Zm9ybT4NCiAgICAgICAgPGxhYmVsIGlkPSJUZXN0TGFiZWwiIGNsYXNzPSJUb3AiPlRlc3Qg TGFiZWw8L2xhYmVsPg0KICAgICAgICA8aW5wdXQgdHlwZT0idGV4dCIgdmFsdWU9IlNvbWUgVGV4 dCIvPg0KICAgICAgPC9mb3JtPg0KICAgICAgPGJ1dHRvbiB0eXBlPSJidXR0b24iIG9uY2xpY2s9 IkNhcHRpb25Qb3MoJ1RvcCcpIj5Ub3A8L2J1dHRvbj4NCiAgICAgIDxidXR0b24gdHlwZT0iYnV0 dG9uIiBvbmNsaWNrPSJDYXB0aW9uUG9zKCdMZWZ0JykiPkxlZnQ8L2J1dHRvbj4NCiAgICAgIDxi dXR0b24gdHlwZT0iYnV0dG9uIiBvbmNsaWNrPSJDYXB0aW9uUG9zKCdSaWdodCcpIj5SaWdodDwv YnV0dG9uPg0KICAgIDwvZGl2Pg0KICAgIDxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4N CiAgICAgIENhcHRpb25Qb3MgPSBmdW5jdGlvbihkaXIpIHsNCiAgICAgICAgdmFyIExhYmVsID0g ZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ1Rlc3RMYWJlbCcpOw0KICAgICAgICBMYWJlbC5jbGFz c05hbWUgPSBkaXI7DQogICAgICB9DQogICAgPC9zY3JpcHQ+DQogIDwvYm9keT4NCjwvaHRtbD4=