Tuesday, October 16, 2012

Edit-Only and Revisiting Appcache

‹prev | My Chain | next›

During the recent Gaming JavaScript hackathon, I mentioned to the kids that they should limit the number of faces on shapes so that the computer does not have to work too hard, especially during animations. So what does my son do? He tries 5 million faces in one of his games.

Actually, I'm quite proud. He tried something stupid, which is the only real way to learn. In the process, he uncovered a bug that others will undoubtedly run into as well—if a game overwhelms the computer, then there is no way to correct the problem. Since the editor and the preview are in the same browser window / tab, the programmer has effectively denied him/herself access to correct the situation.

This turns out to be much easier than I had expected. If the programmer appends ?edit-only (or even ?e) to the code-editor, then I want edit-only mode. It take a moment to find (because I never remember) that JavaScript calls the query string as the "search" property of the window's location:
var EDIT_ONLY = window.location.search.indexOf('?e') > -1;
With that, all that I need do is add a guard clause to the update() function of the code-editor:
var update = function () {
  if (EDIT_ONLY) return;
  // Update the preview frame...
In edit-only mode, I increase the number of sides in one of the games to 2 million. This is auto-saved by the code-editor, so I then remove the ?edit-only query string from the URL and am greeted by a laptop that quickly grows very hot, but does very little else. After killing the offending tab, I reenter ?edit-only mode, fix the problem, and am again able to view the preview frame back in normal mode.

With that, I am ready to deploy. I had a spot of trouble the last time that I deployed my appcache editor—changes did not seem to get applied. I am using the swapcache scheme from HTML5 Rocks to load in new versions of the code-editor. The alert dialog saying that "A new version of this site is available. Load it?" would display, but then the older version of the code-editor remained in place.

I start by updating the editor.appcache manifest with today's date:
# 2012-10-16

That change, even though it is a only a comment change, is enough for the browser to see a different manifest, and reload the page. And, after deploying the changed page, I see the HTML5 Rocks confirmation alert:

And all of my changes seem to be in place. Specifically, I can enter into the edit-only mode with a ?edit-only query string. So whatever the problem was in the previous deployment, it seems fixed now. I hate that.

I try various ways to break the loading again: I remove the /code-editor/ from the manifest (it is no longer needed), I update the master page (the one that links the manifest), I update the various JavaScript libraries. All to no avail—I cannot get the deployed manifest to fail. Newly updated files are always updated in the appcache.

Bah! I will file this away for later investigation. I do not believe that I have solved this. I know that I saw this behavior on both my machine and my son's. In both cases, the only was to resolve was to manually remove the appcache. But, for now, I honestly cannot think of another way to attempt to break this.

Day #541

No comments:

Post a Comment