Showing posts with label browser detection. Show all posts
Showing posts with label browser detection. Show all posts

Friday, October 29, 2010

Jangaron 0.71: fix for IE9 beta

Another new browser version needs another patch.
This time, it's IE9 beta: alas, it became too standards-compliant! Thus, a typical crude workaround needed for IE6/7/8 did not work anymore. I fixed it, so you can now enjoy Jangaron in Internet Explorer 9 (beta)! It's fast and it's fun!

Evaluation
In IE < 9, you will run into problems when trying to dynamically create an input field by code like this:
  var input = document.createElement("input");
  input.setAttribute("type", "radio");
Old IEs refuse to interpret the type, also if you set it as a JavaScript attribute. Thus, you are forced to use a proprietary, IE-specific API extension that allows to hand in HTML fragments instead of the element name:
// only works in IE < 9:
  var input = document.createElement("<input type='radio'>");
Unfortunately, the usual way to do feature detection instead of browser detection does not apply here, since the function createElement() is defined in any browser, only old IEs provide additional semantics. So I did browser detection (shame on me), which of course failed when IE 9 (note: only in IE 9 mode, not in any backwards-compatibility mode!) became standards-compliant.
The only way out was to use the anti-pattern programming by exceptions and simply try the extended API and catch the error for standards-compliant browsers. To avoid recurring runtime penalty, I only do this once and store the result in a feature flag:
  var SUPPORTS_CREATE_ELEMENT_WITH_ATTRIBUTES = function() {
    try {
      window.document.createElement("<input type='text'>");
      return true;
    } catch (e) {
      return false;
    }
  }();
Instead of SUPPORTS_... I should maybe call that flag REQUIRES_..., since I do not use this feature because it is supported, but because the way the standard suggests does not work in old IEs.

Tuesday, September 14, 2010

Eventually: Jangaron + Sound in Firefox 3.6

Greetings, programs, it's been quite a while.
Jangaron looks a bit abandoned, doesn't it? Well, you may be right. I've been working hard on the "parent" project Jangaroo and its Flash compatibility: see this new Flash-ported-to-Jangaroo Demo!
But nonetheless, I was quite annoyed when I noticed that Jangaron was not working correctly with Firefox 3.6. To be more precise, the mini game worked, and the settings UI worked, but starting the full game from the settings UI with sound enabled failed. The workaround was to
  1. play Jangaron mini only or
  2. switch off sound before starting the game from the UI.
Now that I found time to dig into the problem, the solution sounds somewhat familiar: browser detection was broken with Firefox 3.6! After patching that, everything now works fine again. So please spread the word to Firefox 3.6 users to go ahead and play Jangaron (again)!
The problem was in the browser detection code I copied back then from an old version of MooTools, which detects Gecko aka Firefox like so:
  if (window.document["getBoxObjectFor"] != null)
    return ENGINE_GECKO;

It is not really bad practice to use proprietary methods or properties to detect a browser, but as you can see in this case, it is not very future-safe. Because as browsers become more and more standards-compliant, especially these proprietary methods are likely to be removed (as in this case, see here). Or, as for example happened in case of Microsoft extensions like CONTENTEDITABLE, they are copied by other browsers, and thus also fail as a distinguishing criteria.
Whatsoever, since the only thing that came after GECKO was OPERA and UNKNOWN, I now ask for Opera first and consider everything else a Gecko and hope your exotic Linux browser won't mind.

Thursday, July 3, 2008

Jangaron 0.52 in Firefox 3 -- but slow

About 20% of all Firefox surfers that have visited www.jangaron.net during the last month already used Firefox 3 -- and couldn't start the game! After a really small patch, Jangaron 0.52 now works completely in Firefox 3.
My workmate Jan found a bug in the browser abstraction code: To let standard-compatible browsers simulate IE behavior (yes, I know, it should be the other way round!), I checked whether MouseEvent is defined. Since MouseEvent is supposed to be a constructor function, I used typeof MouseEvent=="function". For reasons beyond my imagination, Firefox 3 changes the type of MouseEvent to "object", so the check failed. Now, I simply use typeof MouseEvent!="undefined".
After quick-fixing the bug (no new version number, just reload / maybe clear browser cache), the full game now works in Firefox 3. However... it runs unbearably slow :-(. I started searching for similar problems and found many disappointed Firefox users who reported that version 3 is actually quite slower than 2 (at least in certain circumstances).
Currently, there is not much more I can, or better am willing to do about it. Maybe the guys over at Mozilla will come up with some performance tips or patches soon. Until then, I do not recommend using Firefox 3 to play Jangaron. If you are brave and try, I would really be interested in your experience. By the way, I didn't yet bother to patch the "stable version" 0.43, which has the same bug, so please use 0.52 with Firefox 3.
One last hint, if you want to use Firefox 3 for surfing and Firefox 2 to play Jangaron: just google for "firefox.2 firefox.3 parallel". Essentially, you create a separate profile for each Firefox version so the other one does not mess it up, and start the program with command line switches that tell it a) to use a certain profile and b) not to reuse the running Firefox instance.
After being a bit disappointed by Firefox 3, Opera 9.5 and Internet Explorer 8 are my next candidates...