Bug 88188 - Accept HTML and MathML namespaces as valid requiredExtensions
Summary: Accept HTML and MathML namespaces as valid requiredExtensions
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Frédéric Wang (:fredw)
URL: http://www.w3.org/TR/SVGTiny12/extend...
Keywords:
Depends on: 126762
Blocks: 74749 mathjax
  Show dependency treegraph
 
Reported: 2012-06-03 06:37 PDT by Frédéric Wang (:fredw)
Modified: 2014-01-15 10:57 PST (History)
16 users (show)

See Also:


Attachments
testcase (14.03 KB, image/svg+xml)
2013-09-13 21:54 PDT, Frédéric Wang (:fredw)
no flags Details
Patch V1 (11.41 KB, patch)
2014-01-06 08:44 PST, Frédéric Wang (:fredw)
no flags Details | Formatted Diff | Diff
Patch V2 (11.97 KB, patch)
2014-01-06 09:41 PST, Frédéric Wang (:fredw)
krit: review-
Details | Formatted Diff | Diff
Patch V3 (14.43 KB, patch)
2014-01-09 05:35 PST, Frédéric Wang (:fredw)
krit: review-
krit: commit-queue-
Details | Formatted Diff | Diff
Patch (Final Version) (15.05 KB, patch)
2014-01-10 03:23 PST, Frédéric Wang (:fredw)
no flags Details | Formatted Diff | Diff
Patch with reftests (14.02 KB, patch)
2014-01-11 06:05 PST, Frédéric Wang (:fredw)
buildbot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2 (462.54 KB, application/zip)
2014-01-11 06:51 PST, Build Bot
no flags Details
Patch with reftests (13.80 KB, patch)
2014-01-11 06:58 PST, Frédéric Wang (:fredw)
darin: review+
darin: commit-queue-
Details | Formatted Diff | Diff
Patch (14.51 KB, patch)
2014-01-12 06:18 PST, Frédéric Wang (:fredw)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Wang (:fredw) 2012-06-03 06:37:22 PDT
The SVGTiny12 spec suggests support for HTML and MathML languages in <foreignObject>. It also shows the use of "http://www.w3.org/1999/xhtml" and "http://www.w3.org/1998/Math/MathML" as requiredExtensions strings:

http://www.w3.org/TR/SVGTiny12/extend.html#ForeignObjectExamples

Firefox has supported these languages in SVG and recognized these requiredExtensions values since at least 2008/2009:

https://bugzilla.mozilla.org/show_bug.cgi?id=449746

The inclusion of foreign object is useful to mix diagrams and formulas and has been discussed e.g. in MathJax mailing lists.

Here are reftests from the MathJax test suite which are currently failing in Chrome/Safari:

http://devel.mathjax.org/testing/testsuite/Configuration/Contexts/svg-1a.html
http://devel.mathjax.org/testing/testsuite/Configuration/Contexts/svg-1-ref.html

http://devel.mathjax.org/testing/testsuite/Configuration/Contexts/svg-1b.html
http://devel.mathjax.org/testing/testsuite/Configuration/Contexts/svg-1-ref.html

See also
http://www.w3.org/Math/Documents/Notes/graphics.xml#mathml-in-svg-guidelines
Comment 1 Frédéric Wang (:fredw) 2013-09-13 21:51:36 PDT
I might try to work on this, since that's similar to my work for bug 120058.

SVGSwitchElement::childShouldCreateRenderer contains a comment

// FIXME: This function does not do what the comment below implies it does.
// It will create a renderer for any valid SVG element children, not just the first one.

But it seems to me that what the code does is correct.
Comment 2 Frédéric Wang (:fredw) 2013-09-13 21:54:04 PDT
Created attachment 211617 [details]
testcase

