I'm writing a packaged app for Chrome. Is there an advantage to using the background page - instead of the app's main HTML page - to read/write the localStorage values?
Currently users seem to be losing data in ways I cannot duplicate. Right now the app reads and writes localStorage in the main HTML page's JavaScript. Would changing the app to use the background page's JavaScript fix this?
LocalStorage is limited to 5 megabytes, regardless of set permissions.
When users checks the "Delete cookies and other website and plugin data" on chrome://settings/clearBrowserData then I believe both site specific and extension localstorage files are deleted. Maybe this is how your users are "losing" data.
Using the background page to read/write to localstorage prevents corruption of your data from other extensions, which can happen for site domain localstorage files as only your background page can access the file.
While other extensions indeed can call your background page, they still have to use your save/load functions to access your extension localstorage file.
The problem might be with the context of the localStorage container. When run from the background script you are saving the the localStorage of your extension. When run from a content script you are saving to a localStorage are for that specific website. localStorage.setItem( 'xx', 'yyy' ) that is written by a content script on a google.com page can't be read by localStore.getItem( 'xx' ) call from a content script on yahoo.com
Related
I'm injecting an iFrame into a webpage using a Chrome Extension. The iFrame's source is another webpage that I built and it's just a basic To Do list that stores the To Dos in localstorage.
I'd like to be able to access these To Dos in Local Storage inside of my Chrome Extension (either inside a background script or a content script).
I'm slightly confused on how to do this though, since window.localStorage only gives me access to the page's localStorage.
If I check on chrome's console and look at LocalStorage on the Application Tab, I can see the To Dos from the iFrame's localStorage.
As you can see, on google.com, the xxxx.github.io tab is the localStorage for the app I built and there are the associated todos as values.
I'd like to be able to access that localStorage data in my chrome extension. But, whenever I use window.localStorage, I only get access to the "https://www.google.com" key,value pairs.
Is it possible to access the key,value pairs for other sites?
Thank you very much for your help.
You can solve this using the postMessage API.
Use window.parent.postMessage("message", "*") to send a message from the iFrame to the parent window.
Then, add a message Listener in your content script to listen for messages.
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)
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 trying to create an extension for Google Chrome overriding the "new tab" page, in which there is content in JavaScript. In the first tab, it runs correctly, but when new tabs are opened, the scripts don't work. What should I do for fixing it?
You can make an extension for Google Chrome. Chrome extensions require a manifest.json file to be included, and you can set overridable pages to bookmarks history or newtab. Like such:
"chrome_url_overrides" : {
"newtab": "index.html"
},
For more info about making Chrome extensions, read the docs.
I'm not sure what you mean by 'content in JavaScript'.
You can check out the code for my chrome extension, New Tab Redirect: https://github.com/jimschubert/newtab-redirect
The way I have it set up is that there is a redirect.html page which is used as the override page. On load, it checks for a user-specified url from the background/event page (background.js), then redirects to that url with a simple JavaScript redirect.
The master branch is v1.0 (background page) and the 2.0 branch uses an event page.
edit
To specifically answer why you might be having problems with your code, without seeing any actual code.. I assume you're doing the initialization of your script in a background page in very much the same way as in my extension and querying that data from the redirect page, where you're then getting/setting data in local storage.
If any of that data needs to change, you can't use local storage from your redirecting page. Instead, you need to send the data back to the background page and store options there. Think of your background page as a service and your redirecting page as a very thin, very stateless client.
Is there any client-side script that would be able to make changes to a file on the hosts computer? (Intention stated below)
I am creating a packaged app for chrome which can show some online data, and make it available even when offline.
There is a certain thing, for e.g. 'a webpage' i want to show/store (but i cannot get/read its contents due to it being on different origin). To show when online, i can use iframe, but am unable to preserve it for offline.
So i thought i could make an appcache (manifest within the application package) which will cache the file, and on press of an update button a script would run which would make some change to the manifest which would force the cached resource to be reloaded.
I searched a lot, but no results.
Any suggestions as to how it can be done. Or any other way to get it to work?
I don't think so. This could be a huge security problem if it existed.
If you had to, you could send an ajax request to the server to create a file it creates with the current prices, and add it to the appcache file.
Here is a link to another SO quesitob that has a list of APIs you could use to get your stock price.
Webservice to get stock quotes?