I have a couple of questions on use of localStorage in Chrome extensions.
Is the 5mb storage limit per extension?
Does Chrome use the extension ID to monitor whether an extension conforms to this limit?
In short: Yes and Yes.
localStorage is tied to an origin w3 spec: The localStorage attribute, usually the protocol and host part of a resource's URL.
The origin of a Chrome extension is chrome-extension://EXTENSIONIDHERE, which implies that the extensionID of a Chrome extension is indeed used to enforce the per-origin storage limits.
You can find a proof of this by visiting your profile directory, and looking in the Default/Local Storage directory, which contains several (SQLite) files of the following format:
chrome-extension_EXTENSIONIDHERE_0.localstorage
chrome-extension_EXTENSIONIDHERE_0.localstorage-journal
Extension's localStorage is similar to website's localStorage so I guess it'd be 5mb. You can also consider using chrome.storage
Extension id is the only unique thing to every extension so chrome must use this to conform to this limit.
Related
I have a browser extension which POSTs to a server. I want to whitelist the extension's origin in my server. For instance, requests for the Chrome extension originate from a location like: chrome-extension://fjhbdidbplpijoncnlfoadfadfasdf and from Firefox like: moz-extension://cadf4351-e4f3-ca4d-b974-812309843dafd
I realize that I can whitelist those particular addresses on my server, but I'm not sure if they're static addresses. Do these randomly generated locations ever change, like if I ever submit an update? Is there anyway to set them permanently?
Do those change?
Situation differs for Chrome and Firefox.
Chrome
For released extensions that are on the Web Store, the ID is fixed. You can rely on it.
For unpacked extensions in development, the ID is determined either by the "key" value in the manifest, if present, or the absolute path to the extension folder. So it may change if you move the extension about. But you can "pin" it by providing a valid "key".
Firefox
What you see in Mozilla is an installation-specific origin. No matter what the extension's ID is, the UUID you see here will differ on each extension install (but should persist through updates).
There's some discussion of the mechanism in this bug.
Essentially, this is an anti-extension-blocking technique.
This means you can't whitelist just one origin and be done with it, unfortunately.
Is it a good idea to rely on this?
Probably not. While browsers tend to report Origin faithfully, other tools capable of generating requests don't follow that. So it would be relatively easy to spoof.
So, I am working on a project(building a chrome extension) that requires data to be stored on the local machine of the user. The size of data is quite large hence I thought of using IndexDB for this purpose.
My Question is whether is it possible to connect a chrome extension with IndexDB and query the database at the same time??
If Yes, Then how can I integrate them. In which file(popup.js or background.js or any other file) should I include the source code for creating the database.
I want the code for creating the database to run only once. After that I only want to update or delete data only.
If No, then is there any other way to achieve this?? The data is large hence I cannot store data in local storage.
Any paper, online material, advice or method from chrome developers or any other valid site would be helpful. Any example would help me alot.
Thankyou.
You can store tons of data in any HTML5 storage (including IndexedDB or localStorage) and chrome.storage.local with "unlimitedStorage" permission.
HTML5 data is stored per URL origin and each extension has its own one that looks like chrome-extension://id where id is a 32-character string that is the extension's id. In Firefox the origin looks like moz-extension://id.
Extension's own HTML5 storage:
can be accessed in any extension page (popup, options, background) just like you would do it in a web page, there are no differences.
cannot be accessed in a content script as it runs in a web page and thus can only access HTML5 storage of the web page's URL origin.
chrome.storage.local can be accessed in any extension page and in a content script.
No need for special event to create/upgrade your IndexedDB storage - it'll happen automatically if needed - simply open it as shown in the documentation whenever you need to access it and your onupgradeneeded callback will be invoked in case there was no DB or it was outdated.
Use a wrapper library for IndexedDB that provides a simplified syntax. Some are listed in the documentation, but you can probably find better ones yourself.
Is there any way to add a time delay to a script/asset loading in the Google Chrome Browser via the Chrome Developer Tools? Or to block a script loading entirely?
The reason I want to do this is to see how a site performs when a script/asset suffers from delayed loading or failed loading.
In Chrome Developer Tools when you are in the Network you can add custom throttling. You can specify download and upload speed as well as request latency. But this will apply to all resources and not only to a specific one.
--- edit ---
For delay individual URLs on any page, you can use a chrome extension (since it can intercept browser requests). I use https://chrome.google.com/webstore/detail/url-throttler/kpkeghonflnkockcnaegmphgdldfnden
If the asset is a third party or hosted on a different domain, there is a Chrome plugin that's designed to test what you are calling loading delays, that are also called SPOF (Single Point Of Failure). It might not be very intuitive at first use, but it's very helpful :
The plugin is called SPOF-O-Matic and can be found here: https://chrome.google.com/webstore/detail/spof-o-matic/plikhggfbplemddobondkeogomgoodeg
Following solutions have nothing with Chrome Devtools but they work.
If you don't mind redirects then you can try Slowwly or deelay.me.
Other alternative for non-windows OS is Comcast.
You can do it by combining multiple resources.
I use http://www.deelay.me/ to generate the delayed url.
I then combine it with requestly extension (https://requestly.io/) to create a host replace rule to target a specific resource
This devtools extension can fit your requirement, Its a Chrome/Firefox devtools extension that can simulate http request delay for any configurable URL.
Chrome devtools extension webstore
You can use Requestly Browser Extension or Desktop App to modify your network requests. Delaying/Throttling scripts is one of the use-cases amongst many already supported in Requestly.
Here's how you can do it. Once you install Requestly, Use the Delay Request feature.
Create New Rule & Select Delay Rule Type
Define URL (or URL Pattern) and the delay value
This article explains 3 different approaches to add delay/throttle APIs (or network requests). However, in your case Requestly extension based approach should work best.
PS - I built Requestly.
I've developed an iPad web app that uses the appcache. It's not intended to be a fully offline app but I use the appcache to store large image files so that they're not sent over 3G. Problem is when the manifest is updated the appcache updates whether the iPad is on wifi or 3G, which could be expensive.
Is it possible to have the user decide if the appcache can be updated or not? From what I've seen, this isn't possible, it all happens automatically, you just get events. But perhaps there's some trickery like writing the manifest on the fly or similar.
Using PHP on the server side if that helps. Thanks.
Connection Type: Theory & Future
There is a draft spec of Network Information API on W3C that provides the information of the connection type (ethernet wifi 2g 3g 4g etc.), but it hasn't been implemented on any browser yet apart from:
the stock Android browser on Android 2.2+ (not the Google Chrome browser)
navigator.connection.type // Based on W3C draft, (Implemented on stock Android browser)
and PhoneGap which is not exactly a browser
navigator.network.connection.type // on PhoneGap
Having that information in the future you could detect if the user has cellular data, then temporarily remove the src of the images and ask the user through a confirmation dialog.
You will also probably have to cancel the app cache update using:
window.applicationCache.abort() (documentation)
Reality
Unfortunately, the Net Info API is not available (at least not widespread) at the moment, but certainly will help in the future.
Long shot
There is a database that includes network speed (DIAL = dial up, DSL = broadband/cable, COMP = company/T1), but I haven't used it and I doubt it will help.
Dynamic App Cache
While checking into this, I tried to generate the html tag along with the manifest declaration on the fly, in order to combine it with the Network Info API but the AppCache manifest is loaded before javascript execution and is not affected afterwards.
So altering the manifest file on the fly through Javascript is not possible and data URI is not an option.
Alternative solution
HTML5 application cache is an untamed beast at the moment and there are talks to improve it. Until it changes to support more complex configurations (bandwidth level flag would be awesome), you could change perspective on the solution, although App Cache may be the best you have at the moment.
Depending on how big your images are you could rely on the normal browser cache. You could combine localStorage and far-future expiration HTTP headers. LocalStorage in order to keep track of the loaded/cached images.
First add a far in the future date for expiration on your images HTTP headers
On page load, remove all src from imgs
Loop the images and check localStorage if each image was loaded in the past
If there are images that were not loaded in the past, display a dialog confirming for the downloading of those images
If the image was loaded in the past, then put back the src on the img
For every image that is downloaded, save its URL on localStorage
I don't know what the status of indexedDB is on the iPad, but this could be an alternative solution.
In short: Indexeddb is a clientside database. Data is stored in object stores which are key/value pairs. The maximum storage capacity is in theory the maximum of your disk space. For more information about indexeddb:
Specification
My blog
What you could do with the indexeddb:
When someone navigates to a page:
Check every image tag if it is present in the indexeddb
if present
Get the image from the indexeddb and put it in the image tag
if not present
Download it
store it in the indexeddb
put the image in the image tag.
As extra (in the future) you can do as discribed by Sev: check the connetion type and only download the image when working on a fast internet connection.
I have 'invented' a working solution developing a webapp on the iPad (iOS 6.0.x) that may answer your question.
The idea is first to check if a localstorage variable is set/defined or not yet (I use the title of the page, thus the webapp name.)
If this localstorage variable exists, then assume (in webapp sandbox context) that its the first time the app is being run. At this point I populate a UUID in conjunction with $PHP_SESSION($uuid) to avoid 'cross app contamination' in server-side PHP land.
In addition to this I have a dynamic manifest.appcache.php which includes in the CACHE section a list of files to add to the manifest. Thus;
<?
echo $manifest_file_list[0]."\n";
?>
Using the JS appcache manifest event listeners I then monitor the progress to something like $('#manifestappcache').html(result);
I have an HTML document with an associated appcache manifest. But now I want to get rid of offline application caching for a while.
If I remove mention of the manifest from the <html> tag, browsers that already have a cached version will continue to use that cached version.
If I update the appcache manifest, well, whatever, there is still an appcache.
What is the most sensible way to go about removing offline application caching? I suppose that I could just change the manifest to have no entries other than:
NETWORK:
*
Then it won't actually cache anything.
But surely there must be a way to get rid of the appcache and the manifest file altogether, no?
You simply need to remove the appcache manifest from your server. If the browser can't access the manifest file, it will stop caching your app and remove all cached data.
Some useful information from two sites:
If the manifest file itself can't be retrieved, the cache will ignored
and all cached data associated with it will be disregarded.
http://appcache.offline.technology/
Application caches can also become obsolete. If the manifest is
removed from the server, the browser removes all application caches
that use that manifest, then sends an "obsoleted" event to the
application cache object. Then the application cache's status is set
to OBSOLETE.
https://developer.mozilla.org/en/Offline_resources_in_Firefox
FOR anyone coming across this question and who've deleted the appcache manifest, deleted the browser's cache and removed the manifest from the server and the reference to it in the HTML: If this still did not cause your HTML document to load the update version in Google Chrome, you can go to chrome://appcache-internals/ in your browser and click REMOVE next to the manifest you wish to get rid of.
Manually delete app cache: Only for Chrome
Enter the follow URL in your chrome browser: chrome://appcache-internals/
There you will see a list of every application cache you have in storage with the possibility to remove any of them.
Reference
In modern Firefox you can manipulate the offline cache with Edit Preferences Advanced Network.
In windows it is now (v27.01) Tools Options Advanced Network