search

readium / readium-shared-js

Repository for the shared JavaScript libraries that are used in the SDK-Launchers and other applications developed on top of the SDK
BSD 3-Clause "New" or "Revised" License
78 stars 101 forks source link

Invalid location/CFI received #453

Open EdwinGuzman opened 5 years ago

EdwinGuzman commented 5 years ago

This issue is a Bug

Related issue

Example: See also #388

Observed behavior

We tested this on the debugger using Readium's Readium_cloud-reader-lite.zip (hosted here: https://readium.org/technical/technical-notes/_posts/testing-with-cloudreader/)

Under certain circumstances, a location/CFI reported by the SDK becomes invalid (or no longer exists in the new DOM structure). The easiest way to demonstrate is to:

  1. Ask the SDK to give us its current location.
  2. Make some change that affects the page structure or DOM.
  3. Navigate away to some random spot (best if a different chapter).
  4. Attempt to re-apply the CFI from step 1.

Outcome:

  1. The open request fails, either sending the user to the beginning of the chapter (the idref from the attempted page open), or it just silently fails and you stay on the page you're already on.

In our test, we ask for the current location calling bookmarkCurrentPage(), make the font change, navigate away, and then try to navigate back to that spot using openSpineElementCfi().

Steps to reproduce

The "changes" we've tested so far that we know will cause the bug:

  1. Changing the text size
  2. Applying the CFI across different browsers (Android to iOS or vice versa)

Test file(s)

We tested on a handful of DRM-free Epub's, which we can provide but don't expect to make a difference.

Product

danielweck commented 5 years ago

Just a note: I am not sure about the version of Readium_cloud-reader-lite.zip available on the readium.org website. I would recommend using the official GitHub releases: https://github.com/readium/readium-js-viewer/releases/tag/0.31.1

danielweck commented 5 years ago

By design, CFI references do break if the DOM / document markup changes. There is no way around that, other than blacklisting / skipping injected elements that are added at runtime for specific presentation / rendering purposes (i.e. not part of the original authored publication, and not meant to be persistent). For example, Readium blacklists the markup generated for MathJax, annotations, etc.