I've got a local instance of browser-solidity running with a bunch of .sol files open. Does anyone know where those source files are stored (on Mac OSX)? I can't find them anywhere.
Browser-solidity stores the .sol files in the browser's local storage.
If you would like to view them you can view them:
Chrome via Developer tools > Application > Storage > Local storage
Firefox via Tools > Web Developer > Storage Inspector (You may need to enable the storage tool in Firefox's Developer Settings)
Related
For some reason Google Chrome Local Storage sub-tab located within Developer Tools -> Application -> Storage tab doesn't display data. When I enter localStorage in console, then local storage data is printed out. Please advise what might be an issue with my Chrome settings.
It is a known bug that has been reported here:
https://bugs.chromium.org/p/chromium/issues/detail?id=701413
As a work around (until the bug is fixed) you can close & reopen Developer Tools after a page refresh - Local Storage should be visible in the Application tab on initial open of dev tools.
In Chrome Dev tools, I am no longer able to map a localhost network file to the local source file for saving changes to disk. The problem occurs when I click on Map to file system resource.... It does not populate the next screen with local file choices as it used to. Any help or hints are much appreciated.
You should delete the "?ver=4.7.2" - these are query parameters which confuse the search for local files.
I am developing a chrome extension which needs to fetch some configuration from a system file... Earlier chrome provided NPAPI plug-ins, which could access any system resource (win registry, file system, IPC calls etc...)
However knowing that NPAPI will be discontinued soon, i am looking for alternatives.. one of the ways to build a plug-in is using Pepper clients, but pepper clients read/write only to chrome local storage.. which looks like a more data version of cookies...
So is there any other alternative to access system resources (like registry, files etc) in chrome extensions now??
The suggested alternative to NPAPI for many cases is "Native Messaging", where you provide an installer to users which adds binary code that chrome can communicate with via message passing. See http://developer.chrome.com/extensions/messaging.html#native-messaging.
For file access, in packaged apps there is the fileSystem API that lets you get access to the actual (non-sandboxed) filesystem. See http://developer.chrome.com/apps/fileSystem.html.
If I write a web app that will run in Chrome or Firefox and uses IndexedDB (or localStorage), but it's not hosted anywhere and instead is run by the user double-clicking a local ".html" file, will the limits on storage size still apply?
I'm referring to this:
https://developers.google.com/chrome/whitepapers/storage#unlimited
[Unlimited Storage is] unique to Chrome extensions as well as hosted and installed web apps.
If it is not hosted, indexeddb won't work. The indexeddb is origin dependend, meaning it needs to have an address. Local file system doesn't meet that requirement.
Webapps are a different story, but these apps need to be installed and run inside a sandbox.
I'm writing a Google Chrome app that stores things locally with the HTML5 FileSystem API. Is there any way to use Windows Explorer to get to the directory where Chrome stores these files or is it entirely virtual and inaccessible from outside the app? I haven't been able to find the directory by poking around nor have I seen any reference online to it.
I suppose I could just write something within the app to allow me GUI management of the files my app stores or just use the developer console, but it would really be a time saver to use WE.
Nevermind, I just found it. For anyone looking, it's in (on my windows 7 machine at least)
C:\Users\ user \AppData\Local\Google\Chrome\User Data\Default\File System
Also note that this was in Chrome 11, in Chrome 13 there were some changes to the FileSystem (probably for security) that make it very difficult to find specific files by scrolling through the files in Chrome's AppData space.