Firefox 36 Has A Massive Memory Leak

While looking through our TrackJS logs the other day, I ran across a peculiar error message coming from Firefox 36 on Windows 7. The error message was simply out of memory. It seemed that the pesky local storage issue had reappeared mysteriously. However, with a quick check of the codebase, I verified that no one had accidentally reverted those fixes.

With that possible cause ruled out, I turned to a developer’s best friend, Google, for solutions. Well, it appears that Firefox 36.0.0 has quite the memory leak issue. When looking into the detail of the issue, it became highly probably that this issue was the cause of the errors in our monitoring tools. Apparently, this bug rears its ugly head when you are doing 2D rendering on your page, and the site uses a 2D charting library to present information.

According to Mozilla, Firefox 36.0.1 should resolve this memory leak issue and has been released for public consumption. Upgrade Firefox today!

Tags:

Related Posts

Jul 3, 2014
2 minutes

== and === in JavaScript and HTML Input Elements

If you read any current information about best practices in JavaScript, you will typically find the following advice somewhere in the list of things to do.

Always use === and !== while avoiding == and !=

While I will never argue against this advice, there are a few things that a developer shoule realize when using === and !== instead of == and !=.

  1. === and !== first do a check of the data type of the two objects you are comparing. JavaScript never forces you to explicitly define the datatype for an object you are creating as it will automatically assign one based on the contents of the object and how it was created.
  2. The output of all of the Math functions produce integers or floats as the datatypes for the resultant numbers. For example, Math.floor(10.39438) will produce 10.
  3. When retrieving the value of any select or input or textarea is always return as a string. This means that even though the value of the string may be a perfectly good number, it will never match a number data type. For example "10" is not equal to 10 when using the ===.

You should always use === and !== instead of == and !=, but you should make sure you understand the datatypes you are dealing with so that your comparison works as expected without any surprises at runtime.

#jquery #responsive-web-design #javascript
Read More
Jul 8, 2014
3 minutes

Always Use Automated Integration Testing

QA or Quality Assurance of a software project is often the area of software development that is most neglected. Typically developers avoid software testing like their lives depended on it. While a basic level of testing is required for a single scenario to validate that your code “works”, the level of testing that is required to ensure that all users have a good user experience across all targeted platforms is something that a developer seems to think is beneath them.

#javascript #microsoft #design-patterns
Read More
Apr 30, 2014
2 minutes

Always Namespace Variable Names in JavaScript

After running into a few issues with variable naming collisions over the past few days, it drives home how much we all should be namespacing our variable names in JavaScript. When writing JavaScript code that is only in use on your own website, you should still always namespace your variables. If you are writting a JavaScript library that will be in use on any website a user puts it on, namespacing your variable names is a minimum requirement.

#javascript #design-patterns
Read More