Browser bugs: Posts

Hell must have frozen over or something. I don’t know if this just fixes certain kinds of leaks or all of them; explicit circular references in your code should still be avoided. Xopus, via Snook:

At Xopus we develop a pretty big (~50k lines) JavaScript application to edit XML documents through a WYSIWYG interface. With such a large application there’s a large risk of memory leaks. Indeed, this is what we’ve been experiencing in Internet Explorer 6. We’ve also seen a decrease in performance as memory usage increased. These leaks, however, do not occur in Internet Explorer 7. And, as of just 10 days ago, they no longer occur in IE6 on Windows XP.

On June 12th, Microsoft released security update MS07-033. Included in this update is the following:

General distribution release (GDR) fixes
A memory leak occurs in Internet Explorer 6 when you view a Web page that uses JScript scripting on a Windows XP-based computer (KB929874)

And indeed, IE 6 on Windows XP no longer leaks memory, nor performance. This is great news for all JavaScript hackers, there’s no need to worry about memory leaks anymore!

The one cave-at is that this fix is only available for Windows XP. For Xopus this means we’ll still have to fix the leaks, since some of our clients are still running Windows 2000. Users who haven’t installed the latest security updates will also experience memory leaks in IE 6. In the end though, Microsoft fixed the memory leak issues in Internet Explorer, and I’m thankful for that.

Internet Explorer’s behavior sometimes really, really makes me angry.

We recently rolled out a copy of our javascript libraries after much testing and, a few hours later, discovered a page on our site that IE was barfing on. Specifically, the page would load about half way and then announce that it could not load the page (despite the fact that it’s clearly loaded behind the error message) and then present you with its generic “page not found” content.

I’ve seen this behavior before and generally know what to look for, but it’s a huge pain because the page is gone and your only method for debugging it is to slowly remove code, line by line, until it stops doing it. Then you put things back bit by bit until you narrow it down to the offending line. It’s painstaking work and the constant error popping up begins to really grate.

So why does IE do this?

Perhaps I should use “when” instead of “why” in that header, because I don’t really know why the developers of IE would do this.

Update: Bit thanks to Jon in the comments for turning me on to this MSFT support page about this topic. I’ve updated this article here to more accurately describe the problem. More detail can be found in the MSFT article.

IE does this when you attempt to modify a DOM element before it is closed. This means that if you try and append a child element to another and that other element (like the document.body) is still loading, you’ll get this error. This will occur if you use .appendChild (which in Mootools includes .adopt, .injectInside, .injectBefore, etc.) or if you use Element.innerHTML = “” (or in Mootools, the .setHTML method). | Read the rest »

So I spent an entire day discovering a quirk about javascript that I must now share. In a previous post on creating default settings for classes/objects I discussed the following technique:

Now, this isn't a very useful class, but it illustrates the technique. The functions in our class don't have to worry if the options are defined; they are either what the default value is or they are what the user passed in. If the user elects to just pass in a subset of the values, that's fine:

But what if you want to extend the functionality of your class later? What if you want to be able to insert more default options?

Here's what I was doing that caused me trouble: | Read the rest »

Fantastic! Via ajaxian (of course):

Have you been bugged by IE background flicker?

Cristi Balan talked about the issue and the solution:

html {
  filter: expression(document.execCommand("BackgroundImageCache", false, true));
}

Cristi links to a blog posting by Dan Popa, who discovered the IE6 background image flicker fix. And while you're on Dan's site, check out a forensic analysis of the IE6 BackgroundImageCache command identifier.

Brandon S. writes: The first release candidate of IE version 7 came out today...
And then on ajaxian:
The IE Team has posted more details on the IE7 CSS changes so we can all get prepared:

We are currently locking down IE7 for shipping and I wanted to give an update on the CSS work that went into IE7. Chris originally outlined our plans for IE7, and we listened to a lot of feedback (blog, connect database, conferences, our WASP partnership etc.) to help us address the most grievous bugs and prioritize which features to put in for IE7. I like to thank especially the contributors on this blog for their participation. Your feedback made a difference in deciding what issues to address.

We understand that we are far from being done and we know we have still a lot of work ahead of us. IE 7 is a stepping stone in our effort to improve our standards compliance (especially around CSS). As an example, in the platform we did not focus on any proprietary properties - though we may try out new features in the future using the official ms- prefix, following the CSS extension mechanism. We also work very closely with the W3C CSS working group (which I am a member of) to help clarify assumptions in our implementation and drive clarifications into the spec. I really like to thank everyone who helped us here.

In all, we made over 200 behavior changes (bug fixes or new features) under strict mode to improve CSS2.1 compliance. All this work (with the exception of transparent PNGs) has been done under the switch only, since all changes required behavioral updates to be more in line what the CSS spec specifies. To preserve application compatibility we will not make any behavioral changes to 'quirks mode' as it has been established since IE6.

Read about the many changes that have been made.

Ok. So in my previous posts I talked a lot about various ways to detect javascript leaks, what often causes them, etc. I have to libraries that are leaking, both of which use Objects that are instantiated and reference, in one form or another, elements in the DOM.

I've fixed my memory leaks in my popup handler (which I'll post about in a sec) but not yet in my toolbar script (which manages to leak in Firefox if you can believe it). My popup handler leaked for two reasons: circular references and closures. | Read the rest »

Continuing in my efforts to make my code stop leaking (fun!), I've been working on a popup handler I wrote recently (which I plan to post and share as soon as, you know, it doesn't leak). | Read the rest »

via Ajaxian: this is a somewhat old post, but this short (3min) screencast was useful in my on-going memory leak quest. Just watching it I better understand the problem and realize that previous code I've written will require some refactoring. | Read the rest »

It's been a while since I last posted. Partly because I haven't seen anything super interesting and partly because I've been heads-down on something super-duper secret. I'll post on it when I'm good and ready.

The super secret thing I'm working on has a problem: it leaks. It leaks in Firefox, which I'm told is a rare thing. I feel special. I emailed my pal Alex about it; he's an old friend who happens to have unstoppable code kung-fu and he always seems to have something to share that's worth listening to. He writes back regarding my javascript memory leak with this pearl of wisdom that probably would have taken me a long time to figure out: | Read the rest »

found this burried in a recent ajaxian post:

Reserved ID Values?

As a followup to my entry about id="tags" causing problems in IE/Win, here are four five test pages for IE/Win:

• IE Keyword Testing (length)
• IE Keyword Testing (item)
• IE Keyword Testing (namedItem)
• IE Keyword Testing (tags)
• IE Keyword Testing (urns)

These are based on Kevin Hamilton's observation that it's highly likely the problems are caused by the tags method in IE/Win's document.all DOM interface. As he says:

[I]f you have an element with an id='tags', then document.all.tags is now a reference to that element, and no longer a method of the document.all object.

Such states would completely shatter any IE DOM scripting that relied on the document.all methods, and at least in the case of tags causes problems like crashing on print (probably because of the aforementioned conflict between the ID value and the DOM method). The other keywords of concern are chronicled in the test pages listed above. I'd test IE/Win myself, except I don't have a printer handy for IE/Win to use, and besides, bug-hunting is best conducted in large groups.

Here's the rest of the article and the test patterns and how to use them.