I'm making a bookmarklet, and the bookmarklet goes to about:blank, then stores data under localStorage (technically, it downloads a script that stores data under localStorage)
The idea is that it downloads a script, and stores it under localStorage. That way, it doesn't have to download it again. However, there is no way of ensuring that one of the scripts won't try to edit the contents of another script (in localStorage).
So, I was wondering if it was possible to get a fresh context for localStorage, e.g. via going to about:blank/xyz. However, I do not want this to go to a website, even if the website is specially designed for this. I want this to be entirely local (the entire purpose behind this is to save bandwidth).
Or, being able to somehow sandbox localStorage would work too (in fact, that would be much preferred)
Any thoughts?
TL;DR I want to be able to have a fresh context for localStorage, without accessing a website (e.g. via about:blank, hence the title: Multiple about:blank's)
Related
Background:
I have built an offline HTML5 application that stores some data into the local browser db using pouchdb.
Now the requirements have changed and I have to store large pdf documents(around 200 of them, each with 5mb - 8mb size) into the local browser so the user can view it offline when required.
Issue:
I don't think that it is a good idea to put these large documents received from server into my in browser database using pouchdb.
I would like to know if there is a way to put these documents into my device some how and then get a url reference pointing to the location within the local device ?.
Include the PDFs in your offline manifest, so that they're cached with the rest of the application. Then you just use your normal URL to refer to it, and it's satisfied from the offline app cache.
Re your question below:
When the application is loaded in the browser then i store the details of the associated pages into the browser via a manifest file. And when the user clicks on a 'SYNC' button then I communicate with the server and fetches all the pdfs associated with the user. If I have to persist these pdfs using the manifest then how can I do it ?.....the manifest is already stored
The way we do something similar is this: We have separate pages for the things that the user has taken offline (a day's worth of appointments, for instance), and a list page driven entirely by client-side data that lists those pages. Here's how it works:
When the user wants to take something they're looking at offline, they click a button which opens a URL with the information telling the server what they want (say, example.com/offline/stuff-saying-what-they-want-here/), and the server generates a page with that data embedded in it along with a manifest for the page and any assets it requires. So at that point, that information is available offline on that URL. When it loads, the page registers itself in a list in localStorage, giving a description of the page and its URL.
The list page (say, example.com/offline/list/) has its own manifest and assets, which don't change often because it's driven entirely by that localStorage information. It shows the list of things they have offline with links to them. It's primarily a convenience for users, in case they forget to bookmark the individual things they take offline; e.g., the idea is that they'll bookmark the list once, and never have to worry about bookmarking individual pages. (They could go hunting through their history, but it's a pain.) The list page keeps itself up-to-date by getting the list of known pages from localStorage when it loads, and subscribing to the storage event so if you load other pages in other tabs while the list is open, it sees them arrive and updates its list.
So without knowing anything about your app, it sounds like perhaps your main page could be like or list page, and clicking "sync" could open a page for the PDF, generating the manifest on the fly, and that page could register the PDF in localStorage the way we do with our offline pages so the main page can show their status correctly.
Obviously, there's potential there for the actual appcache and our localStorage list to get out of sync; we can't help it if a user clears appcache (which would make us list things that can't really be viewed offline) or clears localStorage (which would make is not list things they could view offline), but there we are. Users mostly don't do that, all that often.
In the future, you'll get much more granularity and control with service workers, but for now since service worker support is very thin on the ground so far, we're stuck with appcache and its fairly stodgy way of defining offline assets.
T.J. Crowder is right: if your PDFs are static and known in advance, then AppCache is the way to go. Unfortunately it does mean that each and every PDF will be saved in the user's browser when they first load the site, but maybe that's what you want.
Else if the PDFs are dynamic and not known in advance, then yeah, you may see performance problems from PouchDB with 5MB attachments. But if you want to try it out, then check out PouchDB attachments and blob-util. blobUtil.createObjectURL() is exactly what you're looking for in terms of a "local URL."
I'm writing a HTML5 site that's only going to be used internally at my corporation. I'm trying to think of a way that we can save down the state of a user's browser window for using to debug later. Is it possible?
To clarify the question, here is the context followed by the requirements.
Context:
A HTML5 page is rendered in their browser. They have input data into a couple text fields, have interacted with Javascript which now has a local transient state, and also saved data down to LocalStorage.
Requirements:
Save the URL the user is on, the current state of the HTML document (e.g. after any scripts such as AJAX, Bootstrap, etc have manipulated the content), the current state of Javascript variables, and a serialised version of LocalStorage. (I'll refer to all this state data as the 'snapshot').
As long as this snapshot is saved anywhere, our systems can access it. I.e. if it's saved down to a temp folder locally we can use enterprise tools to grab it and pass it onto a developer.
The developer will need to be able to intialise a browser state with this snapshot so that they can see what happened.
I am working on a Chrome extension that needs to save some information (tabs info mainly) that will exist throughout the lifetime of the extension (e.g , since the user starts using it until he closes the browser).
One option is to use localstorage, however localstorage can only save Strings and that makes it very uncomfortable for me (since I have a bunch of data to save - dates , URLs , integers etc). What I'm looking for is using my own javascript objects that will live throughout the time of the extension.
Now the problem is that defining these objects in a script in some javascript files will erase them each time the user clicks on the browser action . In other words I have a browser action called popup.html that includes a javascript file (in which I want to save my objects) and every time the user clicks on the browser action all the objects I defined in the JS file are lost, yet I want everything to be persisted .
What option do I have to keep data that persists through many clicks on the browser action and that is NOT localstorage?
You really should use localStorage (you may use JSON.stringify and JSON.parse).
If you really don't want to use localStorage nor a server side storage, use IndexedDb : https://developer.mozilla.org/en/IndexedDB/Using_IndexedDB
Try using the Filesystem API's persistent storage. That is more reliable than localStorage. localStorage will be cleared once the user clears the cache, cookies etc. Filesystem is more reliable.
This answer about using chrome.storage worked for me far better than the others.
https://stackoverflow.com/a/14009240/766115
It's like localStorage, but works between the popup / background and content scripts.
As a simple example, let's say I want to insert a word at the bottom of every webpage, and I want the user to be able to change that word. So I have an options page (within the extension), within which I take user input and use it to call "localStorage.preferences = x;".
Next, the user navigates to http://www.google.com/, and I inject a script which writes the word found in localStorage.preferences. The problem is, since I'm now at a different domain, I'm seeing the localStorage for google.com, not my extension.
How can I share data between my extension's options page and a script injected into some 3rd-party webpage?
It's not, perhaps, the most direct response to your question, but one way to potentially get around this would be to use message passing to fake direct access to local storage from another domain. Assuming you're running your Javascript in the context of a content script, you could pass a message to the background page asking for a key, which would return the contents of localStorage.
Is its possible to have a javascript file that is aware of two different HTML files? And how would I do this?
I would like to be able to have two pages. index.html and pictures.html. I have an index.js that changes the display properties of index.html (it puts data based on people into tables and makes it look nice). I would like this current index.js file also to be able to edit the pictures.html file and change information there. index.html would link to pictures.html to display pictures of a person (based on the persons name I have them saved smith1.jpg, smith2.jpg, reagan2.jpg, ect). Is there anyway that this javascript file could get DOM elements based on their id or class of the second file (pictures.html) even though it "lives in" index.html? When i say lives in it is called at the top of the index.html page.
thanks
A script can access elements on another page if it was loaded in some way of connection.
For example, if you make a popup using var popup = window.open(), the return value will contain a reference to the opened popup and this allows access to elements within the popup. E.g. popup.document.getElementById('something'). Pages loaded within frames, iframes and such have similar ways of access.
So yes, if your page loads the second page its script can work there as well. I suggest avoiding this beyond opening and closing popups from a script though; a script should stay inside the box of its page and if it needs to do larger operations on another page, that usually means that you need to change your code architecture a bit.
You'll need to explore server-side programming to accomplish your goal.
http://en.wikipedia.org/wiki/Server-side_scripting
...Or you could write a client-side application in which "pages" are separate views of one actual page or are generated from backing data structures. If you want persistance of what is created/edited, you'll still need server-side programming.
You can use the html5 (group of technologies) postmessage api as well.. This allows you to send messages to another page, and in that page you define an event handler that knows how to handle the message.
This also works across domains.
Here is a blog with an example I just randomly found via google:
http://robertnyman.com/2010/03/18/postmessage-in-html5-to-send-messages-between-windows-and-iframes/
Not possible on the client side if editing the actual HTML file is your goal. If getting pictures to show up depending on stuff a user does on another page is all you care about then there are lots of options.
You can pass small sets of data like stuff the user entered into tables via cookies for accessing the right sets of image files in a pre-established scheme. This would actually persist until a user cleared out cookies.
You could wrap both pages in same-domain iframe elements with the parent element containing just the JS. This would allow you to persist data between pages and react to iframe load events but like everything in client-side JS, it's all gone when you reload the page.
Newer browsers have working file access objects that aren't total security nightmares. These are new and non-standard enough that it would take some doing to make it work for multiple browsers. This could be used to save files containing info that the user would probably have to be prompted to upload when they return to the site.
If the data's not sensitive you could get creative and use another service to stash collections of data. Use a twitter API to tweet data to some publicly visible page of a twitter account (check the Terms of Service if you're doing anything more than an isolated class project here). Then do an Ajax get request on whatever URL it's publicly visible at and parse the HTML for your twitter data.
Other stuff I'd look into: dataURIs, html5 local storage.
Note: None of these are approaches I would seriously consider for a professional site where the data was expected to be persistent or in any way secure regardless of where a user accesses it from.