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.
Canonical link: https://commits.webkit.org/155422@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@174540 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-10-09 23:48:09 +00:00
|
|
|
<!DOCTYPE html>
|
|
|
|
|
<html>
|
|
|
|
|
<head>
|
|
|
|
|
<style type="text/css">
|
|
|
|
|
@font-face {
|
|
|
|
|
font-family: stretchy;
|
|
|
|
|
src: url("stretchy.woff");
|
|
|
|
|
}
|
|
|
|
|
math {
|
|
|
|
|
font-family: stretchy;
|
|
|
|
|
font-size: 10px;
|
|
|
|
|
}
|
2014-10-10 22:29:20 +00:00
|
|
|
div {
|
|
|
|
|
width: 700px;
|
|
|
|
|
height: 100px;
|
|
|
|
|
background-color:#eeeeee;
|
|
|
|
|
}
|
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.
Canonical link: https://commits.webkit.org/155422@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@174540 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-10-09 23:48:09 +00:00
|
|
|
</style>
|
|
|
|
|
<body>
|
2014-10-10 22:29:20 +00:00
|
|
|
<div id="mathContainer">
|
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.
Canonical link: https://commits.webkit.org/155422@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@174540 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-10-09 23:48:09 +00:00
|
|
|
<math display='block'>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mmultiscripts>
|
|
|
|
|
<mi>C</mi>
|
|
|
|
|
<none/>
|
|
|
|
|
<mi>16</mi>
|
|
|
|
|
<mprescripts/>
|
|
|
|
|
<mi>5</mi>
|
|
|
|
|
<mi>10</mi>
|
|
|
|
|
</mmultiscripts>
|
|
|
|
|
</mrow>
|
|
|
|
|
<mspace width="0.5em"/>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mn>2</mn>
|
|
|
|
|
<mo>⁢</mo>
|
|
|
|
|
<msub>
|
|
|
|
|
<mi>H</mi>
|
|
|
|
|
<mn>2</mn>
|
|
|
|
|
</msub>
|
|
|
|
|
<mo>+</mo>
|
|
|
|
|
<msub>
|
|
|
|
|
<mi>O</mi>
|
|
|
|
|
<mn>2</mn>
|
|
|
|
|
</msub>
|
|
|
|
|
</mrow>
|
|
|
|
|
<mover>
|
|
|
|
|
<mo>→</mo>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mi>m</mi>
|
|
|
|
|
<mo>,</mo>
|
|
|
|
|
<mi>n</mi>
|
|
|
|
|
</mrow>
|
|
|
|
|
</mover>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mn>2</mn>
|
|
|
|
|
<mo>⁢</mo>
|
|
|
|
|
<msub>
|
|
|
|
|
<mi>H</mi>
|
|
|
|
|
<mn>2</mn>
|
|
|
|
|
</msub>
|
|
|
|
|
<mo>⁢</mo>
|
|
|
|
|
<mi>O</mi>
|
|
|
|
|
</mrow>
|
|
|
|
|
<mspace width="0.5em"/>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mi>A</mi>
|
|
|
|
|
</mrow>
|
|
|
|
|
<munderover>
|
|
|
|
|
<mo>↔</mo>
|
|
|
|
|
<mi>b</mi>
|
|
|
|
|
<mn>a</mn>
|
|
|
|
|
</munderover>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mi>B</mi>
|
|
|
|
|
</mrow>
|
|
|
|
|
<mspace width="0.5em"/>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mi>A</mi>
|
|
|
|
|
</mrow>
|
|
|
|
|
<munderover>
|
|
|
|
|
<mo>⇄</mo>
|
|
|
|
|
<mi>0</mi>
|
|
|
|
|
<mn>a</mn>
|
|
|
|
|
</munderover>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mi>B</mi>
|
|
|
|
|
</mrow>
|
|
|
|
|
<mspace width="0.5em"/>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mi>A</mi>
|
|
|
|
|
</mrow>
|
|
|
|
|
<munderover>
|
|
|
|
|
<mo>⇄</mo>
|
|
|
|
|
<mn>0°C</mn>
|
|
|
|
|
<mn>100°C</mn>
|
|
|
|
|
</munderover>
|
|
|
|
|
<mrow>
|
|
|
|
|
<mi>B</mi>
|
|
|
|
|
</mrow>
|
|
|
|
|
</math>
|
|
|
|
|
</div>
|
|
|
|
|
<script>
|
2014-10-10 22:29:20 +00:00
|
|
|
var mathDiv = document.getElementById("mathContainer");
|
|
|
|
|
|
|
|
|
|
mathDiv.style.width = "300px";
|
|
|
|
|
document.body.offsetWidth; // forces layout
|
|
|
|
|
|
|
|
|
|
mathDiv.style.width = "500px";
|
|
|
|
|
document.body.offsetWidth; // forces layout
|
|
|
|
|
|
|
|
|
|
mathDiv.style.width = "700px";
|
|
|
|
|
document.body.offsetWidth; // forces layout
|
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.
Canonical link: https://commits.webkit.org/155422@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@174540 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2014-10-09 23:48:09 +00:00
|
|
|
</script>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|