26

I am developing an html application that is essentially a series of pages like a book. Within this application, I would like to store several JavaScript variables across pages. Think things like pages read, bookmarks, etc. When this application is viewed over HTTP, I plan to use localStorage with fallbacks for older browsers (globalStorage, userData, etc.).

However, this completely breaks down if the files are accessed via "file://", for example if viewed off of a CD. It seems that most (if not all) localStorage solutions will not work under the file protocol. Cookies are not an option either under "file://".

Any ideas on how to persist JavaScript data across html pages when they are being viewed via "file://"?

It really only needs to be available in the current user session. I really don't want to use frames, but as of yet, I can't think of another way to accomplish this

mplungjan
  • 155,085
  • 27
  • 166
  • 222
Bart
  • 6,586
  • 6
  • 41
  • 52

2 Answers2

9

A buddy of mine at work helped me out with this problem by sharing his implementation of using window.name to store data across pages of a single window/session.

A similar implementation (and discussion around the method) can be found here: http://ajaxian.com/archives/whats-in-a-windowname

Preliminary tests I've been doing on this method look very promising. I tested this, under the file protocol (loading page from desktop, a.k.a. - "file:\") on the following browsers. It worked on all of them!!

  • IE 6
  • IE 7
  • IE 8
  • IE 9
  • FF 3.6
  • FF 4
  • Chrome 11
  • Opera 10
  • Safari 4

I have not yet done any testing as to how much data you can store here, but the internets seem to agree on a value of 2 MB.

Sources, links, more information

Bart
  • 6,586
  • 6
  • 41
  • 52
  • I've put together a demo of this (used to keep a persistent sidenav scrolled identically as you move from page to page): http://phrogz.net/tmp/data-through-window.name/ Tested to work with Chromev21, FFv14, IE8 and IE9 on both `http://` and `file://` – Phrogz Aug 01 '12 at 17:15
  • Great demo! I might suggest a fallback to `sessionStorage`. This would give you a little extra insurance in the event a future browser version decided to plug the `window.name` "hole". – Bart Aug 01 '12 at 18:04
3

On Webkit (Chromium 12.0.742.21 dev-m) localStorage over file protocol worked fine to me.

On Gecko it's reported and should be improved soon.

You can even find a workaround, but I recommend that you develop using Chrome nightly build. So you'll not lose time moving it back to localStorage in future.

kbtz
  • 12,311
  • 8
  • 48
  • 69
  • Is `storageSession` the different from `localStorage` or `globalStorage`? I thought Gecko left it out of `file://` on purpose. – Jeff May 06 '11 at 18:11