navigator.epubReadingSystem injected in EPUB content documents with delay about readium-shared-js

[jccr]

I have pushed a branch with a solution to this:
feature/iframe_injection

[danielweck]

Thanks!
This "solution" is elegant, but the navigator.epubReadingSystem object is
JSON-stringified (copied), therefore the actual instance does not
get shared amongst iframe-hosted EPUB HTML content documents. Am I right?
This is problematic, as any navigator.* object reference is meant to be
shared. We need navigator.epubReadingSystem to reflect a shared state (for
future use with widgets, etc.).
dan

On Monday, July 14, 2014, Juan Corona [email protected] wrote:

I have pushed a branch with a solution to this:
feature/iframe_injection

—
Reply to this email directly or view it on GitHub
#41 (comment)
.

[jccr]

@danielweck
Yes, the epubReadingSystem is serialized into "source" text. This is how it's made available from the very start. This is not necessarily limited to JSON, as you can see by my attempt to pass along simple functions.

I'll see if I can pass along an actual instance before the iframe document is written to. (And how something like this behaves across multiple browser engines.)

[jccr]

It looks like by just simply doing

        iframe.contentWindow.document.open();
        iframe.contentWindow.navigator.epubReadingSystem = navigator.epubReadingSystem;
        iframe.contentWindow.document.write(htmlText);

Achieves just that.

[danielweck]

That would be great!
We now need to check all the features that depend on proper XHTML serialisation, like namespace-aware CSS selectors, annotations and Media Overlays -injected content, etc. We also need to thoroughly test on native apps, as the UIWebView tends to behave very differently in SDKLauncher-iOS/OSX/Android compared to pure browser implementations, especially when dealing with XHTML (e.g. self-closing tags).

[danielweck]

For reference:
https://github.com/readium/readium-shared-js/blob/feature/iframe_injection/js/views/iframe_loader.js#L55

[danielweck]

I am wondering whether the document.open()+write() approach has an impact on "programmatic fetching" (document / file Blobs, etc.) See readium/readium-js#54

[jccr]

I believe it will.. It calls the basic iframe loader's loadIframe with an "empty" blob document as a source. This will throw everything off. I'm still unsure on how to test the use of the zipIframeLoader. Is it used in the chrome extension? Is it at all used from the cloud reader?

If the document.open()+write() approach is found to work on both loaders then we should refactor them to use the same approach.

[mickael-menu-mantano]

I tried a similar approach – albeit not using document.open() + write() – to inject JavaScript before the page's JavaScript is executed and faced a problem when changing the spine item in fixed layout books. The first time we set the href of the iframe it worked properly but the second time (next spine item), my JavaScript wasn't executed. I had to recreate a new iframe for each chapter for the solution to work, but it introduced other bugs in the layout when rotating the screen.

It seems very similar to the issue Juan talked about on the mailing-list, in the mail entitled "[AppJS] Readium + MathJax & Iframe injection":

Iframes need to be destroyed and recreated on every content document change. Iframe elements once rendered cannot be re-used when switching documents, or else MathJax will not reinitialize and render MathML after the switch. This still needs to be implemented for all other views, not just reflowable views.

Did you check if the epubReadingSystem was still available when changing the spine item in a fixed-layout?

[danielweck]

I remember having conversations with Boris about the pitfalls of "iframe
recycling". I'll be following this discussion very closely. Dan

On Wednesday, July 16, 2014, Mickaël Menu [email protected] wrote:

I tried a similar approach – albeit not using document.open() + write() –
to inject JavaScript before the page's JavaScript is executed and faced a
problem when changing the spine item in fixed layout books. The first time
we set the href of the iframe it worked properly but the second time (next
spine item), my JavaScript wasn't executed. I had to recreate a new iframe
for each chapter for the solution to work, but it introduced other bugs in
the layout when rotating the screen.

It seems very similar to the issue Juan talked about on the mailing-list,
in the mail entitled "[AppJS] Readium + MathJax & Iframe injection":

Iframes need to be destroyed and recreated on every content document
change. Iframe elements once rendered cannot be re-used when switching
documents, or else MathJax will not reinitialize and render MathML after
the switch. This still needs to be implemented for all other views, not
just reflowable views.

Did you check if the epubReadingSystem was still available when changing
the spine item in a fixed-layout?

—
Reply to this email directly or view it on GitHub
#41 (comment)
.

[danielweck]

As verified by @aadamowski, document.write() breaks XML namespaces, see:
readium/readium-js#54

[danielweck]

Fixed in
#76