449746 - Switch content is not displayed with requiredExtensions="http://www.w3.org/1999/xhtml" or requiredExtensions="http://www.w3.org/1998/Math/MathML"

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Frédéric Wang (:fredw)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5

I made an XHTML+MathML+SVG page with Amaya. A  requiredExtensions="http://www.w3.org/1999/xhtml" is attached to the <foreignObject/> element. This attribute prevents Firefox to render the foreignObject properly.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Frédéric Wang (:fredw)]

Attachment: Testcase

Comment 2

[Robert Longson [:longsonr]]

At the moment mozilla any use of requiredExtensions disables rendering.

Where have you got http://www.w3.org/1999/xhtml from? Other than it is the namespace for xhtml. Why is that a valid value for requiredExtensions?

http://www.w3.org/TR/SVG/extend.html#AnExample uses "http://example.com/SVGExtensions/EmbeddedXHTML" and I've no idea at all where that is from.

Comment 3

[Frédéric Wang (:fredw)]

"requiredExtensions=http://www.w3.org/1999/xhtml" is automatically generated by Amaya. I don't know where this namespace comes but it could be a mistake of the developers.

Comment 4

[Frédéric Wang (:fredw)]

"requiredExtensions="http://www.w3.org/1998/Math/MathML"" appears in a W3C note (but the example is not well-formed...):

http://www.w3.org/Math/Documents/Notes/graphics.xml#mathml-in-svg-guidelines

Comment 5

[Robert Longson [:longsonr]]

http://lists.w3.org/Archives/Public/www-svg/2004Feb/0074.html

Looks from that like a browser can do whatever it likes and that trying to detect xhtml support using requiredExtensions is not going to be portable across different browser implementations.

Comment 6

[Frédéric Wang (:fredw)]

In the example given in the SVG list, it seems that the <switch/> is supposed to be used for non-standard XML content.

But in the W3C note, the author uses the <foreignObject/> for mathematical formulae inside SVG graphics. The <switch/> allows to give an alternate text for browser that can't display MathML inside SVG. It was the case for Firefox in the past and it is still the case for many browsers.

Since Firefox is able to display MathML and XHTML inside SVG, I suppose it must accept the two URI I gave for "requiredExtensions" (Amaya does so).

Comment 7

[Robert Longson [:longsonr]]

I just checked the Safari code and it works the same as Mozilla.

How do Opera and the Adobe SVG plug-in treat requiredExtensions? 

If you want this to go any further your best bet is to raise this on the w3c svg mailing list: http://lists.w3.org/Archives/Public/www-svg/ suggesting that SVG specification directly indicate that browsers that support xhtml and mathml should use those URIs.

Comment 8

[Frédéric Wang (:fredw)]

Attachment: Take into account the MathML and XHTML URI when checking the requiredExtensions

Hi,

I finally get an answer from the SVG WG:
http://lists.w3.org/Archives/Public/www-svg/2008Sep/0036.html

Comment 9

[Jonathan Watt [:jwatt]]

Thanks for pursuing this Frédéric, but all that Doug has has said so far is that the working group will discuss the issue, so it's a little early to request review.

Comment 10

[Frédéric Wang (:fredw)]

OK, no problem. At least a patch is ready. Let's wait the WG decision.

Comment 11

[Robert Longson [:longsonr]]

Comment on attachment 338442 [details] [diff] [review]
Take into account the MathML and XHTML URI when checking the requiredExtensions

> /**
>+ * Check whether we support the given extension string.
>+ *
>+ * @param aExtension the URI of an extension. Known extensions are
>+ *   MathML and XHTML.
>+ */
>+PRBool
>+NS_SVG_HaveExtension(const nsAString& aExtension)

This is an internal function to this module so it should be static and also should not begin NS_SVG_

