How to test IndexedDB 'QuotaExceededError' without filling disk? - javascript

I want to make sure my code handles the QuotaExceededError with IndexedDB properly, I'd prefer not torturing my SSD to do so.
Is there any way to set a storage limit (like to say 5 MB) in the developer tools or browser settings?

In Chrome, you can launch the browser with --user-data-dir pointing at a smaller volume, e.g. via tmpfs.
Chrome doesn't have devtools support for such testing, but it's on the wish list.

As of today you can open DevTools, go to the Application Panel and check the Simulate custom storage quota label and then provide the maximum amount of MB that can be stored by IndexedDB.
Chrome DevTools Application Panel Screeshot

I've used a VM with a small hard drive. That's not ideal obviously, so I hope someone suggests a better answer!

Building on #joshua-bell's answer but adding detail on exactly how to do this in Mac OSX:
Copy the mount-ram.sh file at https://gist.github.com/koshigoe/822455 (you will probably want the unmount-ram.sh file for later as well)
Save that file anywhere you want
From the directory where you saved mount-ram.sh, run sh mount-ram.sh mytmpfs 512
cd /Applications/Google Chrome.app/Contents/MacOS (at least that's where it was on my machine)
./Google\ Chrome --user-data-dir=/PATH/TO/mytmpfs/, replacing /PATH/TO/mytmpfs/ with the path the directory you created in step 3.
Now you've got Chrome running, pointed at a file system with only 512MB of storage.

If you're ok with a 100MB storage limit, just open Chrome in incognito mode.
To see how much storage you have left, try this:
navigator.storage.estimate().then(console.log)

Related

Allocate browser memory for IndexedDB connection open issues

The Setup:
Hello, my org has built an Angular PWA for our users to work offline in the field on their corporate Surface Go devices. This PWA needs to review and edit various data while users are disconnected, so we researched and settled on working with the IndexedDB (Idb) in the browser. Users have the ability to download various files, PDFs, and images while in the office, go offline and into the field, capture new photos within the app (Idb), and upload this all back to our servers upon return.
We store large JSON and blob objects in the Idb to keep track of everything and users have a good workflow to follow for downloading, fielding, and uploading. We also keep a close watch on the Storage within the browser to ensure the Surfaces do meet the limits.
The PWA is loaded in MS Edge (Version 96.0.1054.62 (Official build) (64-bit)) on Windows and the PWA is installed onto their desktop to function like a native app. The Surfaces have 8GB of RAM and plenty of hard drive space for storage.
The Problem:
This has all worked great for a few months but users have now started experiencing issues with the PWA crashing upon navigating to our app. The browser is opened, navigate to the URL, the app loads for 2-3 seconds, and then the entire browser crashes (all tabs and windows). Users have reported uploading and storing photos (3MB each) when the first crash happens. Users are then out of commission and can no longer access the app by any means, so there defiantly seems like a tipping point somewhere.
We have narrowed it down to a memory (RAM) issue with the browser. When the app starts up and establishes a connection to the Idb, the memory spikes dramatically based on the amount of data stored within it. Looking at the local File System in Windows the users that have been affected have upwards of 4.5GB+ stored in their Idb (this is everything).
Loading the browser .exe into Visual Studio and navigating to the app we can see the result. As soon as the call the indexeddb.open happens, a spike in memory is shown.
Chrome (in this instance) throws memory errors.
We have also tried to increase the amount of memory available to the browser by following these posts with no difference. We have been able to copy out the Idb files from the affected users (C:\Users{user}\AppData\Local\Microsoft\Edge\User Data\Default\IndexedDB), swapped them into our machines, and been able to reproduce the crashing locally.
System memory shows the same spike, but there is obviously a lot more memory to give.
As it stands, our users are dead in the water and unable to open the app and unable to access their data. The raw Idb files are unreadable and every solution we have taken to extract the data (https://github.com/amyboyd/indexeddb-to-json) just fails in the same way.
Questions:
Can we allocate more memory to the browser through some other means?
Can we extract the data from the Idb without the browser?
Can we avoid the memory issues when opening the Idb some other way?
OK, so months later we were able to implement a different approach that goes around the IndexedDB and uses the File System API. This has its own drawbacks but this fixed all my issues by getting raw files out of the IndexedDB.
Related to the IndexedDB itself, we found some very specific issues around the images we were storing there, as they were all being base64 encoded and stored as strings. It seems that when the IndexedDB stores these large strings (3-4MB) it has to decode them when it wakes up to correctly render them on demand at a later time.
Based on the number of large strings it has to do this for when making the initial connection to the database, it causes a huge memory spike (decoding hundreds of base64 strings) and ultimately crashes the browser as the IndexedDB and browser engine just completely crashes.
We were not able to dig too deep into how and what the IndexedDB does under the covers as some proprietary magic from the creators at Google? I'm hoping someone with more knowledge on standards at the WWWC can chime and provide more data on this. I would love to know how it works under the covers and why we can't access the raw data on the file system.
TLDR; Don't store large base64 encoded strings in the IndexedDB.

safari loads css/js very slow on client certificate SSL website

I have a website where I use client certificates for accessing the site and it runs with SSL required. It runs on IIS 8.5 on a windows server 2012 R2.
All my css and javascript is minified into 4 seperate files
app.js -> Our own javascript
app.css -> Our own css
vendor.js -> External javascript libraries
vendor.css -> External css libraries
All of these files are minified and placed locally on the server.
The site works very well when using chrome or IE from a computer, but when using safari (only tried safari 5 on PC and latest safari on iphone 6/7) the page can stuck in a "loading" mode. The does not happend every time, and when it does it often helps with clearing the cache in safari and try again.
The website also uses local storage to save some userdata, and a cookie that stores a token for authentication. Not sure if this is useful information, just throwing it out there.
It can connect to the webserver, since we can see the EV+ certificate.
When debugging the phone on a mac, or safari on a PC and looking at the network tab in the developer window I can see that sometimes it takes really long time for the browser to load some of the css and/or javascript files.
Sometimes it appears to be vendor.js, and sometimes app.css, and sometimes the other ones. There seems to be no logic to me, that its always the same files etc.
The site is .NET 4.6 site, running with angularjs, signalr 2.2.1 and html5 in the front.
We have tried
Monotoring IIS Logs and network traffic
Remove sourcemap on css/js to reduce file size
Tried reference signalr/hubs (the generated js file). And also tried copying the content into vendor.js so there is a local version instead
Without any success ATM. I would really appreciate help, feeling stuck on this one.
Many Thanks!
It may be dynamic compression. Are you using Brotli compression on the server?
I suggest a detailed analysis of HTTP Request and Response headers. There may be a discrepancy resulting in this unexpected behaviour. I would follow this up with scouring the Safari bug tracker.
The SSL certificate itself may be the issue, or rather Safari's interpretation of policies.
Hope it helps.

Visual Studio 2013 caching older version of .js file

I am working on a small web api project in Visual Studio 2013 Ultimate. Windows 2013. Internet Explorer 9. When I run (debug) from VS using the internal web server (I guess that is IIS Express, now), I am finding that the changes I am making (and saving) to a javascript page are being ignored. Placing a breakpoint in the javascript shows the older code without my changes.
CTRL+F5 does not force the application to use the currently updated page. Checking the page in, then checking it back out often works. Is there some setting or trick that will help me out here?
Clearing the cache history seemed a bit excessive and I don't want to do that all the time.
The following solution worked me in Internet Explorer:
First enable script debugging:
Tools menu -> select Internet Options
On advance tab uncheck "Disable script debugging (Internet Explorer)"
Then make sure you get the newest page:
From the Tools menu choose Internet Options.
On the General tab, under Browsing history, click Settings.
Under "Check for newer versions of stored pages" make sure "Every time I visit the webpage" is selected.
Click the OK button.
If somebody has this problem and ctrl+F5, clearing browser's cache, restarting debugging, changing browser, changing web.config and rebuilding project don't help, then there is one last thing that works (at least for me): restart Visual Studio.
Also changing debugging port on local IIS Express helps but this is far more painful if working in a team or using Azure Active Directory etc.
Only solution that worked for me was changing the javascript file name and updating the bundle configuration to point at the new file. I tried everything else from restarting my pc, deleting bin/obj/cache/etc, CTRL F5, restart IIS, and so on.
If I'm correct you should build (ctrl+shift+b) your project before debugging. This web server runs in the background on a port of choosing whenever you start in debug mode. You can close the task(s) (process bar next to your clock) if you need a new session or press F5 in VS.
You can avoid using the built in web server if you have IIS (Express) or something similar.
Go to RUN and type iis depending on your OS it's already installed. Otherwise try to install it in Control Panel > Programs or Features > Turn windows features on or off
add a website (site name, path, hostname)
add to your host file 127.0.0.1 hostname (c:\windows\system32\drivers\etc\hosts)
To debug your project in Visual Studio:
open your website on your hostname in your favourite browser
click on DEBUG
click on ATTACH TO PROCESS
find w3wp.exe
hit ctrl+f5 in your browser to start debugging server code
Depending on how your solution/project is setup, you can publish your project files directly to IIS if you choose to publish to File System. Right mouse click on your project and choose publish. Set it up from there.
If your Visual Studio is up-to-date you can publish single files with alt+$+p.
Hope it helps.
Locate the code section where the JavaScript file is loaded to the page and add a parameter string to the end for testing. For example:
Change src="../Resources/js/MyScriptFile.js"
To src="../Resources/js/MyScriptFile.js?v=23"
Every time you update your JavaScript file, you change the version number. This will force the browser to load your new version of JavaScript file. After you finished testing, You can remove the string "?v=23". The bonus, if you leave it there, the end user will not be required to refresh his/her browser cache after you deployed your code to production.
I keep getting this problem very often. Normally what I do is first get into the drive where the OS is installed (In my case C:), and delete all the application.dll and application.pdb (it is stored in Windows\Microsoft.net\Framework\vx.x.xxxxx\Temporary ASP.NET Files). Delete application.dll and application.pdb in the users\xxx. Get into the application directory and again delete application.dll and application.pdb. Clear the browser cache. Restart the system (cold restart). Build the application. Most of time found to be working.
Note: I use DOS prompt for deleting since I'm quite used to it. But the user should have admin privileges. It's not a perfect solution but it works.
What worked for me was
Shutdown Visual Studio 2013 update 2 (I have win 8.1 all 64 bit)
Delete clear out "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files"
Cleaned and Rebuilt solution
Restart IIS Express. If using IIS just re start app and pool.
Run in VS 2013 Debug (F5) it still loads the old file under Script Documents > Windows Internet Explorer > Page_Name.aspx
Then F12 Developer tools clear Browser Cache (IE), I have the same issue in Chrome
F5 in browser reload the page finally loads the changed JS script file with my debugger; entry and breakpoints set
So i had the same problem and i could avoid this by canceling the .ASP.NET-Server
.ASP.NET-Server from Visual Studio for debugging
from Visual Studio and restarting the debugging. Hope this helps someone.
I restarted Visual Studio and rebuilt the project, but the problem persisted for me -- the debugger continued to run an old copy of the .js file. The solution for me was to simply reboot the machine. (When all else fails...)
For reference, I'm currently using Visual Studio 2015.

Firebug like debugging on Android

I have seen several posts that talk about remote debugging of javascript code on Android, but they all miss the point of what I am trying to do.
I have a Nexus 7 and I want to use it as a remote development environment when I am away from my desktop. I have created a chrooted debian distribution to run apache and php and git (via ssh). This chrooted environment mounts a subdirectory of the /sdcard directory from outside the chroot environement. Apache document root of a virtual host is pointing at a directory within this. Before leaving the desktop I can git push the latest release to the tablet. When I return git pull can get what I have done back again.
I then (when away from home and NOT connected to any network) can edit the code using an Android editor (using the 920 text editor), but then run the browser to look at what I have developed using localhost the apache virtual host picks this up and displays it.
The application I am developing IS NOT FOR ANDROID - it is ultimately for the desktop. But I want to be able to debug it like I was on the desktop. Breakpoints and single stepping are the prime thing, but also I tend to use the html section in firebug to adjust my CSS before editing it.
Is there a way to get either the chrome developer tools or firebug add on for firefox to load into a browser that will run in android?
I use Firebug lite bookmarklet for iPhone and iPad, never tried on Android, check this out http://martinkool.com/post/13629963755/firebug-on-ipad-and-iphone it must be similar on Android.
To activate it use this steps:
Create a new bookmark or bookmark a page
Rename the bookmark to “Firebug”
Copy the textarea link:
javascript:(function(F,i,r,e,b,u,g,L,I,T,E){if(F.getElementById(b))return;E=F[i+'NS']&&F.documentElement.namespaceURI;E=E?Fi+'NS':Fi;Er;Er;Er;(Fe[0]||Fe[0]).appendChild(E);E=new%20Image;Er;})(document,'createElement','setAttribute','getElementsByTagName','FirebugLite','4','firebug-lite.js','releases/lite/latest/skin/xp/sprite.png','https://getfirebug.com/','#startOpened');
Edit the Firebug bookmarklet, remove the URL and paste the
bookmarklet
Choose “Done” (on the virtual keyboard) and you’re all set
Hitting that bookmarklet should give you a fully functioning Firebug at the bottom of your mobile device.
At least not for Firefox Mobile, because all the devtools are still partially based on XUL, where the Firefox Mobile is using Native UI.
I don't think there is any plan in the close future to change this situation; it's not a common scenario.
However, you should be able to do something using the Debugger API, creating an add-on for Firefox Mobile. But I don't know if it's worthy.

How to tell IE a HTML file on my disk is not a security risk?

Our build script creates a HTML log with some embedded javascript. When I open that in Internet Explorer, I get the yellow warning bar that IE has blocked running "scripts or activex controls".
Since it is a local file, I cannot add it to trusted sites (IE expects a domain here).
I do not want to change security settings for the default zone.
Any idea how to permanently unblock it?
IE version is 7.0.5730.13 on XP Pro.
Embed the Mark of the Web:
<!-- saved from url=(0016)http://localhost -->
You could add The Mark of the Web to the document so that IE will act as if it's from a certain security zone.
Probably not what you want to hear but I'm not sure you can. Does Firefox/Opera/Safari complain when you run it in any of those? If it works then that seems like the simplest solution to me.
You can add Local Machine Zone and configure security for it:
http://www.microsoft.com/windows/IE/community/columns/improvements.mspx
You can always enable ActiveX. I've tested this on Internet Explorer 11, but should work on earlier version of IE:
Tools > Internet Options > Advanced > Security :
(✓) Allow active content from CDs to run on My Computer
(✓) Allow active content to run in files on My Computer
You could set up a local server and save such files in a domain you can now add to the trusted sites, but opening the file in any other browser than IE is easier.
Another option, if it's only IE you need to view it in is to save it as a .hta file.
This makes it a HTML application.
It's as simple as changing the suffix to .hta. Although there are other options you can specify.
For more info:
http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx

Categories