Bug 96960

Once its on, it the chromium fuzzer bots should tell us if we have any stability issues left to worry about. If so, we can always turn it off again before branching for m24 in another 6 weeks.

Sounds good!!

I've CC'd the upcoming WebKit gardeners for this week so they're aware of this impending change (feel free to remove yourself if you're not interested!)

http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/features.gypi is the file to change, btw.

We'll also want to remove this line once MATHML is turned back on: http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L1651 or perhaps as part of turning it on.

Other than checking for crashers, I think our two main issues will be: 1. Most of the MathML tests are pixel tests. I still need to tweak MathML layout sometimes, and when I do, it often triggers a ~1MB patch (sigh). This is almost all test results in LayoutTests/platform/*/mathml/presentation. Actually, so far the only platforms are mac, efl, and gtk. I verify the results in platform/mac, and lately Christophe Dumez usually checks the efl and gtk ones. I'd be happy to check results on various platforms if gardeners want to upload them or e-mail a zip file to me. Actually WebKit MathML isn't used yet in the wild too much, so we don't have to be too paranoid about small changes. If you check the .png files quickly and they look similar to the platform/mac ones, then I'd just rebaseline (.png and .txt) if I were you. If your .png files look bad, then please upload or send your results to me. 2. The biggest platform issue for MathML will doubtless be fonts. We can minimize this problem by ensuring the STIX fonts are on all the bots - then we might even be able to combine some pixel test baselines. On Mac bots the OS must be at least OS X 10.7.4, or else the STIX fonts come out always italic. Can someone verify the OS version on the Chromium Mac bots? There are also some issues on linux - search LayoutTests/platform/efl/Skipped for "mathml"; and see bug 47744; and bug 38377, comment 2 (I need to fix that, I think). But the biggest issue is probably -webkit-line-box-contain on Windows - see <http://code.google.com/p/chromium/issues/detail?id=77095>. Christophe Dumez was able to fix this on linux fairly quickly in bug 93073 - see its comments 8, 11 and 12, and its patch. It'd be great if a Windows font expert could do this on Windows also. Bug 48124 may also be an issue on Windows. Note the Apple Mac port doesn't enable subpixel layout yet I believe, so its MathML baselines may be slightly different from Chromium. I think the summary is that it'll be great to test MathML for crashes, and hopefully we can also get it looking good on Mac, Linux, and Windows soon. If not, we may have to turn it off on some platforms for now. But MathML in Chrome is still exciting!

(In reply to comment #4) > http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/features.gypi is the file to change, btw. Apparently you also have to add an include path of Source/WebCore/rendering/mathml somewhere. Does anyone know where? Has anyone been able to compile chromium with ENABLE(MATHML) locally? Is there anything else I need to do? Thanks in advance!

http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.gypi is where the files go, http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.gyp/WebCore.gyp is where the include paths go, I believe. Tony Chang is the many I ask all my gyp questions to, he'll correct me if I'm wrong. :)

I'm away from my work machine, otherwise I'd test this build for you. update-webkit-chromium && build-webkit --chromium should also work if you need to try yourself.

update-webkit-chromium is just the fancy script that update-webkit --chromium (note the space) calls to update the generated project files (in your case, XCode file, presumably) after each update. It can be called manually to update the generated project files w/o updating the repository (despite it's confusing name). :)

That all looks to be working great, thanks! (Sorry, I had been looking in Source/WebKit/chromium.)

Sounds like you got things building. For TestExpectations, I would just mark the lines as [ Failure ]. This will run the tests on the bot and allow anyone to rebaseline them using garden-o-matic. I don't think using a special font will avoid pixel results since there will still be antialiasing differences across platforms. It looks like there are only 32 pixel tests. Adding 32 * 2 (txt and png file) * 3 (win, mac, linux) = 192 files for Chromium pixel results isn't great, but I can't think of anything better. http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L1643

Thanks very much for the expert information and advice. I indeed have things building, but have been stuck on an assertion failure due to a combination of MathML, FlexBox, and SubPixel layout units. LayoutTests/mathml/presentation/roots.xhtml causes totalWeightedFlexShrink in RenderFlexibleBox::layoutFlexItems to go negative due to roundoff error, at least for chromium mac snowleopard with ENABLE(MATHML). I think the main issue is that MathML uses flexboxes but without any flex, so every child in RenderFlexibleBox::resolveFlexibleLengths becomes a violation [in a case where availableFreeSpace < 0]. Then RenderFlexibleBox::freezeViolations subtracts each preferredChildSize from totalWeightedFlexShrink [child->style()->flexShrink() is always 1], and the roundoff error brings totalWeightedFlexShrink slightly below 0. I realize I should file a bug for this, but it'd be easier after MathML is enabled in Chrome, since I haven't been able to reproduce this without MathML yet. However, I'm thinking this summary may be enough for Tony & Ojan to say something? Thanks greatly!

Calling in the sub-pixel brigade! (Be warned, all Googlers are distracted this week with annual peer-reviews, due friday.)

This sounds like a genuine flexbox bug. It's not clear to me where the bug is at a quick glance at the code. It's hard to look into it further without a flexbox-only test case.

I'm happy to help you flip this flag tomorrow if you'd like, Dave.

(In reply to comment #16) > I'm happy to help you flip this flag tomorrow if you'd like, Dave. I have it compiling, and could submit a patch to turn MathML on in Chrome, marking the layout tests as failing. I guess I was waiting on bug 98791, and I'm working on bug 97390, and also I'm guessing -webkit-line-box-contain will fail on Windows so all the MathML won't layout right there. There are also some smaller layout issues, but maybe it's better to turn MathML on so we can see these issues? I think I'll discuss this with you (Eric) by e-mail, so I can get clarity, thanks!

Created attachment 168027 [details] Patch

Comment on attachment 168027 [details] Patch If the EWS likes it, then I do. SGTM. Please let the bubbles roll before landing.

CCing todays gardeners.

Comment on attachment 168027 [details] Patch Attachment 168027 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14259163 New failing tests: http/tests/xmlviewer/dumpAsText/mathml.xml

abarth says "bring it on". Feel free to land whenever and we'll be in #webkit to help you clean up any troubles.

Created attachment 168056 [details] Patch

Comment on attachment 168056 [details] Patch Forwarding Eric's R+.

Committed r130950: <http://trac.webkit.org/changeset/130950>