Fix app not working in Chrome when served from a filesystem

[explorigin]

This partially addresses #71. The point here is to prevent localStorage failure from disabling the whole application. This allows Chrome to at least be used when viewing from a file:// even if settings are not preserved across sessions.

[johndyer]

This is great. But Chrome still doesn't allow file:// based ajax either, so the app still fires the warning to open Chrome with --allow-file-access-from-files right?

[explorigin]

Yes, you're correct. I had an old session open that I started with that flag and hence forgot about it. But we could use JSONP to solve that problem.

[johndyer]

I wish we could. But you can't really make JSONP work with local files
since there's no server to wrap the content in a function...

On Fri, Sep 4, 2015 at 8:29 AM, Timothy Farrell [email protected]
wrote:

Yes, you're correct. I had an old session open that I started with that
flag and hence forgot about it. But we could use JSONP to solve that
problem.

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

John Dyer - http://j.hn/

[explorigin]

But we do have control over the generated files. It's a matter of deciding what our function name is and statically using that one when we generate files. This is a bit of a hacky solution but would work.

If this is an acceptable solution, I would rather decide that the JSONP function name be define and these files automatically become AMD modules. Then we could take advantage of all the benefits of RequireJS (all the while having a working solution for offline Chrome).

[johndyer]

I would SOOOO love to do that.

However, part of the original app requirements were to have the chapters be
functional static HTML that can be used on lower powered, slower devices.
This means they need to be real HTML files, not strings wrapped in a JSONP
function. I would love it to run on Chrome out of the box, but we decided
that overcoming Chrome's limitations weren't a good enough reason to make
the data non-functional.

I've been searching for a solution to this for some time, so if you can
come up with one, I'd love to hear it!!

On Mon, Sep 7, 2015 at 2:27 PM, Timothy Farrell [email protected]
wrote:

But we do have control over the generated files. It's a matter of deciding
what our function name is and statically using that one when we generate
files. This is a bit of a hacky solution but would work.

If this is an acceptable solution, would rather decide that the JSONP
function name be define and these files automatically become and AMD
module http://requirejs.org/docs/whyamd.html. Then we could take
advantage of all the benefits of RequireJS http://requirejs.org/ (all
the while having a working solution for offline Chrome)

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

John Dyer - http://j.hn/

[explorigin]

Can you give me some more ideas about what is a "lower powered, slower device"?

You're already parsing the HTML as a string in Javascript (with jQuery here: https://github.com/digitalbiblesociety/browserbible-3/blob/master/app/js/texts/textprovider-local.js#L85) so the AMD method shouldn't add considerable overhead over what you already have.

In case I've missed something in reading the source above, the only option left is use iframes but that might run astray of the scroll controller.

[explorigin]

Oh sorry I missed the "functional static" part. Could we have the content in two files (html and JS string) for two separate modes since the static site is already a separate mode until itself?