Make Jasmine run at (near) full-speed in a background tab

Friday, March 2, 2012

Jasmine environments have a default updateInterval value of 250 that determines how often, in milliseconds, execution of the next spec will be deferred so that the screen can be updated.

    var now = new Date().getTime();
    if (self.env.updateInterval && now - self.env.lastUpdate > self.env.updateInterval) {
      self.env.lastUpdate = now;
      self.env.setTimeout(function() {
        self.next_();
      }, 0);
    } else {
      if (jasmine.Queue.LOOP_DONT_RECURSE && completedSynchronously) {
        goAgain = true;
      } else {
        self.next_();
      }
    }

Both Chrome and Firefox now require a minimum value of one second for setTimeout in a background tab. This basically means that for every 250ms of work that we do, we end up sleeping for 1000ms.

This gist shows one way to tell Jasmine to not even bother trying to update the screen when running in the background.

var foregroundScreenRefreshRate = 1500;
var backgroundScreenRefreshRate = 9000;

jasmine.getEnv().updateInterval = foregroundScreenRefreshRate;

$(window).focus(function() {
    jasmine.getEnv().updateInterval = foregroundScreenRefreshRate;
});

$(window).blur(function() {
    jasmine.getEnv().updateInterval = backgroundScreenRefreshRate;
});

(Please refer to the gist for the most up-to-date code.)

This code makes Jasmine run at full-speed in a background tab in Chrome, but continue to be updated about once every 2.5 seconds when in a foreground tab. However, using this as-is in Firefox will result in a warning about an unresponsive script, if the tab is inactive. Luckily, you can continue to run Firefox in the foreground fine with this script (good for CI perhaps), or you can just override the dom.max_script_run_time variable to never get that warning, or you can set updateInterval to something less than the default 10 second max script run time.

Chrome and Firefox throttle setTimeout/setInterval in inactive tabs

Mark Rushakoff

Wednesday, February 29, 2012

Do your Jasmine tests (or anything else) seem to lock up when they aren’t the active tab in your browser?

Unfortunately, your new and modern browser is to blame. There are a few workarounds, but none of them are ideal in my opinion.

The cause of the problem

In early 2011, both Firefox and Chrome clamped the minimum wait time for setTimeout and setInterval to one second when running in a tab that is not the active tab for its window.

You might also be surprised to find out that HTML5 specifies a minimum of 4ms delay for setTimeout.

Workarounds

Workaround 1: Run that tab in its own window

This is the easiest solution, but it’s often less convenient to switch between browser windows when you want to just switch between tabs in the same window.

Workaround 2: Compensate for the fact that your callbacks will happen at most once per second

The accepted answer at this StackOverflow question demonstrates how you can figure out “where your animation is supposed to be” and just jump ahead. This workaround probably doesn’t apply if you have logic beyond visuals that depend on somewhat accurate timing.

Workaround 3: Use another, newer (and not necessarily standardized) API

window.postMessage

Mozilla suggests that you use window.postMessage to achieve sub-4ms delays.

window.setImmediate

Microsoft recommends using the setImmediate function as a replacement for setTimeout with a delay of 0.

But Mozilla has this to say about setImmediate:

This method is currently only proposed, is not expected to become standard, and is only implemented by recent builds of Internet Explorer.

On a side note, the Microsoft page has a lovely visualization of quicksort.

window.requestAnimationFrame

Another not-yet-standardized function, requestAnimationFrame seems best suited for animations, not for precise timing.

Workaround 4: Build your browser from modified source

I’m being somewhat facetious here, but Chrome and Firefox both have hardcoded constants for the interval limit. Without looking through the rest of the source code, I can’t conclusively say for either browser that there is no simple way to add support for overriding the inactive tab’s clamp value.

I saw one or two mentions about Firefox having an option to overwrite the minimum timeout limit, but since I’m not able to find those links again or any further information about those options, I’m led to believe that Firefox also does not let you override that one second minimum limit.

Unwanted whitespace between elements

Mark Rushakoff

Saturday, January 21, 2012

We recently came across a situation in our markup where we wanted whitespace in the markup for readability, but we didn’t want that whitespace represented between the elements.

We found a fix that suggested using font-size: 0 in CSS to eliminate the whitespace. That worked fine in Chrome, but we found that in Firefox, the containing element no longer scrolled with the mouse wheel or arrow keys! Apparently Firefox’s scroll speed is proportional to font-size.

Here’s a jsFiddle demonstrating the issue (open in Firefox to see the problem, of course).

Ultimately the best solution for us was to eliminate the whitespace in the markup. This StackOverflow question lists a couple creative ways to solve the same problem (using comments in place of whitespace, leaving the whitespace inside the tag).

The CSS3 draft (currently) specifies a text-space-collapse property, but we are targeting IE8 among other browsers, and the draft doesn’t seem to be finalized anyhow.

Standup 9/10/2009: "All Alias, All The Time"

Pivotal Labs

Thursday, September 10, 2009

Interesting Things

One team reported that Capistrano can’t deal with host aliases in .ssh/config. Others use host aliases with capistrano without trouble. The problem could be related to multiple host aliases. All this led to the statement:
If you are working with EY, you should go all alias, all the time.
Problems with JsUnit and Firefox 3.5. From Adam:
If you’re planning to use JsUnit, or you already use JsUnit
and you plan to upgrade your Firefox to version 3.5, you
may run into this problem. Apparently the security settings
in Firefox were updated in 3.5 to restrict file access in a way
that stymies JsUnit. If you don’t fix this JsUnit will fail to open
test files, and will simply hang on tests runs, with no error
output. To fix it:
- type ‘about:config’ in the Firefox URL bar
- Filter by ‘security.fileuri.strict_origin_policy’
- Set this to false

Standup 11/11/2008: Firefoxen goodness

Pivotal Labs

Thursday, November 13, 2008

Interesting Things

In response to our ask for help, Ray Baxter answered us in code with a script called Firefoxen. “It’s a script to automatically configure multiple installations of Firefox so that they open with different profiles.” You can grab Firefoxen on GitHub. Thanks Ray!
IE7 sends odd Accept headers (*.* instead of an explicit text/html) which can cause undesired behavior in Rails. Someone suggested manually setting the format in a before_filter:
```
params[:format] ||= 'text/html'
```
This was discouraged because it can cause problems elsewhere. A better solution was to put the html format at the top of any `respond_to` blocks:
```
def show
  respond_to.html # run by default when type cannot be determined
  respond_to.js
end
```
The Ruby MySQL Gem version 2.7 leaks memory for very large queries. The solution is to remove the 2.7 gem and manually install version 2.8 from source. This library is no longer a gem and must be installed from the mysql-ruby-2.8 tarball.

Ask for Help

“As a followup to Firefox SSL certificate problems…”

It turns out that our server running nginx had an old version of OpenSSL installed. Upgrading OpenSSL solved the problem.