IE has multiple severe errors in the console log file

[kimtuck]

When I view a particular epub in IE, I see a number of errors that I don't see when I view the same document in Chrome and Firefox. I have protractor tests that, at the end of each test, check the console.log to see if any severe errors were output. If severe errors occurred, then the test is failed.

So, these severe errors are preventing my protractor tests from passing in IE.

1. These messages occur very often. It seems to me that these are not really errors; as far as I can tell, the application continues to work correctly. If these are not really errors, please lower the severity.

• !iframe.baseURI => http://localhost:17105/library/testlibrary/EPubRead/doofvr9
• algorithm incorrect: downshiftedEntry.orderingByLastUseTimestampIdx: 6, i: 6 -- /ops/images/pub.jpg

2. I get this when moving back and forth between two chapters in a particular epub. I have not traced through the code to determine where it is occurring. It might be something in my implementation, rather than in Readium; so no need to take action until I get further info for you.

• [object Error]{description: "Access is d...", message: "Access is d...", name: "Error", number: -2147024891, stack: "Error: Acce..."}

3. I get this often as well; but I think that this is my implementation, rather than a readium issue. Again, no need to take action until I get further info.

• MEDIA12899: AUDIO/VIDEO: Unknown MIME type.

UPDATE: #3 is an issue caused by the inclusion of a file in the epub, where the mimetype of the file is not one that is recognized by readium.

[rkwright]

@kimtuck THanks for reporting this. Do you see 1 and 2 on all books or just some specific ones?

[kimtuck]

#1 -- first message occurs a lot; there is a console.error line that outputs this. I don't consider this an error; and the console.error statement could be removed.
#1 -- second message occurs often; and I have no idea what it means or why it occurs.

#2 I don't know yet. I've been working on other things for a while and so I haven't had time to investigate further.

#3 is not a readium issue per se; the publisher included a file with a mimetype that is not recognized by the browser; and thus the browser issues this error. The file in question is a css file; and is included by the xhtml file; but the manifest says it is of some other mimetype, not text/css.

[chine]

I have observed #1 as well. However, just the iframe.baseURI part.

I can add that I observe (consequently, I presume) IE making requests for the referenced content of the document from the stated (incorrect in our case at least, our application is hosted from a different domain than the content) base URI, which 404, and then again from the desired base URI.

[danielweck]

The iframes that host EPUB content documents (HTML files) are actually fed with BlobURIs in the cloud reader (rather than a regular URL), or via document.write() in the IE case. So the baseURI is important to resolve relative / linked resources. The reason why it's a console.error() log message, not a lower-priority console.warn() is to be debated (we need to figure-out / test what happens when the iframe baseURI is missing)

https://github.com/readium/readium-js/blob/develop/js/epub-fetch/iframe_zip_loader.js#L36

            if (!iframe.baseURI) {

                if (isIE && iframe.ownerDocument.defaultView.frameElement) {

                    //console.debug(iframe.ownerDocument.defaultView.location);
                    iframe.baseURI = iframe.ownerDocument.defaultView.frameElement.getAttribute("data-loadUri");

                    console.log("EPUB doc iframe src (BEFORE):");
                    console.log(src);
                    src = new URI(src).absoluteTo(iframe.baseURI).search('').hash('').toString();
                }
                else if (typeof location !== 'undefined') {
                    iframe.baseURI = location.href + "";
                }

                console.error("!iframe.baseURI => " + iframe.baseURI);
            }