-
Notifications
You must be signed in to change notification settings - Fork 107
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
When a DRM key error occurs while opening an EPUB, navigator is stuck in loading state #396
Comments
One thing I don't understand is that if there's a DRM key error, shouldn't the spread not even begin to load? Since after all the resource won't be able to be used. But instead it seems like we are injecting the JS anyway? |
Are you talking about this part?
This does not inject the Readium JS layer into the resource. Instead, it executes a script within the spread view context. Since the spread view is unaware of any decoding errors in the resource, it continues as if the resource is valid. |
I may have spoken incorrectly, sorry. I'm still trying to piece together all the spread view lifecycle events and moving parts in my head. But yes I was referring to that. I guess I was trying to understand if that script should be executed even if a DRM error had happened before, since such an error (for example one stemming from a broken DRM key) will prevent any resource from being decrypted. But it sounds like it should, if I understand correctly? Because, and pls let me know if I am off, basically:
However, as I show in the (updated) reported log, after reading the DRM key from disk successfully, once the |
beside the above, with the recent additions to index-reflowable.js and other JS files in my commit, I am seeing the |
our
|
Yes, because if you have two FXL resources displayed side by side, one might work but not the other. For reflowable though, the publication resource is loaded directly in the web view, so it might fail if the HTML is incorrect. I don't know about your particular DRM, but I would attempt to check for the validity of the key when opening the publication, in the However what we're talking about can still be useful if the publication appears to be valid, but one or more resources are corrupted for some reason.
I'm not sure I understand, don't we want to cancel the stop to keep the spinner running when receiving |
we do, but I think we'd want to do it only when there are no errors, right? The problem is that in case of errors the Here's my updated code: https://github.com/ettore/swift-toolkit/commits/fix/neverending-loading-state
|
This is a good point, there are some validity checks that can be done beforehand, such as checking the key length. But the key could be corrupted and have the correct length. Generally speaking, since we don't control the decryption keys (which are shipped with the EPUB by the distributor) it will be hard to determine if the key is valid before using it. |
I would try decrypting the first resource (or part of it) to at least make sure the key is valid. It's better to fail with a protection error when opening the book than reporting the error from the navigator.
I see, I was confused because FXL and reflowable are two very different cases. It's challenging talking about both at the same time. In a nutshell, the JS files you modified for FXL ( Note that in the case of a double-page spread ( I would recommend fixing the problem first on reflowable, then FXL one page, then FXL two pages. |
Thank you, that was exactly the problem. By sending the I opened a tentative PR, but if there's more work to do, happy to improve it. |
Describe the bug
Using Readium with Content Protection (for example using a DRM system such as Axis360) involves tracking potential DRM errors, such as invalid keys, keys corruption, or more in general the lack of a functioning key asset that decrypted the DRM-encrypted content. When such a situation happens, the Readium swift-toolkit doesn't present any errors to the user, and instead only shows a never-ending activity indicator.
How to reproduce?
Readium version
current top of
main
OS version
iOS 17
Testing device
Various simulators and iPhone 11
Environment
Additional context
On this branch I added a modification per discussion in slack where I am "optimistically" scheduling the stop of the activity indicator, and then canceling the stop if the spread starts to load. Below is the console log when I attempt to open an EPUB with a corrupted DRM (Axis360) key:
The text was updated successfully, but these errors were encountered: