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

Programmatic fetching on Internet Explorer fails with InDesign demo EPUB #54

Closed
danielweck opened this issue Jul 13, 2014 · 16 comments
Closed

Comments

@danielweck
Copy link
Member

...even after "Blob-pinning" implemented by @aadamowski

Bugzilla 78:
https://app.devzing.com/Readium/bugzilla/show_bug.cgi?id=78

@aadamowski
Copy link
Member

I have a fix in vicinity - it turns out that Trident engine doesn't support loading documents from a Blob object URL.

For IE, going back to the old (pre commit dc6f4c6) logic of replacing content document DOM fixes this.

I currently have a quick and dirty fix based around a window.navigator.userAgent.indexOf("Trident") > 0 condition in my local repo, but would like to discuss the best, clean and correct approach.

@danielweck
Copy link
Member Author

Do you think this may have an impact on epubReadingSystem injection?

readium/readium-shared-js#41

@jccr
Copy link
Member

jccr commented Jul 15, 2014

@aadamowski Would something like iframe.contentWindow.document.open() , write(), close() work for you? https://github.com/readium/readium-shared-js/blob/feature/iframe_injection/js/views/iframe_loader.js#L61-L76

You can load HTML as plaintext programatically to the iframe using this API, and it seems to work well in Trident. A caveat is that to fix all relative URLs a <base href="root url here"> element is needed.

@aadamowski
Copy link
Member

@danielweck , yes, it would.

So that was the rationale behind commit dc6f4c6. I was trying to track it down, but found no info in the original pull request #45 .

This means we need a different approach for Trident. I'll try out @jccr 's suggestion.

Does anyone have a quick test EPUB for epubReadingSystem, like the one mentioned in readium/readium-js-viewer#13?

@aadamowski
Copy link
Member

Submitted a pull request. Using document.write() indeed works under IE. Availability of epubReadingSystem must still be tested - can you point to some test EPUBs?

Surprisingly, the document.write() approach on Chrome breaks CSS selectors that use namespace prefixes (e.g. used in the childrens-media-query.epub sample). For this reason, the document.write() approach is only employed when running on IE.

@jccr
Copy link
Member

jccr commented Jul 20, 2014

@aadamowski Do the CSS namespace selectors break on IE + document.write()?

@aadamowski
Copy link
Member

I didn't test that yet, since the childrens-media-query.epub fails to load at all on IE, apparently due to an unrelated compatibility issue.

I don't have other test EPUBs that would employ CSS namespace selectors.

@aadamowski
Copy link
Member

It seems that XHTML namespaces don't work for documents constructed using document.write().

The resulting document has a null namespaceURI on attributes tagged with a namespace prefix.

For example, the childrens-media-query sample has the following namespaced type attribute on a <div> element:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
...
    <div epub:type="chapter">   

When the document is constructed either programmatically (as in older Readium.js versions) or by setting the iframe's src to a text/xhtml Blob URL, the type attribute has the correct namespaceURI:

div
  ...
  attributes: NamedNodeMap
    epub:type
      ...
      namespaceURI: "http://www.idpf.org/2007/ops"

On the other hand, when the document is constructed through document.write(), the type attribute's namespaceURI is null:

div
  ...
  attributes: NamedNodeMap
    epub:type
      ...
      namespaceURI: null

Moreover, this behaviour is consistent between browsers and is probably by design:

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

@aadamowski
Copy link
Member

Thanks for pointers to samples, Daniel. Will investigate further.

@aadamowski
Copy link
Member

OK, the georgia-cfi sample was a bit easier for IE to render (albeit also problematic - the whole content is being rendered in an area the size of a poststamp, so I had to scroll through it by mouse-selecting the text).

The behaviour on IE is the same as on Chrome - namespaces on attributes aren't applied, and CSS selectors don't match. <sarcasm>At least it's consistent cross-browser</sarcasm>.

But this means that the document.write() approach for loading content documents is suboptimal and we need a different one that would support XHTML namespaces and wouldn't interfere with epubReadingSystem injection and would work on IE. If such an approach exists.

@aadamowski
Copy link
Member

For now, I recommend merging pull request #56 as it makes IE at least render the document.

The other issues (small rendering area, XHTML namespaces) should be tracked separately.

@danielweck
Copy link
Member Author

@aadamowski, thank you for the XML NS tests. I commented on the Pull Request #56 discussion thread. If we collegially agree on merging, this will close this issue. As you said, we will need to file a separate issue to address XML namespace issues / CSS selector matching, etc.

@jccr
Copy link
Member

jccr commented Jul 28, 2014

@aadamowski Thanks for looking in to the XML issues with document.write()

Let's see if we can find a solution for this one.

@danielweck
Copy link
Member Author

I wonder if this issue is related?
#51

@danielweck
Copy link
Member Author

This was fixed some time ago (PR merged)

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

No branches or pull requests

4 participants