WebKit should render the square root of n using MathML, but it renders the <text> fallback instead.
Comment 3 Philip Rogers 2013-09-23 13:53:22 PDT
The current MathML implementation has inherent security flaws that will likely prevent it from being shipped in a major browser (see https://code.google.com/p/chromium/issues/detail?id=152430#c40). Are any browsers currently shipping with WebKit's MathML enabled?
Comment 4 Philip Rogers 2013-09-23 14:01:29 PDT
(In reply to comment #3)
> The current MathML implementation has inherent security flaws that will likely prevent it from being shipped in a major browser (see https://code.google.com/p/chromium/issues/detail?id=152430#c40). Are any browsers currently shipping with WebKit's MathML enabled?

I was mistaken--Safari ships the WebKit MathML implementation. Please ignore my noise :)
Comment 5 Frédéric Wang (:fredw) 2013-09-24 02:12:22 PDT
I don't think "inherent security flaws" is quite correct. To my knowledge, it's mainly a design issue with the MathML implementation violating some assumptions from other parts of the code. At least nobody (even Google engineers) has been able to provide a test case demonstrating security problem and the only thing I found was a performance issue that could make the browser hangs a few seconds ; something which I think is categorized as the lowest security level by Google.

Anyway the solution for this bug is obvious: just uses the #ifdef preprocessing rules to add/remove the MathML namespace from authorized requiredExtensions values. If the patch is imported to Chromium, the #ifdef code can just be dropped.
Comment 6 Frédéric Wang (:fredw) 2014-01-06 08:44:05 PST
Created attachment 220437 [details]
Patch V1
Comment 7 chris fleizach 2014-01-06 08:57:51 PST
Comment on attachment 220437 [details]
Patch V1

View in context: https://bugs.webkit.org/attachment.cgi?id=220437&action=review

> Source/WebCore/svg/SVGTests.cpp:128
> +    unsigned extensionsSize = m_requiredExtensions.value.size();

size() returns a size_t

> Source/WebCore/svg/SVGTests.cpp:131
> +        if (value.isEmpty() || !hasExtension(value))

I don't think you need to check if the value is empty, since hasExtension will return false for an empty string
Comment 8 Frédéric Wang (:fredw) 2014-01-06 09:02:28 PST
(In reply to comment #7)
> > Source/WebCore/svg/SVGTests.cpp:128
> > +    unsigned extensionsSize = m_requiredExtensions.value.size();
> 
> size() returns a size_t
> 
> > Source/WebCore/svg/SVGTests.cpp:131
> > +        if (value.isEmpty() || !hasExtension(value))
> 
> I don't think you need to check if the value is empty, since hasExtension will return false for an empty string

Thanks for the feedback. I think you are right for the isEmpty. Note that I copied the existing code in SVGTests::isValid() for features and systemLanguage. Should I apply the same changes to these other attributes?
Comment 9 chris fleizach 2014-01-06 09:05:42 PST
(In reply to comment #8)
> (In reply to comment #7)
> > > Source/WebCore/svg/SVGTests.cpp:128
> > > +    unsigned extensionsSize = m_requiredExtensions.value.size();
> > 
> > size() returns a size_t
> > 
> > > Source/WebCore/svg/SVGTests.cpp:131
> > > +        if (value.isEmpty() || !hasExtension(value))
> > 
> > I don't think you need to check if the value is empty, since hasExtension will return false for an empty string
> 
> Thanks for the feedback. I think you are right for the isEmpty. Note that I copied the existing code in SVGTests::isValid() for features and systemLanguage. Should I apply the same changes to these other attributes?

Sure
Comment 10 Frédéric Wang (:fredw) 2014-01-06 09:41:29 PST
Created attachment 220438 [details]
Patch V2

So as I read it, the isEmpty is still necessary for the features attribute.
Comment 11 Dirk Schulze 2014-01-09 00:59:10 PST
Comment on attachment 220438 [details]
Patch V2

View in context: https://bugs.webkit.org/attachment.cgi?id=220438&action=review

Patch looks good in general. r- because of a missing test for SVGDOM.

> Source/WebCore/svg/SVGSwitchElement.cpp:55
> +    // We create a renderer for the first valid SVG element child.
> +    // FIXME: The renderer must be updated after dynamic change of the requiredFeatures, requiredExtensions and systemLanguage attributes (http://wkbug/122297).

Yes, it looks like this is correct. The link is not valid. Even if it would, it references something different (MathML related). Please open a bug with a test case (if you haven't done so yet) and use the link to this bug instead.

> Source/WebCore/svg/SVGTests.cpp:102
> +bool SVGTests::hasExtension(const String& extension) const

This is used by SVGDOM as well. However, you do not have one JS test to check the correct behavior. Could you add those?

> Source/WebCore/svg/SVGTests.cpp:104
> +    // We recognize XHTML and MathML, as implemented in Gecko and suggested in the SVG Tiny recommendation (http://www.w3.org/TR/SVGTiny12/struct.html#RequiredExtensionsAttribute).

We do not implement SVG 1.2 Tiny. But the normative text between SVG 1.1 and SVG 1.2 Tiny is basically the same. Just use http://www.w3.org/TR/SVG11/struct.html#RequiredExtensionsAttribute

> Source/WebCore/svg/SVGTests.cpp:109
> +#if ENABLE(MATHML)
> +    return extension == HTMLNames::xhtmlNamespaceURI || extension == MathMLNames::mathmlNamespaceURI;
> +#else
> +    return extension == HTMLNames::xhtmlNamespaceURI;
> +#endif

I wonder, even though if it would be foolish of an author to do that, if we shouldn't check for the SVG namespace as well.

> Source/WebCore/svg/SVGTests.cpp:117
>          if (value.isEmpty() || !DOMImplementation::hasFeature(value, String()))

To answer your question: value can be empty. However, it is not necessary to have the check though. It could be an optimization on the other hand. Just keep it.

> Source/WebCore/svg/SVGTests.cpp:129
> +    for (unsigned i = 0; i < extensionsSize; ++i) {

Well, this is inconsistent. If you change the other to size_t, this should be size_t as well. (Ditto on the other for-loops.) However, I am not sure if I agree with Chris. We always used to use unsigned.
Comment 12 Frédéric Wang (:fredw) 2014-01-09 01:54:16 PST
(In reply to comment #11)
> > Source/WebCore/svg/SVGTests.cpp:104
> We do not implement SVG 1.2 Tiny. But the normative text between SVG 1.1 and SVG 1.2 Tiny is basically the same. Just use http://www.w3.org/TR/SVG11/struct.html#RequiredExtensionsAttribute

The SVG11 version does not mention the XHTML/MathML examples, so it would not really relevant to point to that page...

> I wonder, even though if it would be foolish of an author to do that, if we shouldn't check for the SVG namespace as well.

I just checked the HTML5 validator schema and the allowed direct children are html, body, math and other HTML5 "inner flow" elements:

https://bitbucket.org/validator/validator/src/5ee4172d2929787d5b78519c2035e62b503eee6c/schema/xhtml5-svg-mathml.rnc?at=default#cl-17

SVG could still be inserted indirectly e.g. by using an intermediate HTML element... but it would be stupid for the author to ask the renderer if it supports SVG (otherwise why would it even be trying to understand the <switch>/<foreignObject> features or rendering the SVG document).

Well, I guess it is easy to add but I'm not really sure it is important... Gecko does not AFAIK.
Comment 13 Frédéric Wang (:fredw) 2014-01-09 02:38:08 PST
(In reply to comment #11)
> > Source/WebCore/svg/SVGTests.cpp:102
> > +bool SVGTests::hasExtension(const String& extension) const
> 
> This is used by SVGDOM as well. However, you do not have one JS test to check the correct behavior. Could you add those?
> 

I'm not sure I understand this. SVG DOM has

http://www.w3.org/TR/SVG/svgdom.html#FeatureStrings

for hasFeature but I don't see hasExtension. Perhaps you mean testing a private method but calling document.implementation.hasExtension returns undefined for me.
Comment 14 Dirk Schulze 2014-01-09 03:52:55 PST
(In reply to comment #12)
> (In reply to comment #11)
> > > Source/WebCore/svg/SVGTests.cpp:104
> > We do not implement SVG 1.2 Tiny. But the normative text between SVG 1.1 and SVG 1.2 Tiny is basically the same. Just use http://www.w3.org/TR/SVG11/struct.html#RequiredExtensionsAttribute
> 
> The SVG11 version does not mention the XHTML/MathML examples, so it would not really relevant to point to that page...

True, but it also doesn't matter since these are examples for URIs. In general, if there is a SVG1.1 version, we use the 1.1 version so that people don't get confused.

> 
> > I wonder, even though if it would be foolish of an author to do that, if we shouldn't check for the SVG namespace as well.
> 
> I just checked the HTML5 validator schema and the allowed direct children are html, body, math and other HTML5 "inner flow" elements:
> 
> https://bitbucket.org/validator/validator/src/5ee4172d2929787d5b78519c2035e62b503eee6c/schema/xhtml5-svg-mathml.rnc?at=default#cl-17
> 
> SVG could still be inserted indirectly e.g. by using an intermediate HTML element... but it would be stupid for the author to ask the renderer if it supports SVG (otherwise why would it even be trying to understand the <switch>/<foreignObject> features or rendering the SVG document).
> 
> Well, I guess it is easy to add but I'm not really sure it is important... Gecko does not AFAIK.

I assume the text could be interpreted as extension to SVG, in which case the SVG URI would not be part of it. Keep it as it is then.
Comment 15 Dirk Schulze 2014-01-09 03:54:54 PST
(In reply to comment #13)
> (In reply to comment #11)
> > > Source/WebCore/svg/SVGTests.cpp:102
> > > +bool SVGTests::hasExtension(const String& extension) const
> > 
> > This is used by SVGDOM as well. However, you do not have one JS test to check the correct behavior. Could you add those?
> > 
> 
> I'm not sure I understand this. SVG DOM has
> 
> http://www.w3.org/TR/SVG/svgdom.html#FeatureStrings
> 
> for hasFeature but I don't see hasExtension. Perhaps you mean testing a private method but calling document.implementation.hasExtension returns undefined for me.

Look at "Basic Data Types" and the interface for SVGTests: http://www.w3.org/TR/SVG11/types.html#InterfaceSVGTests

This has
   boolean hasExtension(in DOMString extension);
Comment 16 Frédéric Wang (:fredw) 2014-01-09 05:35:03 PST
Created attachment 220717 [details]
Patch V3
Comment 17 Dirk Schulze 2014-01-10 03:00:49 PST
Comment on attachment 220717 [details]
Patch V3

View in context: https://bugs.webkit.org/attachment.cgi?id=220717&action=review

Patch looks great, just tiny change requests and the patch is good to go.

> LayoutTests/ChangeLog:5
> +

Please add a detailed description for Changelogs

> Source/WebCore/ChangeLog:12
> +        When HTML and MathML are used as foreign objects of an SVG image, it is important for Web authors to be able to specify a fallback content for SVG-only readers or browsers without MathML support. We rely on the requiredExtensions for that purpose and we use the XHTML/MathML namespaces as suggested in SVG Tiny 1.2 and implemented in Gecko.

The description comes right after "Reviewed by..." Please use line breaks.

> Source/WebCore/svg/SVGSwitchElement.cpp:55
> +    // FIXME: The renderer must be updated after dynamic change of the requiredFeatures, requiredExtensions and systemLanguage attributes (http://wkbug/74749).

Please change that to http://wkb.ug/74749
Comment 18 Frédéric Wang (:fredw) 2014-01-10 03:23:07 PST
Created attachment 220828 [details]
Patch (Final Version)
Comment 19 Dirk Schulze 2014-01-10 03:24:29 PST
Comment on attachment 220828 [details]
Patch (Final Version)

r=me
Comment 20 WebKit Commit Bot 2014-01-10 03:59:09 PST
Comment on attachment 220828 [details]
Patch (Final Version)

Clearing flags on attachment: 220828

Committed r161629: <http://trac.webkit.org/changeset/161629>
Comment 21 WebKit Commit Bot 2014-01-10 03:59:14 PST
All reviewed patches have been landed.  Closing bug.
Comment 22 Alexey Proskuryakov 2014-01-10 10:41:34 PST
svg/custom/conditional-processing-2.html is failing on Mac bots:

http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=svg%2Fcustom%2Fconditional-processing-2.html
Comment 23 Alexey Proskuryakov 2014-01-10 10:43:23 PST
Looks like EWS didn't catch that because it allows "flaky" tests, and this test appears to only fail when run for the first time, not when retried.
Comment 24 WebKit Commit Bot 2014-01-10 10:52:20 PST
Re-opened since this is blocked by bug 126762
Comment 25 Alexey Proskuryakov 2014-01-10 10:55:02 PST
Rolling out. Sample diff: http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20(Tests)/r161644%20(14912)/svg/custom/conditional-processing-2-diff.txt

I'm not sure what's going on with the tools here. WebKit2 bots seem to say that results are missing, and then that results are different on retry. But despite tools shortcomings, it seems clear that the test fails in some way, just not correctly reported.
Comment 27 Dirk Schulze 2014-01-10 11:11:49 PST
(In reply to comment #26)
> More here: http://build.webkit.org/results/Apple%20Mavericks%20Release%20WK1%20(Tests)/r161647%20(2244)/results.html

It might be better to change the painting tests to reference tests instead of DRT tests.
The JS tests can be pure js tests.
Comment 28 Frédéric Wang (:fredw) 2014-01-11 06:05:10 PST
Created attachment 220927 [details]
Patch with reftests
Comment 29 Build Bot 2014-01-11 06:51:09 PST
Comment on attachment 220927 [details]
Patch with reftests

Attachment 220927 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/4757409243332608

New failing tests:
svg/custom/conditional-processing-2.html
fast/canvas/webgl/uniform-samplers-test.html
Comment 30 Build Bot 2014-01-11 06:51:13 PST
Created attachment 220929 [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
Comment 31 Frédéric Wang (:fredw) 2014-01-11 06:58:48 PST
Created attachment 220931 [details]
Patch with reftests
Comment 32 Darin Adler 2014-01-11 15:01:42 PST
Comment on attachment 220931 [details]
Patch with reftests

View in context: https://bugs.webkit.org/attachment.cgi?id=220931&action=review

> Source/WebCore/svg/SVGSwitchElement.cpp:55
> +    // FIXME: The renderer must be updated after dynamic change of the requiredFeatures, requiredExtensions and systemLanguage attributes (http://wkb.ug/74749).

I don’t think it’s appropriate to use wkb.ug URLs in the WebKit source code. It’s neat how short they are, but we don’t want to use them here for the same rason we don’t use them in the change log.

> Source/WebCore/svg/SVGTests.cpp:32
> +#if ENABLE(MATHML)
> +#include "MathMLNames.h"
> +#endif

Conditional includes need to go in their own paragraph, rather than attempting to sort them in with the unconditional includes.

We should add this to the coding style guide; I looked and it’s not mentioned there!

> Source/WebCore/svg/SVGTests.cpp:133
> -    if (!m_requiredExtensions.value.isEmpty())
> -        return false;
> +    unsigned extensionsSize = m_requiredExtensions.value.size();
> +    for (unsigned i = 0; i < extensionsSize; ++i) {
> +        String value = m_requiredExtensions.value.at(i);
> +        if (!hasExtension(value))
> +            return false;
> +    }

This should be written like this:

    for (auto& extension : m_requiredExtensions.value) {
        if (!hasExtension(extension))
            return false;
    }

Lets not do the old style for loops in new code unless there is a reason.
Comment 33 Frédéric Wang (:fredw) 2014-01-12 06:18:30 PST
Created attachment 220972 [details]
Patch
Comment 34 Frédéric Wang (:fredw) 2014-01-15 09:25:02 PST
Can someone please commit the patch I uploaded last Sunday?
Comment 35 WebKit Commit Bot 2014-01-15 09:27:34 PST
Comment on attachment 220972 [details]
Patch

Rejecting attachment 220972 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-03', 'validate-changelog', '--check-oops', '--non-interactive', 220972, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

ChangeLog entry in LayoutTests/ChangeLog contains OOPS!.

Full output: http://webkit-queues.appspot.com/results/6254836169310208
Comment 36 WebKit Commit Bot 2014-01-15 10:57:33 PST
Comment on attachment 220972 [details]
Patch

Clearing flags on attachment: 220972

Committed r162083: <http://trac.webkit.org/changeset/162083>
Comment 37 WebKit Commit Bot 2014-01-15 10:57:39 PST
All reviewed patches have been landed.  Closing bug.