Monday, July 1, 2013

Debugging Dart Applications in FireFox

‹prev | My Chain | next›

I have a problem with the ICE Code Editor, but only in Firefox. When Firefox first loads the editor, the preview layer is not showing. Strangely, this works in IE and Chrome, but not Firefox.

Since ICE is written in Dart, I am at something of a loss to explain this—after all, the whole point of Dart is to smooth out the differences between browser implementations. Still, this may not be so much Dart as it is a problem with application cache (which is where it resides in beta) or even a deployment issue.

Before I jump to conclusions, I need to start somewhere. That somewhere is setting a breakpoint on the preview layer's update callback in Firefox:



I do like the capabilities and the feel of the debugging tools in the newer versions of Firefox (I am using 22 here). What I see is that, when I load the editor the preview layer callbacks are not, in fact being called. If I press the Update button, then the callback is invoked as expected.

So why isn't the preview layer being told to update? Looking through the code, I do not see any obvious explanation. The content of the editor is being set correctly to the most recent entry in localStorage. As far as I can tell, this should always result in the preview layer being notified. In fact, I have several tests that attest to this and Chrome and IE similarly seem to agree.

And yet it is not working.

My next step is to try a non-appcache version of the editor. That is fairly easy—I have a full screen version of the editor in the example sub-directory of the ICE project. And I find... that it loads just fine locally:



I am unsure if I can eliminate any particular cause given this success. What I do know is that Firefox is definitely capable of displaying the preview correctly, but something in the beta setup is preventing this from occurring.

My next step it so try this locally in appcache. I can do this with the GitHub pages version of http://gamingjs.com/. In the root directory of my gh-pages branch, I fire up jekyll, which is the underlying technology behind GitHub pages:
➜  gamingjs git:(gh-pages) ✗ jekyll --auto --server
/home/chris/.rvm/gems/ruby-1.9.3-p194@gamingjs-site/gems/maruku-0.6.0/lib/maruku/input/parse_doc.rb:22:in `': iconv will be deprecated in the future, use String#encode instead.
Configuration from /home/chris/repos/gamingjs/_config.yml
Auto-regenerating enabled: /home/chris/repos/gamingjs -> /home/chris/repos/gamingjs/_site
[2013-07-01 22:17:28] regeneration: 385 files changed
[2013-07-01 22:17:28] INFO  WEBrick 1.3.1
[2013-07-01 22:17:28] INFO  ruby 1.9.3 (2012-04-20) [x86_64-linux]
[2013-07-01 22:17:28] WARN  TCPServer Error: Address already in use - bind(2)
[2013-07-01 22:17:28] INFO  WEBrick::HTTPServer#start: pid=17269 port=4000
...
Then I hit the page locally in Firefox to find:



It does not work locally either.

There should not be any differences between the gamingjs.com version of ICE and the version in my example directory, but to be sure, I remove the application cache manifest locally, force reload and find:



It works. Sigh.

I set the problem aside for tonight's #pairwithme session with Jon Kirkman. The #pairwithme session goes swimmingly (added the beginning of validations to prevent blank project names) and afterwards Jon starts asking questions about my Firefox issue. Eventually those questions result in some exploratory code and shortly thereafter we realize that the updatePreview() method is being called in all cases, but is having no effect under certain conditions in Firefox. Further exploratory code suggests that there is a race condition in here and, sure enough, if we add a 1000 millisecond delay between before actually updating the preview:
  updatePreview() {
    // ...
    var wait = new Duration(milliseconds: 1000);
    new Timer(wait, (){
      if (iframe.contentWindow == null) return;
      // ...
    });
  }
Then it works—even in Firefox.

Huge thanks to Jon for talking me through that problem—I had been banging my head against it too long to be in a position to make headway with it.

With the problem understood, I am ready to fix it. Tomorrow.



Day #799

No comments:

Post a Comment