readium-shared-js icon indicating copy to clipboard operation
readium-shared-js copied to clipboard

window.location.href in scripted EPUB HTML content documents messes-up the iframe state

Open danielweck opened this issue 8 years ago • 11 comments

In other words, dynamic hyperlink creation / activation and window.location redirect are not captured / intercepted by Readium. See internal_links_support.js and processLinkElements(): https://github.com/readium/readium-shared-js/blob/develop/js/views/internal_links_support.js#L180

danielweck avatar Mar 17 '16 10:03 danielweck

Original issues: https://github.com/readium/readium-js-viewer/issues/504#issuecomment-197804416 https://github.com/readium/readium-js-viewer/issues/508#issuecomment-197804546

danielweck avatar Mar 17 '16 10:03 danielweck

Is it possible to intercept window.location.href changes? Or to override the property? (probably does not work in all browsers though)

danielweck avatar Mar 17 '16 17:03 danielweck

Changed priority to High from Blocking. Would have made it medium except that the problem book was generated in InDesign

rkwright avatar Mar 29 '16 16:03 rkwright

I faced this very same issue today with a book from InDesign and I didn't found an acceptable way to solve it.

The only hack I found was to compare the iframe.src value with the iframe.contentWindow.location.href during the load event of the iframe. If those 2 values are different, we call the openContentUrl() method with the new URL. It kinda works but the content flashes and encrypted fonts don't work.

johanpoirier avatar Jul 05 '16 15:07 johanpoirier

Yes, it is a good idea to listen to the iframe load event, as any EPUB-scripted change to window.location.href would be detected there.

danielweck avatar Jul 05 '16 15:07 danielweck

Hello, How and where do you listen to the iframe load event ?

romaingiard avatar Jan 09 '17 08:01 romaingiard

Hi,

You can see a load listener here: https://github.com/readium/readium-shared-js/blob/develop/js/views/iframe_loader.js#L86

johanpoirier avatar Jan 09 '17 09:01 johanpoirier

Well, in Readium (Chrome, hybrid, and native apps), there is a default "iframe loader" which sets up the onload() event callback on iframe HTML containers that are loaded with a plain src URL attribute: https://github.com/readium/readium-shared-js/blob/master/js/views/iframe_loader.js#L86

There is also a special "iframe loader" for the cloud reader that handles loading preprocessed EPUB content documents (e.g. HTML prefetched and supplied as binary Blob / BlobURI): https://github.com/readium/readium-js/blob/master/js/epub-fetch/iframe_zip_loader.js#L129

danielweck avatar Jan 09 '17 09:01 danielweck

Thank you for your answers, johan could you please give me your source code for this function ?

romaingiard avatar Jan 09 '17 09:01 romaingiard

When the src of an iframe container is "forced" by scripts executed in EPUB HTML documents (typically, via window.location.href), several functions of the reading system are bypassed / not activated correctly. This includes: hyperlinking (internal to EPUB publication), obfuscated fonts, MathML / MathJax, Media Overlays, fixed layout scaling, etc. Basically, the reading system needs to take control over how/when EPUB content documents (HTML, SVG) are injected in iframe containers. There is an exhaustive description of RS responsibilities here: https://github.com/readium/readium-shared-js/wiki/ContentModifications

danielweck avatar Jan 09 '17 09:01 danielweck

So, when a "forced" change to iframe.src is detected, the reading system should intercept this, and "redirect" the URL request in order to a resume normal loading behaviour. Perhaps the best way to implement this in Readium is to wire-up a hyperlink action via: https://github.com/readium/readium-shared-js/blob/develop/js/views/internal_links_support.js#L180

danielweck avatar Jan 09 '17 09:01 danielweck