[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
Sun Dec 3 18:32:42 PST 2017


https://bugs.webkit.org/show_bug.cgi?id=179682

--- Comment #45 from zalan <zalan at apple.com> ---
Comment on attachment 328250
  --> https://bugs.webkit.org/attachment.cgi?id=328250
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=328250&action=review

>> Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:73
>> +    }
> 
> I would write:
> 
>     RenderBox* fixingBox = stretchyOperator;
> 
> Instead of writing the static_cast.
> 
> I also would write this as a for loop:
> 
>     for (RenderBox* box = stretchyOperator; box != ancestor; box = box->parentBox()) {
>         box->setNeedsLayout();
>         box->layout();
>     }
> 
> But also, it is really strange to do synchronous calls to layout after setNeedsLayout. We need a layout expert to weigh in on this. It seems wrong. Antti? Zalan?

Normally you set the dirty bit on the renderer soon after you figure its position/size are invalid (usually result of a style change), schedule an async layout and here you would just call layoutIfNeeded(). 
However since in this function we are already have a valid layout context  (through RenderMathMLUnderOver::layoutBlock), this looks more like a multi-pass layout where the descendants need to be readjusted after some ancestors/siblings etc layouts are done. I don't know much about MathML so if that's not the case, then the setNeedsLayout calls are wrong here and they need to be moved somewhere else (see above). 
Even if it was a type of multi-pass layout, the stretch operation should probably dirty the descendants (since that's where the children get invalid) and you'd just call layoutIfNeeded here.

-- 
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/20171204/7ca6c455/attachment.html>


More information about the webkit-unassigned mailing list