I'm building a mobile web app that will rely on caching.
If my cache uses to much memory I'm seeing this message in mobile Safari...
"A problem occurred with this webpage so it was reloaded".
Without intervention the page will reload and do the same thing over again a few times until it gives up.
Are there events I can capture, heap information I can monitor or settings that I can change to build a caching system that is more resilient than forcing page reloads?
Chrome has window.performace.memory but I can't seem to find anything related to solving my issue in mobile Safari. Try/catch statements and onBeforeUnload events don't prevent the page loads or provide an opportunity to clear/reduce the cache.
Does this help ?
Error handling "Out of Memory Exception" in browser?
var localStorageSpace = function(){
var allStrings = '';
for(var key in window.localStorage){
if(window.localStorage.hasOwnProperty(key)){
allStrings += window.localStorage[key];
}
}
return allStrings ? 3 + ((allStrings.length*16)/(8*1024)) + ' KB' : 'Empty (0 KB)';
};
var storageIsFull = function () {
var size = localStorageSpace(); // old size
// try to add data
var er;
try {
window.localStorage.setItem("test-size", "1");
} catch(er) {}
// check if data added
var isFull = (size === localStorageSpace());
window.localStorage.removeItem("test-size");
return isFull;
}
Related
Chrome's Dev Tools are great for debugging web workers as I can "browse" into that JavaScript environment and set break points. Even the console works as expected.
On Safari, it is a completely different story. console.log from the web worker doesn't even print in the console. I see the worker script loaded and I put a break point on it, but it doesn't break. I don't even see the scripts that were loaded with importScripts.
How can I use Safari's Web Inspector to troubleshoot problems?
Not that I think it matters, but I'm using Safari 8.
Insert the debugger; code in your source
Usage: Insert it anywhere you want to add a breakpoint and when developer console is open automatically execution will pause at that line
var a = 50;
a = a + 5;
debugger; //--> execution is paused here
a = a - 5;
For more info see the Debugger Documentation on mozilla.org
In lieu of console.log, you can use postMessage. postMessage should allow you to send debug messages to the safari console.
Here is a great example on how to do that, I pasted the main idea below:
//
// In the Main thread
//
var worker = new Worker('/path/of/webworker/code.js')
worker.onmessage = function (e) {
var result = JSON.parse(e.data);
if(result.type == 'debug') {
console.log(result.msg);
} else if(result.type == 'response') {
// ... use result.answer ...
}
}
//
// In the WebWorker
//
function debug(msg) {
postMessage(JSON.stringify({type:'debug',msg:msg}));
}
onmessage = function (e) {
var inputData = e.data;
// work on input data
debug('Working OK');
// work some more
// ...
postMessage(JSON.stringify({type:'response', answer:42}));
};
If you don't want to play around with postMessage though, David Flanagan made a wrapper for it here that should allow you to at least do debugging with console.log
I am debugging a javascript/html5 web app that uses a lot of memory. Occasionally I get an error message in the console window saying
"uncaught exception: out of memory".
Is there a way for me to gracefully handle this error inside the app?
Ultimately I need to re-write parts of this to prevent this from happening in the first place.
You should calclulate size of your localStorage,
window.localStorage is full
as a solution is to try to add something
var localStorageSpace = function(){
var allStrings = '';
for(var key in window.localStorage){
if(window.localStorage.hasOwnProperty(key)){
allStrings += window.localStorage[key];
}
}
return allStrings ? 3 + ((allStrings.length*16)/(8*1024)) + ' KB' : 'Empty (0 KB)';
};
var storageIsFull = function () {
var size = localStorageSpace(); // old size
// try to add data
var er;
try {
window.localStorage.setItem("test-size", "1");
} catch(er) {}
// check if data added
var isFull = (size === localStorageSpace());
window.localStorage.removeItem("test-size");
return isFull;
}
I also got the same error message recently when working on a project having lots of JS and sending Json, but the solution which I found was to update input type="submit" attribute to input type="button". I know there are limitations of using input type="button"..> and the solution looks weird, but if your application has ajax with JS,Json data, you can give it a try. Thanks.
Faced the same problem in Firefox then later I came to know I was trying to reload a HTML page even before setting up some data into local-storage inside if loop. So you need to take care of that one and also check somewhere ID is repeating or not.
But same thing was working great in Chrome. Maybe Chrome is more Intelligent.
I have a weird problem with this code. Basically I am loading a new ActiveXObject ("InternetExplorer.Application") and putting a reference to it onto the IE window object. I then load up an HTML file and wait for it to finish loading before trying to run script against the new window. When I launch IE via VS2010 with or without debugging (i.e. F5 or CTRL-F5) this code works and I get a reference to lDebugWindow.document.documentElement object.
The problem -- But when I just launch IE from the WIN7 taskbar, lDebugWindow.document is always undefined. Any ideas what is different about IE when launched from VS2010 versus the taskbar? Here is the code with the line highlighted that behaves differently from VS2010 vs. taskbar launch of IE:
function wfDebugXml(pNode)
{
window.lDebugWindow = new ActiveXObject("InternetExplorer.Application");
lDebugWindow.navigate(sFrameworkBase + "/GlobalDebugger/Debug.htm");
lReady = false;
for (var i = 0; i < 40; i++)
{
if (!lReady)
{
try
{
lDebugWindow.onreadystatechange = wfDebugRenderXml(pNode);
}
catch (e) { };
}
}
}
function wfDebugRenderXml(pNode)
{
// THE NEXT LINE IS THE ONE THAT HAS THE PROBLEM
var lDocumentElement = lDebugWindow.document.documentElement;
var lXsltDoc = Sarissa.getDomDocument();
lXsltDoc.async = false;
lXsltDoc.load("GlobalDebugger/Debug.xsl");
var lXslt = new XSLTProcessor();
lXslt.importStylesheet(lXsltDoc);
var lXmlDoc = Sarissa.getDomDocument();
lXmlDoc.loadXML(pNode.xml);
var lXmlOutput = lXslt.transformToFragment(lXmlDoc, lDebugWindow.document);
while (lDocumentElement.childNodes.length > 0)
{
lDocumentElement.removeChild(lDocumentElement.lastChild);
}
lDocumentElement.appendChild(lXmlOutput);
lDebugWindow.Visible = true;
}
I suppose your problem is gone now. For anyone else, it might be a right access issue :
Under Win7 IE runs in a low integrity processus. I suppose it might not be possible to get COM pointers between processus with different levels of integrity.
I used ChangeWindowMessageFilter to fix my issue but I was communicating via messages. It might be a good point to start Googling though.
I have configured PHP to send me mails whenever there is an error. I would like to do the same with Javascript.
Also given the fact that this will be client side it is open to abuse.
What are good ways to get notified by mail when JS breaks in a web application?
Update:
Just to give some perspective, i usually load several js files including libraries (most of the time jQuery).
You can listen to the global onError event.
Note that you need to make sure it doesn't loop infinitely when it raises an error.
<script type="text/javascript">
var handlingError = false;
window.onerror = function() {
if(handlingError) return;
handlingError = true;
// process error
handlingError = false;
};
</script>
The code below relies on the global onError event, it does not require any external library and will work in any browser.
You should load it before any other script and make sure you have a server-side jserrorlogger.php script that picks up the error.
The code includes a very simple self-limiting mechanism: it will stop sending errors to the server after the 10th error. This comes in handy if your code gets stuck in a loop generating zillions of errors.
To avoid abuse you should include a similar self-limiting mechanism in your PHP code, for example by:
saving and updating a session variable with the error count and stop sending emails after X errors per session (while still writing them all down in your logs)
saving and updating a global variable with the errors-per-minute and stop sending emails when the threshold is exceeded
allowing only requests coming from authenticated users (applies only if your
application requires authentication)
you name it :)
Note that to better trace javascript errors you should wrap your relevant code in try/catch blocks and possibly use the printstacktrace function found here:
https://github.com/eriwen/javascript-stacktrace
<script type="text/javascript">
var globalOnError = (function() {
var logErrorCount = 0;
return function(err, url, line) {
logErrorCount++;
if (logErrorCount < 10) {
var msg = "";
if (typeof(err) === "object") {
if (err.message) {
// Extract data from webkit ErrorEvent object
url = err.filename;
line = err.lineno;
err = err.message;
} else {
// Handle strange cases where err is an object but not an ErrorEvent
buf = "";
for (var name in err) {
if (err.hasOwnProperty(name)) {
buf += name + "=" + err[name] + "&";
}
}
err = "(url encoded object): " + buf;
}
}
msg = "Unhandled exception ["+err+"] at line ["+line+"] url ["+url+"]";
var sc = document.createElement('script'); sc.type = 'text/javascript';
sc.src = 'jserrorlogger.php?msg='+encodeURIComponent(msg.substring(0, Math.min(800, msg.length)));
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(sc, s);
}
return false;
}
})();
window.onerror = globalOnError;
</script>
You would wrap your entire program in a try/catch and send caught exceptions over AJAX to the server where an email could be generated. Short of that (and I wouldn't do that) the answer is "not really."
JA Auide has the basic idea. You could also go somewhat in between, ie.:
Write an AJAX "errorNotify" function that sends error details to the server so that they can be emailed to you.
Wrap certain parts of your code (the chunks you expect might someday have issues) with a try/catch which invokes errorNotify in the catch block.
If you were truly concerned about having 0 errors whatsoever, you'd then be stuff with try/catching your whole app, but I think just try/catching the key blocks will give you 80% of the value for 20% of the effort.
Just a note from a person that logs JavaScript errors.
The info that comes from window.onerror is very generic. Makes debugging hard and you have no idea what caused it.
User's plugins can also cause the issue. A very common one in certain Firebug versions was toString().
You want to make sure that you do not flood your server with calls, limit the amount of errors that can be sent page per page load.
Make sure to log page url with the error call, grab any other information you can too to make your life easier to debug.
I'm writing a Firefox extension that creates a socket server which will output the active tab's URL when a client makes a connection to it. I have the following code in my javascript file:
var serverSocket;
function startServer()
{
var listener =
{
onSocketAccepted : function(socket, transport)
{
try {
var outputString = gBrowser.currentURI.spec + "\n";
var stream = transport.openOutputStream(0,0,0);
stream.write(outputString,outputString.length);
stream.close();
} catch(ex2){ dump("::"+ex2); }
},
onStopListening : function(socket, status){}
};
try {
serverSocket = Components.classes["#mozilla.org/network/server-socket;1"]
.createInstance(Components.interfaces.nsIServerSocket);
serverSocket.init(7055,true,-1);
serverSocket.asyncListen(listener);
} catch(ex){ dump(ex); }
document.getElementById("status").value = "Started";
}
function stopServer ()
{
if (serverSocket)
serverSocket.close();
}
window.addEventListener("load", function() { startServer(); }, false);
window.addEventListener("unload", function() { stopServer(); }, false);
As it is, it works for multiple tabs in a single window. If I open multiple windows, it ignores the additional windows. I think it is creating a server socket for each window, but since they are using the same port, the additional sockets fail to initialize. I need it to create a server socket when the browser launches and continue running when I close the windows (Mac OS X). As it is, when I close a window but Firefox remains running, the socket closes and I have to restart firefox to get it up an running. How do I go about that?
Firefox extension overlays bind to window objects. One way around this is to create an XPCOM component or find one that someone else already created to allow you to build functionality without binding it to the window objects.
Of course, section #2 below on Observer Notifications may be helpful as well.
Possible workaround: #1
Instead of calling "startServer()" each time a window is opened, you could have a flag called windowCount that you could increment each time you open a new window. If windowCount is greater than 0, don't call startServer().
As windows close, you could decrement the count. Once it hits 0, stop the server.
Here is information from the Mozilla forums on this problem:
http://forums.mozillazine.org/viewtopic.php?f=19&t=2030279
Possible workaround #2:
With that said, I've also found documentation for Observer Notifications, which may be helpful as there is a section on Application Startup and Shutdown:
https://developer.mozilla.org/en/Observer_Notifications
UPDATE:
Here are some resources on creating XPCOM components in JavaScript and in C++:
https://developer.mozilla.org/en/how_to_build_an_xpcom_component_in_javascript
http://www.codeproject.com/KB/miscctrl/XPCOM_Creation.aspx
https://developer.mozilla.org/en/creating_xpcom_components
You probably want to:
Move your code into a JavaScript component
Register your component as a profile-after-change observer
Whenever someone makes a connection to your socket, find the active window and return its URL.
Use something like
var wm = Components.classes["#mozilla.org/appshell/window-mediator;1"]
.getService(Components.interfaces.nsIWindowMediator);
var win = wm.getMostRecentWindow("navigator:browser");
var spec = win ? win.getBrowser().currentURI.spec : "";
var outputString = spec + "\n";
etc.