[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
Mon Dec 4 09:07:32 PST 2017


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

--- Comment #50 from Minsheng Liu <lambda at liu.ms> ---
(In reply to Frédéric Wang (:fredw) from comment #49)
> Comment on attachment 328323 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=328323&action=review
> 
> > Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp:71
> > +    ancestor->layoutIfNeeded();
> 
> (this comment was lost, so adding it again)
> 
> This seems complicated. Isn't it enough to call setNeedsLayout() on the
> stretchyOperator and layoutIfNeeded() on the direct children of <munderover>?

Oh that is the main point of this new patch! Consider the following case:

<munder> // we are executing layout here
  <msub>
    <mover>
      <msup>
        <mo>...</mo> // the <mo> being stretched
      </msup>
    </mover>
  </msub>
  ...
</munder>

When layoutIfNeeded() is called on <msub>, it will find its immediate child <mover> clean, so the recursion will not go down. I have tested and making sure the whole chain from the immediate child to the operator at its core dirty is crucial for correct layout.

Note that this approach only requires minimal re-layout. Essentially, only logicalWidth() and location() are updated. Therefore, I could get rid of my initially complicated first loop and counter-based lock and all other crazy stuff. I think we are optimal 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/5202b7ea/attachment-0001.html>


More information about the webkit-unassigned mailing list