Changeset 174540 in webkit


Ignore:
Timestamp:
Oct 9, 2014, 4:48:09 PM (11 years ago)
Author:
commit-queue@webkit.org
Message:

Source/WebCore:
RenderMathMLUnderOver adds spacing to the child operator indefinitely when resizing the window.
​https://bugs.webkit.org/show_bug.cgi?id=137330

Patch by Said Abou-Hallawa <​sabouhallawa@apple.com> on 2014-10-09
Reviewed by Darin Adler.

The layout for the <mundercover> math object happens in two separate passes. The first pass runs
the layout for the two children and then calculates the maximum child width. It then sets the
stretch size for the math operator child. And finally it runs the second layout pass by calling
the base class layout() function. The base class function then runs the layout for the children
rendering blocks. In the operator child function computePreferredLogicalWidths(), the stretch
size is used to adjust the width (or the height) of the operator. Then it adds the leading and
trailing spaces and the total will be the operator child width.

When resizing or zooming the window, the render objects are just invalidated but marked as 'needs-
Layout'. The problem is happening because the stretch size of the math operator is not reset
before running the layout. The old logical width (or height) of the the math operator child which
is equal to the stretch size plus the leading and trailing spaces for is compared with the glyph
size if the old logical width ( or height) is larger, it is set to be the stretch size. When it
is used again because of invalidation, new leading and trailing spaces are included in the new
logical width. So with every zooming-in or out or window resizing, new leading and trailing
spaces are added to the logical width of the math operator child or the math <munderober> object.

Ensure the stretch size of the math operator render object is reset before running its layout.
Running the layout means either the page is just loaded or it's invalidated which means, no
layout stall data should be used.

Test: mathml/opentype/munderover-window-resize.html

  • rendering/mathml/RenderMathMLOperator.cpp:

(WebCore::RenderMathMLOperator::resetStretchSize):

  • rendering/mathml/RenderMathMLOperator.h:

resetStretchSize() sets the stretch size to its original value when the class is created.

  • rendering/mathml/RenderMathMLUnderOver.cpp:

(WebCore::RenderMathMLUnderOver::layout):
Make sure the operator stretch size is reset before calling its layout. Also make sure the new
maximum stretch size to the operator objects that were invalid and needsLayout.

LayoutTests:
RenderMathMLUnderOver adds spacing to the child operator indefinitely when zooming or resizing the window.
​https://bugs.webkit.org/show_bug.cgi?id=137330

Patch by Said Abou-Hallawa <​sabouhallawa@apple.com> on 2014-10-09
Reviewed by Darin Adler, Daniel Bates.

When the alignment is center, which is the common case for math, changing the size of
an object affects the position of this object also. We need to confirm that zooming or
resizing the window should not affect the rectangle of the over/under math object operator.

  • mathml/opentype/munderover-window-resize-expected.txt: Added.
  • mathml/opentype/munderover-window-resize.html: Added.

New test with many under and over math objects. After loading the page, the window is resized and
the view is zoomed in and out to make sure the layout of these under and over objects were not changed.

  • platform/mac/mathml/opentype/opentype-stretchy-horizontal-expected.txt:

This test was wrong because of the spacing issue. The page has two <mover> math objects at the beginning.
Each of them has an <mspace> child. The width of the first <mspace> is 1em while the width of the second
<mspace> is 2em. The font size is 10pt. So it is expected to have the first one 10 pixels and the second
to be 20 pixels. In the test, the width of the first is 22 and the width of the second is 32.
I do expect this test to fail on other platforms since they have the same mistake which is now fixed. I am
going to submit the mac expected version only and when it fails I am going to collect the result and submit
another patch for the other platforms expected files.

Location:
trunk
Files:
2 added
6 edited

Legend:

