[Webkit-unassigned] [Bug 179682] Incorrect bounds inside <mover>/<munder> when a stretchy operator is present

[bugzilla-daemon at webkit.org]

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

--- Comment #52 from Minsheng Liu <lambda at liu.ms> ---
(In reply to Frédéric Wang (:fredw) from comment #51)
> (In reply to Minsheng Liu from comment #50)
> > 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.
> 
> Sorry, I was not clear. I mean (quickly looking to the implementation of
> layoutIfNeeded) it seems marking the <mo> at the core dirty will also
> already mark the whole ancestor chain and then you just need to layout the
> direct child.

That will be great (but unintuitive…I clearly need more understanding of those little layout functions). I will double check that.

Other replies:

> mathml/opentype/opentype-stretchy-horizontal.html is a pixel test to check the rendering of stretchy operators with a base size, variant size and glyph assembly. The rendering is *not* tested by the new test so you should not disable it. Operator spacing is irrelevant for this mathml/opentype/opentype-stretchy-horizontal.html, though so please open a preliminary bug that sets lspace="0px" rspace="0px" on the <mo> operators of this mathml/opentype/opentype-stretchy-horizontal.html and updates the PNG/txt expectations, so that we can really see what this patch is changing (hopefully it should not change anything).

Yeah that is a better idea. I will get it done soon. Note that the RenderTree will be different since the width of the stretchy operator will change. The pixel test should be fine, but let’s figure it out.

> This is wrong as it does not work the base case (no embellishments, first row of attachment 328081 [details]). I think what you want is two LayoutUnit variables stretchWidthForScripts and stretchWidthForBase both are set to the maximum of the width of non-stretchy children in the first loop as this is what is clear from the spec. Then you can adjust stretchWidthForScripts and stretchWidthForBase to include other widths of stretchy children in the calculation.

I will look into that when I get home.

> I'm not sure you really need these helper functions. The variables and extra comments should be enough.

I will conform to whatever WebKit chooses. It does make the structure more clear and easier to modify, at least in the current iterative process.

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