I'm extracting this change from bug 152244.
This has already been done for horizontal stretchy operators in the RenderMathMLUnderOver refactoring (http://trac.webkit.org/changeset/199293)
Let's do that for RenderMathMLRow and vertical stretchy operators too.
We can then add appropriate ASSERT in the RenderMathMLOperator::stretchTo functions.
Note that this change causes test failures for the following dynamic DOM/style tests, probably because some relayout that used to be forced by useless stretchTo called is not done anymore.
So the solution from bug 152244 was to be a bit more aggressive with updates, until we better manage such things in the MathML code (bug 156536).
Created attachment 276329 [details]
Comment on attachment 276329 [details]
Attachment 276329 [details] did not pass mac-debug-ews (mac):
New failing tests:
Created attachment 276334 [details]
Archive of layout-test-results from ews112 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 276376 [details]
Comment on attachment 276376 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=276376&action=review
LGTM. Just a small nit comment in the tests.
> +<!-- Horizontal operators or non-stretchy operators inside an mrow element should not stretch. -->
Probably this is common in MathML tests, but its' not that common in other layout tests in WebKit.
This kind of test description is usually in a <p> or something like that. So you can read them if you just run the test in browser.
> +<!-- Vertical or non-stretchy operators inside an munderover element should not stretch. -->
Created attachment 276387 [details]
Comment on attachment 276387 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=276387&action=review
> + ASSERT(hasOperatorFlag(MathMLOperatorDictionary::Stretchy) && m_isVertical);
One of our rules for assertions is that we don’t use && at the top level of an assert expression. Instead we separately assert the two expressions on either side of the &&. That way if the assertion fails we can quickly see which failed.
Committed r199544: <http://trac.webkit.org/changeset/199544>
(In reply to comment #7)
> an assert expression. Instead we separately assert the two expressions on
> either side of the &&. That way if the assertion fails we can quickly see
> which failed.
OK, I split them. Thanks.