Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Home page broken on Safari: "There was a problem generating 990 ." #2

Open
jasonszhao opened this issue Aug 19, 2019 · 2 comments
Open

Comments

@jasonszhao
Copy link

jasonszhao commented Aug 19, 2019

Steps to Reproduce (Safari):

  1. Go to the project home page.
  2. Enter the demo URL
  3. Visit any of the "Transformation results."

Or just visit https://betson.github.io/irs-efile-viewer/transform.html?f=https%3A%2F%2Fs3.amazonaws.com%2Firs-form-990%2F201541349349307794_public.xml.

Result:

The new tab closes. "There was a problem generating 990 ." is displayed in red.

The console reports:

[Log] TypeError: Argument 1 ('node') to XMLSerializer.serializeToString must be an instance of Node (transform.js, line 262)
serializeToString
render — transform.js:333
(anonymous function) — transform.js:253
promiseReactionJob

Environment

This happens on my Safari 12.1.1 (14607.2.6.1.1), macOS 10.14.5.

It works perfectly fine on my Firefox 68 on the same machine.

Also, the ProPublica Nonprofit Explorer, which uses an "e-file viewer adapted" from this project, works fine on my Safari.

@jasonszhao jasonszhao changed the title Broken on Safari: "There was a problem generating 990 ." Home page broken on Safari: "There was a problem generating 990 ." Aug 19, 2019
@jasonszhao
Copy link
Author

jasonszhao commented Aug 19, 2019

I don't know XML or XSLT, but the problem appears to be my Safari's XSL support. The program fails at when XSLTProcessor.transformToDocument is called here.

I made a small repro of this bug, and found that once such unsupported XSL tag in Safari seems to be xsl:include. Safari prints null, and other browsers (FF and Chrome) print a Document.

test.xsl - commenting out the include line would make this "compile" in Safari.

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

  <xsl:include href="dummy-include.xsl" />

  <xsl:template match="/">
    <xsl:text disable-output-escaping="yes">&lt;!DOCTYPE html&gt;</xsl:text>
    <html>
    </html>
  </xsl:template>

</xsl:stylesheet>

dummy-include.xsl


<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <xsl:param name="AppProp" select="/AppData/ApplicationProperties" />

</xsl:stylesheet>

I'm not sure if its worth fixing this bug, since this project already uses XSLT files from the IRS. It might be worth looking into ProPublica's solution.

@betson
Copy link
Owner

betson commented Jul 25, 2022

Thanks for the detailed research on this. I've confirmed this still doesn't work on the most recent Safari either (version 15.5 on MacOS v12.4). Some naive searching says it may be due to a WebKit bug. This was originally created in the context of a Google Chrome issue back in 2009, though the transformations work fine in Chrome now.

In that Chromium thread there's a workaround proposed to request the XML of each <xsl:include> and merge that into the core .xsl file you're using for transformation. It could work, but I haven't run a test for that.

A better way of doing all of this is what ProPublica is probably doing -- running the transformations server-side. That's where I initially started with this project when I was building it as a proof-of-concept. But being able to run the transformations client-side gave me a lot more freedom to publish this without needing to indefinitely host and maintain the infrastructure to run the transformations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants