[Webkit-unassigned] [Bug 137330] RenderMathMLUnderOver adds spacing to the child operator indefinitely when resizing the window

[bugzilla-daemon at webkit.org]

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





--- Comment #17 from Said Abou-Hallawa <sabouhallawa at apple.com>  2014-10-08 18:20:03 PST ---
(In reply to comment #15)
> (From update of attachment 239448 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=239448&action=review
> 
> review- because of the test failures, otherwise looks fine
> 
> > Source/WebCore/rendering/mathml/RenderMathMLOperator.h:69
> > +    void resetStretchSize() { m_isVertical ? m_stretchHeightAboveBaseline = m_stretchDepthBelowBaseline = 0 : m_stretchWidth = 0; }
>
> I think we should start this as private. Seems like the body could be inside the RenderMathMLOperator.cpp file, too. We could still mark it inline, but don’t need it in the header.
> 
> Also, WebKit coding style explicitly frowns upon setting two variables with a single chained assignment statement and implicitly frowns upon using the ?: operator on an expression with side effects. I think we should just use a plain old if statement for this.
> 

Done expect it is still public.  The reason is it will be called from RenderMathMLUnderOver::layout(). More about the need for this is explained below.

> > Source/WebCore/rendering/mathml/RenderMathMLOperator.h:77
> > +    virtual void layout() override;
> 
> I suggest making this protected, or perhaps even private.

I had to go back to my original solution: resetting the stretch size before running the layout for the math operator in the RenderMathMLUnderOver::layout().  The reason is forcing stretching the math operator should happen only in RenderMathMLUnderOver.  But the math operator itself can have stretch size set in the html page and in this case we should not change the stretch size.  We need to limit resetting the stretch size of the math operator to the case where it is a child of a  RenderMathMLUnderOver object and not always as I was doing in the previous patch.  This was the reason for the test cases failures.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.