Bug 130322

Created attachment 226900 [details] WIP Patch Here is a first patch that applies on top of bug 130321. I still need to write tests for that. I'm not sure whether I can use Web fonts or if the appropriate MATH fonts are available on WebKit bots...

Created attachment 226922 [details] Patch+130321+pixel tests

Comment on attachment 226922 [details] Patch+130321+pixel tests Attachment 226922 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/6019759220981760 New failing tests: mathml/opentype/large-operators-LatinModern.html mathml/opentype/vertical-STIX.html mathml/opentype/large-operators-STIX.html mathml/opentype/vertical-LatinModern.html

Created attachment 226926 [details] Archive of layout-test-results from webkit-ews-06 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.5

Comment on attachment 226922 [details] Patch+130321+pixel tests Attachment 226922 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/4753121825783808 New failing tests: mathml/opentype/large-operators-LatinModern.html mathml/opentype/vertical-STIX.html mathml/opentype/large-operators-STIX.html mathml/opentype/vertical-LatinModern.html

Created attachment 226930 [details] Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5

Created attachment 226931 [details] Patch+130321+pixel tests

Created attachment 226939 [details] Patch (applies after bug 130321) I only tested this on the GTK port. I'm not sure the WebKit bots really check the pixel tests on all platforms. It would be great if some people could manually test the patch. Here are more tests: http://localhost/ulule/mathml_torture_test/latinmodernmath.html http://localhost/ulule/mathml_torture_test/stixmath.html

Created attachment 226940 [details] Screenshot of http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/latinmodernmath.html

Created attachment 226941 [details] Screenshot of http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/stixmath.html

