100507 2012-10-26 05:06:54 -0700 Progress bar shadow tree sometimes is not relayouted. 2012-10-29 02:18:01 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) PC All RESOLVED DUPLICATE 83664 P2 Normal --- 0 halyavin webkit-unassigned tasak oldest_to_newest 751908 0 170899 halyavin 2012-10-26 05:06:54 -0700 Created attachment 170899 test page Progress bar shadow tree sometimes is not relayouted. Steps to reproduce: 1. Open page in attachment. 2. Click on a button. 3. See that first bar is updated while second bar is not. What is going on behind the cover: HTMLProgressElement has a shadow tree which consist in 3 nested divs. The most nested div (HTMLProgressElement::m_value) represents progress bar value and is updated by HTMLProgressElement::didElementStateChange method. When javascripts on the page sets the second progress bar value, m_value node loses IsStyleAttributeValidFlag flag. Then <progress> element is inserted into tree and InDocumentFlag is set in m_value. Then Element::recalcStyle is called on HTMLProgressElement and it executes reattach method for it. Method reattach calls attach and as result m_value receives IsAttachedFlag. Then HTMLProgressElement::attach calls didElementStateChange method which calls m_value->setWidthPercentage which sets InlineStyleChange flag to m_value node and ChildNeedsStyleRecalc flag to all its parent nodes. But then reattach methods returns and Element::recalcStyle calls clearNeedsStyleRecalc and clearChildNeedsStyleRecalc methods on HTMLProgressElement node. So now we have m_value node that needs style recalculation but HTMLProgressElement node doesn't have ChildNeedsStyleRecalcFlag flag. As a result, any subsequent changes to progress element doesn't do anything since m_value is already marked as needed to recalculate style. But m_value never recalculates style since HTMLProgressElement doesn't have ChildNeedsRecalcFlag. 753180 1 tasak 2012-10-29 02:18:01 -0700 The reason why progress bar is not re-layouted is: - HTMLProgressElement updates inline styles, i.e. setWidthPercentage, in HTMLProgressElement::attach(). - Element::recalcStyle updates HTMLProgressElement's style by using "reattach()". Element::reaclcStyle() ... // FIXME: The style gets computed twice by calling attach. We could do better if we passed the style along. reattach(); // attach recalculates the style for all children. No need to do it twice. clearNeedsStyleRecalc(); clearChildNeedsStyleRecalc(); ... So after reattach(), clearNeedsStyleRecalc() and clearChildNeedsStyleRecalc() reset update flags set by setWidthPercentage. Now ProgressValueElement has had "InlineStyleChange" style change type, but its relayout flag is cleared. This disables "setNeedsStyleRecalc" to relayout: void Node::setNeedsStyleRecalc(...) ... if (existingChangeType == NoStyleChange) markAncestorsWithChildNeedsStyleRecalc(); ... I will fix this issue by bug 83664. Best regards, Takashi Sakamoto *** This bug has been marked as a duplicate of bug 83664 *** 170899 2012-10-26 05:06:54 -0700 2012-10-26 05:06:54 -0700 test page test.html text/html 758 halyavin PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp cHQiPgogIGZ1bmN0aW9uIGFkZF9wcm9ncmVzc19iYXIoKQogIHsKICAgIGJhZCA9IGRvY3VtZW50 LmNyZWF0ZUVsZW1lbnQoInByb2dyZXNzIik7CiAgICBiYWQuaWQ9ImJhZCI7CiAgICBiYWQuc2V0 QXR0cmlidXRlKCJtaW4iLDApOwogICAgYmFkLm1heD0xMDA7CgogICAgYmFkLnNldEF0dHJpYnV0 ZSgidmFsdWUiLDEwKTsgICAgICAgICAgICAgICAgIC8vUHJvYmxlbSBsaW5lIDEKICAgIGJhZC5z ZXRBdHRyaWJ1dGUoInN0eWxlIiwgImJvcmRlcjpzb2xpZCByZWQiKTsgLy9Qcm9ibGVtIGxpbmUg MgoKICAgIGRvY3VtZW50LmdldEVsZW1lbnRzQnlUYWdOYW1lKCdib2R5JylbMF0uYXBwZW5kQ2hp bGQoYmFkKTsKICB9CgogIGZ1bmN0aW9uIGNoYW5nZV92YWx1ZSgpCiAgewogICAgZG9jdW1lbnQu Z2V0RWxlbWVudEJ5SWQoJ2dvb2QnKS52YWx1ZSA9IDUwOwogICAgZG9jdW1lbnQuZ2V0RWxlbWVu dEJ5SWQoJ2JhZCcpLnZhbHVlID0gNTA7CiAgfQo8L3NjcmlwdD4KPC9oZWFkPgoKPGJvZHkgb25s b2FkPSJhZGRfcHJvZ3Jlc3NfYmFyKCk7Ij4KICAgIDxidXR0b24gb25jbGljaz0iY2hhbmdlX3Zh bHVlKCk7Ij5DbGljazwvYnV0dG9uPgoKICAgIDxwcm9ncmVzcyBpZD0iZ29vZCIgbWluPSIwIiBt YXg9IjEwMCIgdmFsdWU9IjEwIiBzdHlsZT0iYm9yZGVyOnNvbGlkIHJlZCI+PC9wcm9ncmVzcz4K PC9ib2R5PgoKPC9odG1sPgo=