>+{
>+  if (!NS_SVGEnabled()) {
>+    return PR_FALSE;
>+  }

These lines are not required. I think you copied them from NS_SVG_HaveFeature which needs them because it can be called from non-svg code.

>+
>+#define SVG_SUPPORTED_EXTENSION(str) if (aExtension.Equals(NS_LITERAL_STRING(str).get())) return PR_TRUE;
>+  SVG_SUPPORTED_EXTENSION("http://www.w3.org/1999/xhtml")
>+  SVG_SUPPORTED_EXTENSION("http://www.w3.org/1998/Math/MathML")

You need to put the line above inside #ifdef MOZ_MATHML

Comment 12

[Frédéric Wang (:fredw)]

Attachment: Take into account the MathML and XHTML URI when checking the requiredExtensions

Thanks a lot Robert. This is a new patch that takes into account your comments.

Comment 13

[Frédéric Wang (:fredw)]

The proposition of Doug:
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0299.html#start299

The resolution of the WG:
http://www.w3.org/2008/09/16-svg-minutes.html#item03

Comment 14

[Robert Longson [:longsonr]]

Comment on attachment 338448 [details] [diff] [review]
Take into account the MathML and XHTML URI when checking the requiredExtensions

When you ask for reviews on this I think you should get an additional review from a mathml peer as they need to sign off that our implementation of mathml is sufficiently complete that we should advertise it as supported.

Comment 15

[Frédéric Wang (:fredw)]

Attachment: Testcase

Same testcase, but translate the alternate text "foreignObject not supported" so that it is in the visible area of the svg canvas.

Comment 16

[Robert Longson [:longsonr]]

See comment 14 for additional review.

Comment 17

[Karl Tomlinson (:karlt)]

Comment on attachment 338448 [details] [diff] [review]
Take into account the MathML and XHTML URI when checking the requiredExtensions

This looks good to me.

Comment 18

[Karl Tomlinson (:karlt)]

(In reply to comment #16)
> See comment 14 for additional review.

Roger is no longer at uq, and so may not be responsive at that address.
I suggest waiting a few more days to see if Roger comments, and if not go with attachment 338448 [details] [diff] [review] as is.

Comment 19

[Karl Tomlinson (:karlt)]

(In reply to comment #14)
> When you ask for reviews on this I think you should get an additional review
> from a mathml peer as they need to sign off that our implementation of mathml
> is sufficiently complete that we should advertise it as supported.

The MathML support is as sufficiently complete as people expect and at least as good as any other browser.

Comment 20

[Frédéric Wang (:fredw)]

Roger does not seem to respond, so I'll add the keyword "checkin-needeed" to this bug.

Comment 21

[Robert Longson [:longsonr]]

You need a superreview before this can be checked in.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

   // no extensions.  So, if extensions are required, we don't have
   // them available.

This comment is incorrect and needs to be fixed.

IMHO this code should be rewritten to use FindAttrValueIn. That would avoid any need for this macro.

Comment 23

[Robert Longson [:longsonr]]

I'm not sure I follow. FindAttrValueIn is for finding one of a number of possible attribute values and we're parsing a space separated list of values.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oops, of course you're right. So one more question: why are we returning false if the required extensions list is the empty string?

Comment 25

[Frédéric Wang (:fredw)]

http://www.w3.org/TR/SVG11/struct.html#RequiredExtensionsAttribute

"If the attribute is not present, then its implicit return value is "true". If a null string or empty string value is given to attribute requiredExtensions, the attribute returns "false"."

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That's weird. But OK, just fix the comment and we should be good to go.

Comment 27

[Frédéric Wang (:fredw)]

Attachment: change comments to indicate support of XHTML/MathML [Checkin: Comment 28]

Comment 28

[Serge Gautherie (:sgautherie)]

Comment on attachment 345020 [details] [diff] [review]
change comments to indicate support of XHTML/MathML
[Checkin: Comment 28]

http://hg.mozilla.org/mozilla-central/rev/5fd646e4fcd2

NB: Please, provide a patch with full file path in the future.