(In reply to comment #8) > Here are more tests: > http://localhost/ulule/mathml_torture_test/latinmodernmath.html > http://localhost/ulule/mathml_torture_test/stixmath.html Should be http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/latinmodernmath.html http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/stixmath.html sorry.

Let's read the MATH table first.

Created attachment 227419 [details] Patch This one now applies on top bug 130324. I'll udapte tests now that arbitrary MATH fonts are accepted. Test: http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/

Created attachment 227440 [details] Patch+130572+130324

Comment on attachment 227440 [details] Patch+130572+130324 Attachment 227440 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5936326528466944 New failing tests: mathml/presentation/mo-stretch.html media/W3C/audio/canPlayType/canPlayType_application_octet_stream.html mathml/opentype/opentype-stretchy.html mathml/opentype/vertical-LatinModern.html http/tests/media/track/track-webvtt-slow-loading.html mathml/opentype/large-operators-LatinModern.html

Created attachment 227453 [details] Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5

Comment on attachment 227440 [details] Patch+130572+130324 Attachment 227440 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/5343438237073408 New failing tests: mathml/opentype/large-operators-LatinModern.html mathml/opentype/vertical-LatinModern.html mathml/opentype/opentype-stretchy.html mathml/presentation/mo-stretch.html

Created attachment 227470 [details] Archive of layout-test-results from webkit-ews-06 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.5

Comment on attachment 227440 [details] Patch+130572+130324 Attachment 227440 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/5344894767857664 New failing tests: mathml/opentype/large-operators-LatinModern.html mathml/opentype/vertical-LatinModern.html mathml/opentype/opentype-stretchy.html mathml/presentation/mo-stretch.html

Created attachment 227484 [details] Archive of layout-test-results from webkit-ews-02 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-02 Port: mac-mountainlion Platform: Mac OS X 10.8.5

Comment on attachment 227440 [details] Patch+130572+130324 Attachment 227440 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/5442729291022336 New failing tests: mathml/opentype/large-operators-LatinModern.html mathml/opentype/vertical-LatinModern.html mathml/opentype/opentype-stretchy.html mathml/presentation/mo-stretch.html

Created attachment 227494 [details] Archive of layout-test-results from webkit-ews-01 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.5

Created attachment 227633 [details] Patch+130572+130324

Created attachment 228402 [details] Patch I'm asking review for this patch. However, I see at least three points to consider: 1) I've tested the operator stretching with the new fonts on the EFL and GTK ports. Ideally, I'd like someone to test the Windows/Mac ports before taking this patch: http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/. Also, that would be great to have the pixel references on all platforms. 2) At the moment, the patch does not change the default math fonts and still relies on the old fonts to do operator stretching with unicode constructions. I'd like to set MATH fonts as the default instead as they will be important for future work. However, I want to be sure that they are installed on Apple's operating systems. Who should I contact to do that? * As I understand the old STIXGeneral set (without MATH table) is installed by default on Mac, but I don't know if that's the case with the STIXWord set (with the MATH table). Event if that's the case, the official STIX Word has many bugs and it's not clear when they will be fixed so perhaps the fork https://github.com/khaledhosny/xits-math will be better if we want a STIX-like font. * The special case of iOS in mathml.css seems to say that it just has the Symbol font, which I don't think has a MATH table. Would it be possible to install a MATH font on iOS too (or add a table to the Symbol font)? Although I'm not a font designer, I can help to do that. * Many people are used to the TeX's default font (Computer Modern). So I think installing Latin Modern Math (http://www.gust.org.pl/projects/e-foundry/lm-math) on iOS/Mac and setting it as the default would be the best option. It is provided by default with most TeXLive distributions. 3) I added WOFF fonts in LayoutTests/ (Latin Modern Math and a custom font from a Mozilla test suite) to check the new MATH support. If we want Latin Modern Math to become the default later, would it be possible to install that font on the try bot machines, so that we don't need to provide it as a Web font?

Comment on attachment 228402 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=228402&action=review > Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp:1386 > +bool RenderMathMLOperator::getGlyphAssemblyFallFack(const GlyphData& baseGlyph, Vector<OpenTypeMathData::AssemblyPart> assemblyParts, StretchyData& stretchyData) Fallback not fallfack > Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp:1417 > + for (unsigned i = 0; i < assemblyParts.size(); i++) { put assemblyParts.size() in a variable so you don't call it each iteration of the loop > Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp:1489 > + if (primaryFontData && primaryFontData->mathData()) { looks like you can return early here > Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp:1499 > + for (unsigned i = 0; i < sizeVariants.size(); i++) { ditto about sizeVariants > Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp:1525 > + for (unsigned i = 0; i < sizeVariants.size(); i++) { ditto for sizeVariants > Source/WebCore/rendering/mathml/RenderMathMLOperator.h:96 > + bool shouldAllowStretching(); looks like it can be const > Source/WebCore/rendering/mathml/RenderMathMLOperator.h:154 > + StretchyData getDisplayStyleLargeOperator(const GlyphData& baseCharacter); both look like they can be const

Created attachment 228824 [details] Patch Fix Chris' comments. BTW, I wanted to use for (auto& ... for vectors, but it seems that the element are not listed in the right order.

@Chris: can you take a look again at the patch again? And do you have any remarks about comment 24?

(In reply to comment #27) > @Chris: can you take a look again at the patch again? And do you have any remarks about comment 24? Patch changes seem ok - I've started some enquiries regarding MATH font support on Mac/iOS

(In reply to comment #28) > (In reply to comment #27) > > @Chris: can you take a look again at the patch again? And do you have any remarks about comment 24? > > Patch changes seem ok - I've started some enquiries regarding MATH font support on Mac/iOS Thanks. Gurpreet Kaur said she will test the patch on Windows. I'm not sure I was really clear about the STIXGeneral / STIXWord. So if you go to http://sourceforge.net/projects/stixfonts/files/Current%20Release/ The STIXv1.1.0.zip archive from 2012-08-03 contains two subdirectories: - STIXGeneral, the old set which has many fonts. - STIXWord, the new set which has only 5 fonts: STIX-Bold / Italic / BoldItalic / Regular and STIXMath-Regular (which has the MATH table) Currently WebKit uses only Unicode-based construction so could use any of these sets. With this patch, it will require STIXMath-Regular to read the MATH table and to use more size variants and glyph assembly. The STIXv1.1.1-word.zip archive from 2013-06-21 contains only the STIXWord version (and probably has bug fixes). STIXv1.1.0-latex.zip (for LaTeX use) and STIXv1.1.1-webfonts.zip (WOFF STIX General) can be ignored for MathML purpose.

(In reply to comment #26) > BTW, I wanted to use for (auto& ... for vectors, but it seems that the element are not listed in the right order. Could you elaborate? What elements are not listed in the right order? A newfangled for loop on a vector will iterate in the same order that a ++i loop will.

Created attachment 228968 [details] Patch

(In reply to comment #30) > (In reply to comment #26) > > BTW, I wanted to use for (auto& ... for vectors, but it seems that the element are not listed in the right order. > > Could you elaborate? What elements are not listed in the right order? A newfangled for loop on a vector will iterate in the same order that a ++i loop will. Nevermind, I just tried again and that seems to work now.

Created attachment 229115 [details] Snapshots with Cambria and STIX Word in Windows

Created attachment 229116 [details] Snapshots with Cambria and STIX Word in Windows

Created attachment 229117 [details] Snapshots with Cambria and STIX Word in Windows

I have attached the snapshots for https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test using Cambria and STIX Word on Windows.

(In reply to comment #36) > I have attached the snapshots for https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test using Cambria and STIX Word on Windows. Thanks, the rendering of Cambria Math looks great, except for test 24 where the vertical bars are two short (I see it also on Linux). For STIX, the size variants are correctly taken but the spacing is completely wrong. I suspect this is an issue with how glyph metrics are handled on Windows. Mac/Win/Linux seems to have inconsistent behavior, see for example this Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=947650 I'd appreciate if someone could test the patch on Mac/iOS too, as they are the main targets for Apple products.

Created attachment 229120 [details] Patch This patch is essentially the same, except that I verify that the SimpleFontData obtained from the character via glyphDataForCharacter is really the PrimaryFontData of the MATH font, so that I can safely reuse it for other variants/pieces. @Gurpreet: you said that you got an ASSERT with the version of the page that has Web fonts. Does this patch help?

(In reply to comment #38) > @Gurpreet: you said that you got an ASSERT with the version of the page that has Web fonts. Does this patch help? > Hi Frederic, > Ya I am still facing the crash. > ASSERTION FAILED: m_purgePreventCount > ..\platform\graphics\FontCache.cpp(388) : WebCore::FontCache::getCachedFontData @Brent: Do you have an idea about why this assert could happen? And about the wrong font metrics?

Has anyone tried the patch on Mac? I wonder whether we will have the same ascent/descent problem as in Windows for some MATH fonts. However, I didn't have this problem with FreeType on WebKit while I have it on Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=947650), so perhaps WebKit Mac won't be affected by the bug. If at least as in Windows/Linux the MATH table can be read correctly (if the glyph metrics is incorrect), then we can probably resolve bug 130321 as WONTFIX.

(In reply to comment #40) > Has anyone tried the patch on Mac? > > I wonder whether we will have the same ascent/descent problem as in Windows for some MATH fonts. However, I didn't have this problem with FreeType on WebKit while I have it on Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=947650), so perhaps WebKit Mac won't be affected by the bug. > > If at least as in Windows/Linux the MATH table can be read correctly (if the glyph metrics is incorrect), then we can probably resolve bug 130321 as WONTFIX. Trying on Mac, and running the mathml tests. I hit this assert about 4 times during the test runs Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000000bbadbeef VM Regions Near 0xbbadbeef: --> __TEXT 0000000107c54000-0000000107ce9000 [ 596K] r-x/rwx SM=COW /data/* Application Specific Information: CRASHING TEST: mathml/opentype/opentype-stretchy.html Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.JavaScriptCore 0x00000001086d664a WTFCrash + 42 (Assertions.cpp:333) 1 com.apple.WebCore 0x000000010a61e1bf WebCore::FontCache::getCachedFontData(WebCore::FontPlatformData const*, WebCore::FontCache::ShouldRetain) + 159 (FontCache.cpp:390) 2 com.apple.WebCore 0x000000010a62d9a2 WebCore::FontCache::systemFallbackForCharacters(WebCore::FontDescription const&, WebCore::SimpleFontData const*, bool, unsigned short const*, int) + 1746 (FontCacheMac.mm:155) 3 com.apple.WebCore 0x000000010a637c82 WebCore::FontGlyphs::glyphDataAndPageForCharacter(WebCore::FontDescription const&, int, bool, WebCore::FontDataVariant) const + 3346 (FontGlyphs.cpp:384) 4 com.apple.WebCore 0x000000010a62fae2 WebCore::Font::glyphDataAndPageForCharacter(int, bool, WebCore::FontDataVariant) const + 98 (Font.h:175) 5 com.apple.WebCore 0x000000010a62f92c WebCore::Font::glyphDataForCharacter(int, bool, WebCore::FontDataVariant) const + 60 (Font.h:168) 6 com.apple.WebCore 0x000000010b723470 WebCore::RenderMathMLOperator::updateStyle() + 656 (RenderMathMLOperator.cpp:1611) 7 com.apple.WebCore 0x000000010b724d42 WebCore::RenderMathMLOperator::rebuildTokenContent(WTF::String const&) + 386 (RenderMathMLOperator.cpp:1352) 8 com.apple.WebCore 0x000000010b7222b9 WebCore::RenderMathMLOperator::updateTokenContent() + 121 (RenderMathMLOperator.cpp:1364) 9 com.apple.WebCore 0x000000010b722233 WebCore::RenderMathMLOperator::RenderMathMLOperator(WebCore::MathMLElement&, WTF::PassRef<WebCore::RenderStyle>) + 259 (RenderMathMLOperator.cpp:1137) 10 com.apple.WebCore 0x000000010b72211d WebCore::RenderMathMLOperator::RenderMathMLOperator(WebCore::MathMLElement&, WTF::PassRef<WebCore::RenderStyle>) + 29 (RenderMathMLOperator.cpp:1137) 11 com.apple.WebCore 0x000000010b30d537 WebCore::RenderPtr<WebCore::RenderMathMLOperator> WebCore::createRenderer<WebCore::RenderMathMLOperator, WebCore::MathMLTextElement&, WTF::PassRef<WebCore::RenderStyle> >(WebCore::MathMLTextElement&&&, WTF::PassRef<WebCore::RenderStyle>&&) + 103 (RenderPtr.h:158) 12 com.apple.WebCore 0x000000010b30d121 WebCore::MathMLTextElement::createElementRenderer(WTF::PassRef<WebCore::RenderStyle>) + 97 (MathMLTextElement.cpp:70) 13 com.apple.WebCore 0x000000010bb00077 WebCore::Style::createRendererIfNeeded(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WTF::PassRefPtr<WebCore::RenderStyle>) + 519 (StyleResolveTree.cpp:301) 14 com.apple.WebCore 0x000000010baffc88 WebCore::Style::attachRenderTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WTF::PassRefPtr<WebCore::RenderStyle>) + 168 (StyleResolveTree.cpp:585) 15 com.apple.WebCore 0x000000010bb0064f WebCore::Style::attachChildren(WebCore::ContainerNode&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&) + 351 (StyleResolveTree.cpp:486) 16 com.apple.WebCore 0x000000010baffdb8 WebCore::Style::attachRenderTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WTF::PassRefPtr<WebCore::RenderStyle>) + 472 (StyleResolveTree.cpp:606) 17 com.apple.WebCore 0x000000010bb0064f WebCore::Style::attachChildren(WebCore::ContainerNode&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&) + 351 (StyleResolveTree.cpp:486) 18 com.apple.WebCore 0x000000010baffdb8 WebCore::Style::attachRenderTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WTF::PassRefPtr<WebCore::RenderStyle>) + 472 (StyleResolveTree.cpp:606) 19 com.apple.WebCore 0x000000010bb0064f WebCore::Style::attachChildren(WebCore::ContainerNode&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&) + 351 (StyleResolveTree.cpp:486) 20 com.apple.WebCore 0x000000010baffdb8 WebCore::Style::attachRenderTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WTF::PassRefPtr<WebCore::RenderStyle>) + 472 (StyleResolveTree.cpp:606) 21 com.apple.WebCore 0x000000010bb0064f WebCore::Style::attachChildren(WebCore::ContainerNode&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&) + 351 (StyleResolveTree.cpp:486) 22 com.apple.WebCore 0x000000010baffdb8 WebCore::Style::attachRenderTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WTF::PassRefPtr<WebCore::RenderStyle>) + 472 (StyleResolveTree.cpp:606) 23 com.apple.WebCore 0x000000010bb0064f WebCore::Style::attachChildren(WebCore::ContainerNode&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&) + 351 (StyleResolveTree.cpp:486) 24 com.apple.WebCore 0x000000010baffdb8 WebCore::Style::attachRenderTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WTF::PassRefPtr<WebCore::RenderStyle>) + 472 (StyleResolveTree.cpp:606) 25 com.apple.WebCore 0x000000010baff2f2 WebCore::Style::resolveLocal(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 370 (StyleResolveTree.cpp:728) 26 com.apple.WebCore 0x000000010bafc01b WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 315 (StyleResolveTree.cpp:886) 27 com.apple.WebCore 0x000000010bafbec8 WebCore::Style::resolveTree(WebCore::Document&, WebCore::Style::Change) + 472 (StyleResolveTree.cpp:963) 28 com.apple.WebCore 0x000000010a3b7ac6 WebCore::Document::recalcStyle(WebCore::Style::Change) + 470 (Document.cpp:1771) 29 com.apple.WebCore 0x000000010a3b404f WebCore::Document::updateStyleIfNeeded() + 431 (Document.cpp:1817) 30 com.apple.WebCore 0x000000010a3c3c92 WebCore::Document::finishedParsing() + 354 (Document.cpp:4493) 31 com.apple.WebCore 0x000000010a825e18 WebCore::HTMLConstructionSite::finishedParsing() + 24 (HTMLConstructionSite.cpp:394) 32 com.apple.WebCore 0x000000010a93ef37 WebCore::HTMLTreeBuilder::finished() + 183 (HTMLTreeBuilder.cpp:2988) 33 com.apple.WebCore 0x000000010a83650e WebCore::HTMLDocumentParser::end() + 190 (HTMLDocumentParser.cpp:440) 34 com.apple.WebCore 0x000000010a834553 WebCore::HTMLDocumentParser::attemptToRunDeferredScriptsAndEnd() + 275 (HTMLDocumentParser.cpp:450) 35 com.apple.WebCore 0x000000010a834360 WebCore::HTMLDocumentParser::prepareToStopParsing() + 288 (HTMLDocumentParser.cpp:165) 36 com.apple.WebCore 0x000000010a836563 WebCore::HTMLDocumentParser::attemptToEnd() + 67 (HTMLDocumentParser.cpp:462) 37 com.apple.WebCore 0x000000010a8365b8 WebCore::HTMLDocumentParser::finish() + 72 (HTMLDocumentParser.cpp:491) 38 com.apple.WebCore 0x000000010a43f53a WebCore::DocumentWriter::end() + 346 (DocumentWriter.cpp:249) 39 com.apple.WebCore 0x000000010a406309 WebCore::DocumentLoader::finishedLoading(double) + 681 (DocumentLoader.cpp:441) 40 com.apple.WebCore 0x000000010a405fce WebCore::DocumentLoader::notifyFinished(WebCore::CachedResource*) + 270 (DocumentLoader.cpp:375) 41 com.apple.WebCore 0x000000010a04373d WebCore::CachedResource::checkNotify() + 109 (CachedResource.cpp:332) 42 com.apple.WebCore 0x000000010a043874 WebCore::CachedResource::finishLoading(WebCore::ResourceBuffer*) + 52 (CachedResource.cpp:349) 43 com.apple.WebCore 0x000000010a03dc78 WebCore::CachedRawResource::finishLoading(WebCore::ResourceBuffer*) + 200 (CachedRawResource.cpp:98) 44 com.apple.WebCore 0x000000010bb1afd3 WebCore::SubresourceLoader::didFinishLoading(double) + 467 (SubresourceLoader.cpp:312) 45 com.apple.WebCore 0x000000010b8aa675 WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*, double) + 53 (ResourceLoader.cpp:509) 46 com.apple.WebCore 0x000000010bd6cd9a -[WebCoreResourceHandleAsDelegate connectionDidFinishLoading:] + 186 (WebCoreResourceHandleAsDelegate.mm:253) 47 com.apple.Foundation 0x00007fff9022d7fd __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke + 48 48 com.apple.Foundation 0x00007fff9022d72d -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 244 49 com.apple.Foundation 0x00007fff9022d61c -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 69 50 com.apple.CFNetwork 0x00007fff8e5f2224 ___ZN27URLConnectionClient_Classic26_delegate_didFinishLoadingEU13block_pointerFvvE_block_invoke + 104 51 com.apple.CFNetwork 0x00007fff8e676d60 ___ZN27URLConnectionClient_Classic18_withDelegateAsyncEPKcU13block_pointerFvP16_CFURLConnectionPK33CFURLConnectionClientCurrent_VMaxE_block_invoke_2 + 84 52 com.apple.CFNetwork 0x00007fff8e5d528c ___ZNK17CoreSchedulingSet13_performAsyncEPKcU13block_pointerFvvE_block_invoke + 25 53 com.apple.CoreFoundation 0x00007fff970cdb44 CFArrayApplyFunction + 68 54 com.apple.CFNetwork 0x00007fff8e5d516b RunloopBlockContext::perform() + 115 55 com.apple.CFNetwork 0x00007fff8e5d5013 MultiplexerSource::perform() + 269 56 com.apple.CFNetwork 0x00007fff8e5d4e42 MultiplexerSource::_perform(void*) + 72 57 com.apple.CoreFoundation 0x00007fff97102661 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 58 com.apple.CoreFoundation 0x00007fff970f3d12 __CFRunLoopDoSources0 + 242 59 com.apple.CoreFoundation 0x00007fff970f349f __CFRunLoopRun + 831 60 com.apple.CoreFoundation 0x00007fff970f2f25 CFRunLoopRunSpecific + 309 61 DumpRenderTree 0x0000000107c71345 runTest(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 4853 (DumpRenderTree.mm:1822) 62 DumpRenderTree 0x0000000107c6ffda runTestingServerLoop() + 282 (DumpRenderTree.mm:1072) 63 DumpRenderTree 0x0000000107c6f835 dumpRenderTree(int, char const**) + 405 (DumpRenderTree.mm:1156) 64 DumpRenderTree 0x0000000107c71bd7 DumpRenderTreeMain(int, char const**) + 103 (DumpRenderTree.mm:1264) 65 DumpRenderTree 0x0000000107cc1492 main + 34 (DumpRenderTreeMain.mm:30) 66 libdyld.dylib 0x00007fff9279c5fd start + 1

(In reply to comment #41) > (In reply to comment #40) > > Has anyone tried the patch on Mac? > > > > I wonder whether we will have the same ascent/descent problem as in Windows for some MATH fonts. However, I didn't have this problem with FreeType on WebKit while I have it on Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=947650), so perhaps WebKit Mac won't be affected by the bug. > > > > If at least as in Windows/Linux the MATH table can be read correctly (if the glyph metrics is incorrect), then we can probably resolve bug 130321 as WONTFIX. > > Trying on Mac, and running the mathml tests. I hit this assert about 4 times during the test runs Thanks, I think it's the same assert as Gurpreet has on Windows (comment 39). That seems to be related to Web fonts and caching but I have not been able to reproduce it on Linux. Could you try with local fonts to see at least if the rendering is OK: https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test (select one of the "experimental" font installed on your computer) I'm assuming "STIX Word" is installed by default on Mac but otherwise see comment 29. Other links: http://www.gust.org.pl/projects/e-foundry/lm-math/download/index_html https://github.com/khaledhosny/xits-math https://github.com/khaledhosny/euler-otf

Created attachment 229433 [details] Patch to prevent access to MATH data while custom fonts are loading @Chris and @Gurpreet: does this additional simple patch prevent the ASSERT to happen?

(In reply to comment #43) > Created an attachment (id=229433) [details] > Patch to prevent access to MATH data while custom fonts are loading > > @Chris and @Gurpreet: does this additional simple patch prevent the ASSERT to happen? Still hit the assert Application Specific Information: CRASHING TEST: mathml/opentype/opentype-stretchy.html Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.JavaScriptCore 0x000000011039844a WTFCrash + 42 (Assertions.cpp:333) 1 com.apple.WebCore 0x00000001122e760f WebCore::FontCache::getCachedFontData(WebCore::FontPlatformData const*, WebCore::FontCache::ShouldRetain) + 159 (FontCache.cpp:390) 2 com.apple.WebCore 0x00000001122f6df2 WebCore::FontCache::systemFallbackForCharacters(WebCore::FontDescription const&, WebCore::SimpleFontData const*, bool, unsigned short const*, int) + 1746 -------- #if !ASSERT_DISABLED if (shouldRetain == DoNotRetain) ASSERT(m_purgePreventCount); #endif

(In reply to comment #44) > (In reply to comment #43) > > Created an attachment (id=229433) [details] [details] > > Patch to prevent access to MATH data while custom fonts are loading > > > > @Chris and @Gurpreet: does this additional simple patch prevent the ASSERT to happen? > Thanks, Gurpreet said that additionally doing shouldAllowStretching() { const auto& primaryFontData = style().font().primaryFont(); return primaryFontData && primaryFontData->mathData() && m_operator && (hasOperatorFlag(MathMLOperatorDictionary::Stretchy) || isLargeOperatorInDisplayStyle()); } prevents the crash, which would suggest that indeed the problem is the reflow due to the Web fonts. have you tried local fonts (comment 42)?

Created attachment 229656 [details] Patch

Created attachment 229657 [details] Patch

Here are tests where I've modified the hhea ascent/descent of the fonts to workaround bug 131839: http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/latinmodern2math.html http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/stix2math.html

Comment on attachment 229657 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=229657&action=review > Source/WebCore/css/mathml.css:18 > + font-family: MathJax_Main, STIXGeneral, STIXSizeOneSym, "DejaVu Serif", Cambria, "Cambria Math", Times, serif; It looks like this is differing from Mozilla's math.css file font-family: MathJax_Main, STIXGeneral, DejaVu Serif, DejaVu Sans, Cambria, Cambria Math, Times, Lucida Sans Unicode, OpenSymbol, Standard Symbols L, serif; What's the implication of removing DejaVu Sans, for instance > Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp:1544 > + const StretchyCharacter* stretchyCharacter = 0; = nullptr; > Source/WebCore/rendering/mathml/RenderMathMLOperator.cpp:1545 > + const int maxIndex = WTF_ARRAY_LENGTH(stretchyCharacters); i think maxIndex is probably a size_t or an unsigned

(In reply to comment #49) > > Source/WebCore/css/mathml.css:18 > > + font-family: MathJax_Main, STIXGeneral, STIXSizeOneSym, "DejaVu Serif", Cambria, "Cambria Math", Times, serif; > > It looks like this is differing from Mozilla's math.css file > > font-family: MathJax_Main, STIXGeneral, DejaVu Serif, DejaVu Sans, Cambria, Cambria Math, Times, Lucida Sans Unicode, OpenSymbol, Standard Symbols L, serif; The idea will be to move to fonts with an Open Type MATH table and keep some old fonts for unicode-only constructions (i.e. those in stretchyCharacters). The same is currently done for Gecko (and actually the plan is to make the default font-family a preference option) where I'm first trying to ensure that MATH fonts are available on Desktop/mobile platforms. The situation is the same in WebKit: we will need to know exactly if the patch works correctly on all platforms and ensure that Open Type MATH fonts are available before deciding the font-family... At the moment, I can only test the patch on Linux.

Created attachment 230897 [details] Patch > Source/WebCore/css/mathml.css I've kept the list of fonts for now, although this will eventually change later. > = nullptr; done > i think maxIndex is probably a size_t or an unsigned done > Still hit the assert Gurpreet tried again yesterday with the latest version and she confirmed that the changes to shouldAllowStretching prevents the assert with the Web fonts. There is certainly something that we don't understand but I can't debug this on Linux as this seems specific to Windows/Mac. So I think we can take the patch, even if it won't improve the rendering with the default fonts for now. The two remaining issues before being able to switch to OpenType fonts with a MATH table for the default font-family is: 1) Ensuring that the fonts are available on test bots & at least Mac/iOS (Windows has Cambria Math and Linux distributions have packages available) 2) Fixing bug 131839 for STIX Word and fonts of the GUST e-foundry group (bug 131839 comment 1). It will probably be best to let the font designers fix that bug rather than adding some special code to handle that in WebKit.

Hi Frederic and Chris. Yes I yesterday tested http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/ and and switching between fonts and no crash was observed. Will upload the snapshots soon for http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/latinmodern2math.html and http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/stix2math.html.

(In reply to comment #52) > Hi Frederic and Chris. Yes I yesterday tested http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/ and and switching between fonts and no crash was observed. Will upload the snapshots soon for http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/latinmodern2math.html and > http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/stix2math.html. It looks like I'm getting this assert when running the tests (and trying to use STIX font) on the torture test Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.JavaScriptCore 0x0000000115aedcba WTFCrash + 42 (Assertions.cpp:333) 1 com.apple.WebCore 0x00000001174cb0cf WebCore::FontCache::getCachedFontData(WebCore::FontPlatformData const*, WebCore::FontCache::ShouldRetain) + 159 (FontCache.cpp:389) 2 com.apple.WebCore 0x00000001174da982 WebCore::FontCache::systemFallbackForCharacters(WebCore::FontDescription const&, WebCore::SimpleFontData const*, bool, unsigned short const*, int) + 1746 (FontCacheMac.mm:155) 3 com.apple.WebCore 0x00000001174e4c62 WebCore::FontGlyphs::glyphDataAndPageForCharacter(WebCore::FontDescription const&, int, bool, WebCore::FontDataVariant) const + 3346 (FontGlyphs.cpp:384) 4 com.apple.WebCore 0x00000001174dcac2 WebCore::Font::glyphDataAndPageForCharacter(int, bool, WebCore::FontDataVariant) const + 98 (Font.h:174) 5 com.apple.WebCore 0x00000001174dc90c WebCore::Font::glyphDataForCharacter(int, bool, WebCore::FontDataVariant) const + 60 (Font.h:167) 6 com.apple.WebCore 0x00000001185eb2cb WebCore::RenderMathMLOperator::findStretchyData(unsigned short, float*) + 1403 (RenderMathMLOperator.cpp:1558) 7 com.apple.WebCore 0x00000001185ea2e7 WebCore::RenderMathMLOperator::updateStyle() + 823 (RenderMathMLOperator.cpp:1617) 8 com.apple.WebCore 0x00000001185f4cce WebCore::RenderMathMLToken::styleDidChange(WebCore::StyleDifference, WebCore::RenderStyle const*) + 94 (RenderMathMLToken.cpp:107) 9 com.apple.WebCore 0x00000001184ec5be WebCore::RenderElement::setStyle(WTF::PassRef<WebCore::RenderStyle>) + 1422 (RenderElement.cpp:432) 10 com.apple.WebCore 0x00000001184eca3e WebCore::RenderElement::setAnimatableStyle(WTF::PassRef<WebCore::RenderStyle>) + 94 (RenderElement.cpp:467) 11 com.apple.WebCore 0x00000001189de80f WebCore::Style::resolveLocal(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 607 (StyleResolveTree.cpp:736) 12 com.apple.WebCore 0x00000001189db44b WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 315 (StyleResolveTree.cpp:886) 13 com.apple.WebCore 0x00000001189db689 WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 889 (StyleResolveTree.cpp:921) 14 com.apple.WebCore 0x00000001189db689 WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 889 (StyleResolveTree.cpp:921) 15 com.apple.WebCore 0x00000001189db689 WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 889 (StyleResolveTree.cpp:921) 16 com.apple.WebCore 0x00000001189db689 WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 889 (StyleResolveTree.cpp:921) 17 com.apple.WebCore 0x00000001189db689 WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 889 (StyleResolveTree.cpp:921) 18 com.apple.WebCore 0x00000001189db689 WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 889 (StyleResolveTree.cpp:921) 19 com.apple.WebCore 0x00000001189db689 WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 889 (StyleResolveTree.cpp:921) 20 com.apple.WebCore 0x00000001189db689 WebCore::Style::resolveTree(WebCore::Element&, WebCore::ContainerNode&, WebCore::Style::RenderTreePosition&, WebCore::Style::Change) + 889 (StyleResolveTree.cpp:921) 21 com.apple.WebCore 0x00000001189db2f8 WebCore::Style::resolveTree(WebCore::Document&, WebCore::Style::Change) + 472 (StyleResolveTree.cpp:963) 22 com.apple.WebCore 0x000000011725c2a6 WebCore::Document::recalcStyle(WebCore::Style::Change) + 470 (Document.cpp:1763) 23 com.apple.WebCore 0x000000011725888f WebCore::Document::updateStyleIfNeeded() + 431 (Document.cpp:1809) 24 com.apple.WebCore 0x0000000117252a79 WebCore::Document::styleRecalcTimerFired(WebCore::Timer<WebCore::Document>&) + 25 (Document.cpp:1715) 25 com.apple.WebCore 0x000000011729e8be std::__1::__function::__func<std::__1::__bind<void (WebCore::Document::*&)(WebCore::Timer<WebCore::Document>&), WebCore::Document*&, std::__1::reference_wrapper<WebCore::Timer<WebCore::Document> > >, std::__1::allocator<std::__1::__bind<void (WebCore::Document::*&)(WebCore::Timer<WebCore::Document>&), WebCore::Document*&, std::__1::reference_wrapper<WebCore::Timer<WebCore::Document> > > >, void ()>::operator()() + 350 (functional:1059) 26 com.apple.WebCore 0x0000000116d7031a std::__1::function<void ()>::operator()() const + 26 (functional:1435) 27 com.apple.WebCore 0x000000011729c3bc WebCore::Timer<WebCore::Document>::fired() + 28 (Timer.h:134) 28 com.apple.WebCore 0x0000000118bbd5bc WebCore::ThreadTimers::sharedTimerFiredInternal() + 396 (ThreadTimers.cpp:135) 29 com.apple.WebCore 0x0000000118bbd279 WebCore::ThreadTimers::sharedTimerFired() + 25 (ThreadTimers.cpp:108) 30 com.apple.WebCore 0x00000001188cbb03 WebCore::timerFired(__CFRunLoopTimer*, void*) + 67 (SharedTimerMac.mm:134) 31 com.apple.CoreFoundation 0x00007fff8cf36494 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 32 com.apple.CoreFoundation 0x00007fff8cf35fcf __CFRunLoopDoTimer + 1151 33 com.apple.CoreFoundation 0x00007fff8cfa75aa __CFRunLoopDoTimers + 298

(In reply to comment #53) > It looks like I'm getting this assert when running the tests (and trying to use STIX font) on the torture test mmmh, that's weird it still happens on Mac. What if you replace "isLoading" with "isCustomFont" in RenderMathMLOperator::shouldAllowStretching()? It's also possible that I need to check whether all the fontdata are custom fonts, not just the primaryfontdata... Another possibility is that storing GlyphData objects on the RenderMathMLOperator is bad (there was a crash in the past when they were not cleaned up correctly). Probably someone who knows more about font cache and stuff could help here...

(In reply to comment #54) > (In reply to comment #53) > > It looks like I'm getting this assert when running the tests (and trying to use STIX font) on the torture test > > mmmh, that's weird it still happens on Mac. What if you replace "isLoading" with "isCustomFont" in RenderMathMLOperator::shouldAllowStretching()? > > It's also possible that I need to check whether all the fontdata are custom fonts, not just the primaryfontdata... > > Another possibility is that storing GlyphData objects on the RenderMathMLOperator is bad (there was a crash in the past when they were not cleaned up correctly). > > Probably someone who knows more about font cache and stuff could help here... Replaced isLoading with isCustomFont and still got this ----------- Application Specific Information: CRASHING TEST: mathml/presentation/style-changed.html Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.JavaScriptCore 0x000000010df69cba WTFCrash + 42 (Assertions.cpp:333) 1 com.apple.WebCore 0x000000010f9510cf WebCore::FontCache::getCachedFontData(WebCore::FontPlatformData const*, WebCore::FontCache::ShouldRetain) + 159 (FontCache.cpp:389) 2 com.apple.WebCore 0x000000010f960982 WebCore::FontCache::systemFallbackForCharacters(WebCore::FontDescription const&, WebCore::SimpleFontData const*, bool, unsigned short const*, int) + 1746 (FontCacheMac.mm:155) 3 com.apple.WebCore 0x000000010f96ac62 WebCore::FontGlyphs::glyphDataAndPageForCharacter(WebCore::FontDescription const&, int, bool, WebCore::FontDataVariant) const + 3346 (FontGlyphs.cpp:384) 4 com.apple.WebCore 0x000000010f962ac2 WebCore::Font::glyphDataAndPageForCharacter(int, bool, WebCore::FontDataVariant) const + 98 (Font.h:174) 5 com.apple.WebCore 0x000000010f96290c WebCore::Font::glyphDataForCharacter(int, bool, WebCore::FontDataVariant) const + 60 (Font.h:167) 6 com.apple.WebCore 0x0000000110a712cb WebCore::RenderMathMLOperator::findStretchyData(unsigned short, float*) + 1403 (RenderMathMLOperator.cpp:1558) 7 com.apple.WebCore 0x0000000110a702e7 WebCore::RenderMathMLOperator::updateStyle() + 823 (RenderMathMLOperator.cpp:1617) 8 com.apple.WebCore 0x0000000110a7acce WebCore::RenderMathMLToken::styleDidChange(WebCore::StyleDifference, WebCore::RenderStyle const*) + 94 (RenderMathMLToken.cpp:107) 9 com.apple.WebCore 0x00000001109725be WebCore::RenderElement::setStyle(WTF::PassRef<WebCore::RenderStyle>) + 1422 (RenderElement.cpp:432) 10 com.apple.WebCore 0x0000000110973f7c WebCore::RenderElement::propagateStyleToAnonymousChildren(WebCore::RenderElement::StylePropagationType) + 668 (RenderElement.cpp:790)

I had taken your latest patch, but it looks like that didn't have the change from comment 45: https://bugs.webkit.org/show_bug.cgi?id=130322#c45 I applied just that change and did not hit the crash. I visited the torture test website and changed to STIX experimental and it seemed to render ok

Created attachment 231000 [details] screen shot on Mac with STIX word experimental

(In reply to comment #56) > I had taken your latest patch, but it looks like that didn't have the change from > comment 45: https://bugs.webkit.org/show_bug.cgi?id=130322#c45 > > I applied just that change and did not hit the crash. > > I visited the torture test website and changed to STIX experimental and it seemed to render ok OK, sounds better. Could you please test STIX Word on both https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test (with your local fonts) and http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/ (with Web fonts) to be sure? (Gurpreet only hit the assert with the latter) Also, could you attach screenshots of the "interesting" part (for example tests 16-21). If the integrals/sums render the same in both cases, then STIX Word is installed by default on Mac.

Created attachment 231001 [details] stix word screenshot 1 (mac)

Created attachment 231002 [details] stix word sceenshot 2(mac)

Created attachment 231003 [details] STIX-Word WebKitGTK+ The integrals/sums should be larger as in this screenshot... :-( I think the condition in comment 45 is too strong (it only allows stretching when we have a MATH font while we might want to use our fallback for old fonts). So actually the assert problem is not solved...

I tested both https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test and http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/ with STIX Word and its not crashing and the integrals are large and same for both the sites.

Created attachment 231525 [details] Patch to remove SimpleFontData members from the RenderMathMLOperator class This patch removes the SimpleFontData pointers stored on the RenderMathMLOperator class, which I suspect is causing memory management problems. @Chris: What do you get if you apply it on top of attachment 230897 [details]?

Created attachment 231693 [details] Patch, part 1 + 2

Created attachment 231780 [details] Patch

Created attachment 231789 [details] Patch

Created attachment 231815 [details] Patch (ENABLE_OPENTYPE_MATH disabled on Mac/Win)

Created attachment 231818 [details] Patch (add FontCachePurgePreventer on updateStyle)

Created attachment 231859 [details] Patch

Comment on attachment 231859 [details] Patch Attachment 231859 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/6399625774759936 New failing tests: mathml/opentype/large-operators-LatinModern.html mathml/opentype/opentype-stretchy.html mathml/opentype/vertical-LatinModern.html

Created attachment 231884 [details] Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-14 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5

Created attachment 231889 [details] Patch

Comment on attachment 231889 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=231889&action=review > Source/WebCore/ChangeLog:6 > + Reviewed by NOBODY (OOPS!). Add a more fuller description of what and why these changes are for

Committed r169305: <http://trac.webkit.org/changeset/169305>

There are several tests failing after this change: mathml/opentype/large-operators-LatinModern.html mathml/opentype/opentype-stretchy.html mathml/opentype/vertical-LatinModern.html Diffs here: http://build.webkit.org/results/Apple%20Mavericks%20Release%20WK1%20(Tests)/r169305%20(6250)/results.html Frédéric, are you available to take a look into this now?

(In reply to comment #75) > There are several tests failing after this change: > > mathml/opentype/large-operators-LatinModern.html > mathml/opentype/opentype-stretchy.html > mathml/opentype/vertical-LatinModern.html > > Diffs here: http://build.webkit.org/results/Apple%20Mavericks%20Release%20WK1%20(Tests)/r169305%20(6250)/results.html > > Frédéric, are you available to take a look into this now? I think it is safe to mark these new tests as failing and/or to regenerated the text/png references.

Committed r169307: <http://trac.webkit.org/changeset/169307>

Committed r169308: <http://trac.webkit.org/changeset/169308>

Its strange to have a difference between WebKit1 and WebKit2 (looks like the Mac failures were WebKit1 only).

Removing Mavericks-specific lines from platform/mac/TestExpecations due to no longer supporting Mavericks.

Committed r193663: <http://trac.webkit.org/changeset/193663>