-
Notifications
You must be signed in to change notification settings - Fork 108
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
Better Safari Support #28
Conversation
Cool, glad to see your pull request, thanks for helping out the project. Patrick On Thu, Mar 20, 2014 at 12:08 PM, Corey Wilson notifications@github.comwrote:
Patrick Keating |
Glad I can help! It's an awesome project! The 2nd commit adds a polyfill for supporting iOS 6 |
Hello, I have found that the latest develop branches (viewer, readium-js, I can provide more information in the meeting tomorrow, Ric, will you put Thanks, Patrick Keating |
hello patrick, i cannot even get a zipped epub to open at all. i must be On Monday, June 16, 2014, Patrick Keating notifications@github.com wrote:
|
I can get it to open but the play button does not do anything. Here is the { "title" : "Ladybug Girl", "author" : "David Soman and Jacky Davis", "packagePath" : "EPUB/package.opf", "rootUrl" : "epub_content/ladybug.epub" } On Mon, Jun 16, 2014 at 2:53 PM, danielweck notifications@github.com
Patrick Keating |
Do you have an example ePub you could send so I could replicate the issue? If I had to guess it's likely due to limitations of zip.js but I will be happy to look in to it.
|
Thanks Patrick, that's what I do too, but the EPUB does not open. I wonder https://groups.google.com/d/msg/readium-dev/qkoYsF6QvCM/tvc29e3YafUJ Dan On Mon, Jun 16, 2014 at 11:59 PM, Patrick Keating notifications@github.com
|
Will do Sent with my thumbs
|
Hey Daniel I don't believe it has to do with that post. All .epub files I'm trying If it still doesn't work you should have some errors in the js console. -Corey On Tue, Jun 17, 2014 at 1:40 AM, danielweck notifications@github.com
|
I'm attempting to load an unpacked chrome extension into Chrome OSX after Thanks, Patrick Keating |
are you sure that the unpacked extension path is pointing to the build On Wednesday, June 18, 2014, Patrick Keating notifications@github.com
|
Haha! Yes, I was pointing at the wrong folder! It seems like a major design flaw that I should have to point my browser at Thanks, Daniel On Wed, Jun 18, 2014 at 11:20 AM, danielweck notifications@github.com
Patrick Keating |
tip: "grunt chromeAppDevBuild" to get a different icon and app ID, separate On Wednesday, June 18, 2014, Patrick Keating notifications@github.com
|
That is really handy to separate it from the Chrome Web Store version, Patrick On Wed, Jun 18, 2014 at 11:25 AM, danielweck notifications@github.com
Patrick Keating |
Hello all, the discussion seems to have digressed from the original topic (Safari support). One thing to keep in mind - media overlays currently do not work for zipped EPUBs when read using plain browser-based viewer utilizing the Taking this into account, does anyone still have problems:
|
@aadamowski See new issue here: |
Data isn't served correctly due to a webkit bug that caches some byte range requests. The problem only presents itself when you are viewing the contents of the epub directly by pulling out specific parts of the compressed epub on the fly.
Steps to reproduce:
Expected Result:
The red "Cover Page" in the demo epub
Actual Result:
A blank page
Technical Details:
The problem is when zip.js is making the request for a byte range by adding the (example) headers If-Range:"21577-1395235757000", Range:bytes=866-1023 Safari is incorrectly returning the same "range" of bytes no matter what is specified in the headers. Here's a few screenshots from Safari Dev Tools that may explain it more clearly than I am :)
First byte range request made:
Second byte range request made:
Notice how Safari also incorrectly reports "No" in the "Cached" column even though the data is clearly being cached which is apparently a bug itself.
This doesn't present itself on unzipped epub content since it makes a full request (not byte range) for each document as it is needed. Thankfully Safari honors the If-None-Match headers-- if added (and does not match the requested files etag) it will serve the correct data for the request and correct the issue.