Unmodified
Added
Removed

  • trunk/LayoutTests/ChangeLog

    r174537 r174540  
     12014-10-09  Said Abou-Hallawa  <sabouhallawa@apple.com>
     2
     3        RenderMathMLUnderOver adds spacing to the child operator indefinitely when zooming or resizing the window.
     4        https://bugs.webkit.org/show_bug.cgi?id=137330
     5
     6        Reviewed by Darin Adler, Daniel Bates.
     7
     8        When the alignment is center, which is the common case for math, changing the size of
     9        an object affects the position of this object also.  We need to confirm that zooming or
     10        resizing the window should not affect the rectangle of the over/under math object operator. 
     11
     12        * mathml/opentype/munderover-window-resize-expected.txt: Added.
     13        * mathml/opentype/munderover-window-resize.html: Added.
     14        New test with many under and over math objects.  After loading the page, the window is resized and
     15        the view is zoomed in and out to make sure the layout of these under and over objects were not changed.
     16        * platform/mac/mathml/opentype/opentype-stretchy-horizontal-expected.txt:
     17        This test was wrong because of the spacing issue. The page has two <mover> math objects at the beginning.
     18        Each of them has an <mspace> child. The width of the first <mspace> is 1em while the width of the second
     19        <mspace> is 2em. The font size is 10pt. So it is expected to have the first one 10 pixels and the second
     20        to be 20 pixels. In the test, the width of the first is 22 and the width of the second is 32.
     21        I do expect this test to fail on other platforms since they have the same mistake which is now fixed. I am
     22        going to submit the mac expected version only and when it fails I am going to collect the result and submit
     23        another patch for the other platforms expected files.
     24
    1252014-10-09  Dean Jackson  <dino@apple.com>
    226

  • trunk/LayoutTests/platform/mac/mathml/opentype/opentype-stretchy-horizontal-expected.txt

    r170699 r174540  
    88          RenderMathMLRow {mstyle} at (1,0) size 16x22
    99            RenderMathMLUnderOver {mover} at (0,0) size 16x22
    10               RenderMathMLOperator {mo} at (-6,1) size 27x21
    11                 RenderMathMLBlock (anonymous, flex) at (2,0) size 22x4
     10              RenderMathMLOperator {mo} at (0,1) size 16x21
     11                RenderMathMLBlock (anonymous, flex) at (2,0) size 11x4
    1212                  RenderBlock (anonymous) at (0,0) size 2x4
    1313                    RenderText at (0,-3) size 2x10
    … …  
    1919          RenderMathMLRow {mstyle} at (1,0) size 26x22
    2020            RenderMathMLUnderOver {mover} at (0,0) size 26x22
    21               RenderMathMLOperator {mo} at (-6,1) size 38x21
    22                 RenderMathMLBlock (anonymous, flex) at (2,0) size 32x4
     21              RenderMathMLOperator {mo} at (0,1) size 26x21
     22                RenderMathMLBlock (anonymous, flex) at (2,0) size 22x4
    2323                  RenderBlock (anonymous) at (0,0) size 2x4
    2424                    RenderText at (0,-3) size 2x10
    … …  
    3030          RenderMathMLRow {mstyle} at (1,0) size 156x42
    3131            RenderMathMLUnderOver {mover} at (0,0) size 156x42
    32               RenderMathMLOperator {mo} at (-3,1) size 162x41
    33                 RenderMathMLBlock (anonymous, flex) at (2,0) size 157x4
     32              RenderMathMLOperator {mo} at (0,1) size 156x41
     33                RenderMathMLBlock (anonymous, flex) at (2,0) size 151x4
    3434                  RenderBlock (anonymous) at (0,0) size 2x4
    3535                    RenderText at (0,-3) size 2x10

  • trunk/Source/WebCore/ChangeLog

    r174536 r174540  
     12014-10-09  Said Abou-Hallawa  <sabouhallawa@apple.com>
     2
     3        RenderMathMLUnderOver adds spacing to the child operator indefinitely when resizing the window.
     4        https://bugs.webkit.org/show_bug.cgi?id=137330
     5
     6        Reviewed by Darin Adler.
     7
     8        The layout for the <mundercover> math object happens in two separate passes. The first pass runs
     9        the layout for the two children and then calculates the maximum child width.  It then sets the
     10        stretch size for the math operator child.  And finally it runs the second layout pass by calling
     11        the base class layout() function. The base class function then runs the layout for the children
     12        rendering blocks.  In the operator child function computePreferredLogicalWidths(), the stretch
     13        size is used to adjust the width (or the height) of the operator. Then it adds the leading and
     14        trailing spaces and the total will be the operator child width.
     15
     16        When resizing or zooming the window, the render objects are just invalidated but marked as 'needs-
     17        Layout'.  The problem is happening because the stretch size of the math operator is not reset
     18        before running the layout.  The old logical width (or height) of the the math operator child which
     19        is equal to the stretch size plus the leading and trailing spaces for is compared with the glyph
     20        size if the old logical width ( or height) is larger, it is set to be the stretch size.  When it
     21        is used again because of invalidation, new leading and trailing spaces are included in the new
     22        logical width.  So with every zooming-in or out or window resizing, new leading and trailing
     23        spaces are added to the logical width of the math operator child or the math <munderober> object.
     24       
     25        Ensure the stretch size of the math operator render object is reset before running its layout.
     26        Running the layout means either the page is just loaded or it's invalidated which means, no
     27        layout stall data should be used.
     28
     29        Test: mathml/opentype/munderover-window-resize.html
     30
     31        * rendering/mathml/RenderMathMLOperator.cpp:
     32        (WebCore::RenderMathMLOperator::resetStretchSize):
     33        * rendering/mathml/RenderMathMLOperator.h:
     34        resetStretchSize() sets the stretch size to its original value when the class is created.
     35        * rendering/mathml/RenderMathMLUnderOver.cpp:
     36        (WebCore::RenderMathMLUnderOver::layout):
     37        Make sure the operator stretch size is reset before calling its layout. Also make sure the new
     38        maximum stretch size to the operator objects that were invalid and needsLayout.
     39
    1402014-10-09  Dean Jackson  <dino@apple.com>
    241

  • trunk/Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp

    r170774 r174540  
    13091309}
    13101310
     1311void RenderMathMLOperator::resetStretchSize()
     1312{
     1313    if (m_isVertical) {
     1314        m_stretchHeightAboveBaseline = 0;
     1315        m_stretchDepthBelowBaseline = 0;
     1316    } else
     1317        m_stretchWidth = 0;
     1318}
     1319
    13111320FloatRect RenderMathMLOperator::boundsForGlyph(const GlyphData& data) const
    13121321{

  • trunk/Source/WebCore/rendering/mathml/RenderMathMLOperator.h

    r174375 r174540  
    6767    void stretchTo(LayoutUnit width);
    6868    LayoutUnit stretchSize() const { return m_isVertical ? m_stretchHeightAboveBaseline + m_stretchDepthBelowBaseline : m_stretchWidth; }
     69    void resetStretchSize();
    6970   
    7071    bool hasOperatorFlag(MathMLOperatorDictionary::Flag flag) const { return m_operatorFlags & flag; }

  • trunk/Source/WebCore/rendering/mathml/RenderMathMLUnderOver.cpp

    r174375 r174540  
    7575{
    7676    LayoutUnit stretchWidth = 0;
     77    Vector<RenderMathMLOperator*, 2> renderOperators;
     78
    7779    for (RenderObject* child = firstChild(); child; child = child->nextSibling()) {
    78         if (child->needsLayout())
     80        if (child->needsLayout()) {
     81            if (is<RenderMathMLBlock>(child)) {
     82                if (auto renderOperator = downcast<RenderMathMLBlock>(*child).unembellishedOperator()) {
     83                    renderOperator->resetStretchSize();
     84                    renderOperators.append(renderOperator);
     85                }
     86            }
     87
    7988            toRenderElement(child)->layout();
     89        }
     90
    8091        // Skipping the embellished op does not work for nested structures like
    8192        // <munder><mover><mo>_</mo>...</mover> <mo>_</mo></munder>.
    … …  
    8596
    8697    // Set the sizes of (possibly embellished) stretchy operator children.
    87     for (auto& child : childrenOfType<RenderMathMLBlock>(*this)) {
    88         if (auto renderOperator = child.unembellishedOperator())
    89             renderOperator->stretchTo(stretchWidth);
    90     }
     98    for (auto& renderOperator : renderOperators)
     99        renderOperator->stretchTo(stretchWidth);
    91100
    92101    RenderMathMLBlock::layout();
Note: See TracChangeset for help on using the changeset viewer.