[Webkit-unassigned] [Bug 179682] Incorrect bounds inside <mover>/<munder> when a stretchy operator is present
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Nov 28 00:24:19 PST 2017
https://bugs.webkit.org/show_bug.cgi?id=179682
--- Comment #19 from Frédéric Wang (:fredw) <fred.wang at free.fr> ---
Comment on attachment 327719
--> https://bugs.webkit.org/attachment.cgi?id=327719
the algorithm in action (just for visual comparison, not a patch to review)
View in context: https://bugs.webkit.org/attachment.cgi?id=327719&action=review
Thanks for working on this. Good point about the lock/unlock. I've added comments to make it closer to the MathML spec / Firefox and less hacky. Can you please try it, test with the various testcases and run the MathML tests?
> Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp:194
> +
This should be setStretchWidthLocked(bool stretchWidthLocked) const { m_isStretchedWidthLocked = stretchWidthLocked; }.
Also setStretchWidthLocked and isStretchWidthLocked are small getter/setter so they can just be moved into the *.h file.
> Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:55
> + ASSERT(isValid());
Can you also repeat the ASSERT(needsLayout()) here? So that we are sure that the extra work in this function only happens when layout is needed.
> Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:56
> +
You might also consider introducing a helper function:
RenderOperator* toHorizontalStretchyOperator(RenderBox* box)
{
if (is<RenderMathMLBlock>(box)) {
if (auto renderOperator = downcast<RenderMathMLBlock>(*box).unembellishedOperator()) {
if (renderOperator->isStretchy() && !renderOperator->isVertical())
return renderOperator;
}
}
return nullptr;
}
> Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:-65
> - }
Can you skip non-stretchy operators with?
if (toHorizontalStretchyOperator(child))
continue;
This is copying the vertical stretchy rule "of the *non-stretchy* direct sub-expressions" of 3.2.5.8.2, but for horizontal stretching. That will cover the case of stretchy under/over and a non-stretchy base.
> Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:62
> +
I think you should first count the number of children satisfying toHorizontalStretchyOperator(child). If it is < number of children then you run the loop above and can even exit just after if it is == 0. It is is == number of children then you can instead do:
for (auto* child = firstChildBox(); child; child = child->nextSiblingBox()) {
auto renderOperator = toHorizontalStretchyOperator(child);
ASSERT(renderOperator);
renderOperator->resetStretchSize();
renderOperator->setStretchWidthLocked(true);
child->setNeedsLayout();
child->layout();
renderOperator->setStretchWidthLocked(false);
stretchWidth = std::max(stretchWidth, child->logicalWidth());
}
This will address the case "Skipping the embellished op does not work for nested structures like <munder><mover><mo>_</mo>...</mover> <mo>_</mo></munder>" where elements should stretch to the max unstretched size I guess.
> Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:66
> + if (renderOperator->isStretchy() && !renderOperator->isVertical() && !renderOperator->isStretchWidthLocked()) {
You can use
if (auto renderOperator == toHorizontalStretchyOperator()) {
if (!renderOperator->isStretchWidthLocked()) {
> Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:-74
> - stretchWidth = std::max(stretchWidth, child->logicalWidth());
Maybe move the comment in the loop I mentioned above.
> Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:80
> + stretchWidth = firstChildBox()->logicalWidth();
Then you don't need this hack anymore, as it is again addressed above.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171128/c40a9cf6/attachment.html>
More information about the webkit-unassigned
mailing list