Closed chrisbeech closed 9 years ago
Thanks for the report. Seems that Chrome's DOMParser fails on the UTF-8 BOM at the start of internal xml files in an ODS file exported from Google Docs. Surprised to see that happen. No fix for that yet, possibly can be worked around by cutting off the BOM on Chromium-based browsers.
BTW, seems the ODS as created by Google Docs is breaking the ODF spec. I tested with https://odf-validator.rhcloud.com/ and a few other tools and all complain about problems. Please report this to Google, they need to fix creating invalid ODF files. (Just because some other tools have possibly added workarounds to deal with that does not change that these are invalid ODF files, killing the idea of a standard format)
Having looked more into it, actually it seems not a failure of Chromium. After all the type of the parameter passed to DOMParser.parseFromString
is a string
, not raw data of a string. So there is no more place for a BOM.
Which is good news in the end, so it's actually a bug in WebODF and can be fixed. No need for workaround or getting another project to fix their code :) First draft of a fix seems to work fine.
Legend! Thanks so much!
To replicate:
U'll notice that the file works fine in FireFox and IE. However, in chrome the console spits out the following:
PluginLoader.js:115 Found plugin by mimetype and xhr head: application/vnd.oasis.opendocument.spreadsheet webodf.js:35 WARNING: refreshOdf called but ODF was not DONE. webodf.js:35 ERROR: Unable to load styles.xml 15webodf.js:35 will be back later...