I'm working on a jQuery Mobile project at the moment and I was not happy with the way that jQM was handling errors from the server. Our application's error handling code sets the HTTP's status code to 500. We do this, because it makes it much easier to track problematic requests. The issue we were running into was that jQM wants to just display a "Error Loading Page" dialog whenever it detects a 500 status code.
In order case, our error pages are formatted for use with jQM, so we really wanted to display the error, just as if the page had successfully loaded. We could have returned a status code of 200, but we wanted to respond with the correct status code.
To work around this issue, jQM has a "pagecontainerloadfailed" event which it fires whenever a page fails to load. Unfortunately, it's not very clear on how to use this event to handle the request as a successful page load. You can use the event.preventDefault() to cancel the default behavior, but how do you handle it as a successful page load?
Well that took some digging, but I finally found a solution that appears to work really well:
// if an error occurs loading the page, the server will make sure we have a properly formatted document $(document).on("pagecontainerloadfailed", function(event, data) { // if the error response is formatted for jQM, it'll have a custom response header that flags to use the standard page handler if( data.xhr.getResponseHeader("X-jQueryMobile-HasLayout") === "true" ){ // let the framework know we're going to handle things. event.preventDefault(); // load the results as if they had succeeded $.mobile.pageContainer.data("mobilePagecontainer")._loadSuccess(data.absUrl, event, data.options, data.deferred)(data.xhr.responseText, "success", data.xhr); } });
What this code does is look for a custom response header of "X-jQueryMobile-HasLayout" and if it sees this header is true, will then stop the default behavior and load the page as if it detecting a 200 status code.
I decided to use a custom header to determine if I should run the code or not, because then any unexpected error that occurred outside our framework would still behave the way jQM acts by default. However, if our application error handler runs, we set the header to "true". This tells jQM that the resulting HTML should be in a format that jQM needs to render the page.
I ended up posting this basic solution in GitHub 6866 - Add documentation for presenting server generated error pages and Alexander Schmitz, a jQuery Foundation member, confirmed this is the basic approach they plan on implementing in the future.
While this shouldn't affect most users (and by and large is probably a good thing), I noticed that Firefox 29 started automatically aborting requests after 300 seconds if the server has responded. As a developer, I often have test scripts that can take a very long time to run to completion, so this change was causing me some issues running a script to validate some data.
The change appears to be with the network.http.response.timeout setting in the about:config menu. It appears this setting used to be undefined, but it now set to 300.
It appears setting the value to 0 will reset the behavior so that Firefox will no longer automatically abort requests. Once I made this change, my test script starting running successfully (it's final runtime was about 6 minutes.)
Anyway, I don't expect this to affect most people. I think the impact is going to be felt mostly by developers who might have unit tests that run via a browser or other test scripts which could take a very long time to run.