Bug 152455 – [GTK] W3C CSS2.1 anonymous table tests are failing

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

We need to add GTK expectations for the W3C CSS2.1 anonymous table tests added in r190893, but all the tests are currently failing. It is expected that no red text appear, but there is lots of red text. The problem is probably related to this nasty problem (output taken from table-anonymous-objects-015.xht):

CONSOLE MESSAGE: line 12: SyntaxError: Unexpected token '<'
CONSOLE MESSAGE: line 20: ReferenceError: Can't find variable: doTest

i.e. the GTK port is choking on this section of the test:

    <script type="text/javascript"><![CDATA[
      function doTest() {
        var s = document.getElementById("s");
        s.disabled = true;
        document.documentElement.className = "";
      }
    ]]></script>

I had not seen CDATA before today, but I guess the problem is that the GTK port is trying to handle this as an HTML document instead of as an XHTML document. It is probably relevant that shared-mime-info detects the MIME type of the test file as text/html (check with the file properties dialog in nautilus), whereas for our other XHTML layout tests it detects the MIME type as application/xhtml+xml. So maybe the test is not valid XHTML for some reason, but I think more likely we are misdetecting the MIME type. (Do we use shared-mime-info for that?)

Hey Carlos Lopez, what is your preferred way to handle this situation? I hesitate to add expectations now as that would make the tests pass incorrectly.

[Michael Catanzaro]

I fixed the tests locally by simply renaming the file extension, e.g. by renaming table-anonymous-objects-015.xht to table-anonymous-objects-015.xhtml. This also causes shared-mime-info detects the content type as application/xhtml+xml instead of text/html.

Bastien, I'm CCing you since this might be a shared-mime-info bug. I found in freedesktop.org.xml.in:

  <mime-type type="application/xhtml+xml">
    <_comment>XHTML page</_comment>
    <acronym>XHTML</acronym>
    <expanded-acronym>Extensible HyperText Markup Language</expanded-acronym>
    <sub-class-of type="application/xml"/>
    <generic-icon name="text-html"/>
    <glob pattern="*.xhtml"/>
    <root-XML namespaceURI='http://www.w3.org/1999/xhtml' localName='html'/>
  </mime-type>

Maybe the simple fix is to add:

    <glob pattern="*.xht"/>

? But maybe that would just be a workaround, not sure.

[Mario Sanchez Prada]

As I mentioned in the mailing list [1], I think shared-mime-info could be the right place to change this, so that WebKit will do the right thing according to the MIME types registered in WebCore/platform/MIMETypeRegistry.cpp.

That said, I'm not sure of what other implications doing that change in shared-mime-info could have, so better see what Bastien has to say about it before assuming that's the right thing to do instead of, say, hacking it somehow in WebKit itself (if that's even possible).

[1]https://lists.webkit.org/pipermail/webkit-gtk/2016-January/002501.html

[Bastien Nocera]

I've added *.xht as a suffix for XHTML files in shared-mime-info, but, really, relying on something as coarse as the mime-type from shared-mime-info seems bizarre. I mean, you have a parser that surely can see the difference between HTML, XHTML and whatever other variants, and a big one at that.

If you need something more from shared-mime-info, please file a bug with a patch following the HACKING file in the shared-mime-info git repo.

[Michael Catanzaro]

Created attachment 268664 [details]
Patch

[Michael Catanzaro]

(In reply to comment #3)
> If you need something more from shared-mime-info, please file a bug with a
> patch following the HACKING file in the shared-mime-info git repo.

Your patches work great, nothing else needed. Thanks!

[Mario Sanchez Prada]

Comment on attachment 268664 [details]
Patch

LGTM

[WebKit Commit Bot]

Comment on attachment 268664 [details]
Patch

Clearing flags on attachment: 268664

Committed r194845: <http://trac.webkit.org/changeset/194845>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.