See testcase, when viewing, that testcase, Mozilla quickly takes up more and more memory, and that seems to go on indefinitely. I haven't really gone past the 500MB boundary, because further than that, I could get problems terminating the firefox.exe process, while the process will take more and more memory, basically making my computer unusable for a long time. So please beware when opening the testcase in current trunk build! Be prepared to quickly close the firefox.exe process. The iframe content consists of this: <fieldset><audio> <script>window.addEventListener('DOMAttrModified', function() {window.frameElement.parentNode.removeChild(window.frameElement);}, true);</script> <legend></legend>

Hmm, I seem to get this also with other tags in my testing, so I guess this is not isolated to audio tags. Perhaps this is an event handling issue?

This testcase shows that the playbackrate attribute seems to get added, which triggers the DOMAttrModified event listener.

Regression range: 2008072903 - 2008073003 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=07%2F29%2F08&enddate=07%2F30%2F08 -->Bug 448445 (_might be_, couldn't find anything else as a reasonable culprit, but then again that's me) ;)

So there really shouldn't be any DOMAttrModified events here.

The issue was caused due to playbackRate and defaultPlaybackRate being erroneously implemented as content element attributes. These were changed during a call to Load at a bad time. playbackRate and defaultPlaybackRate are not content element attributes according to the spec. I've removed that and re-implemented them as DOM attributes only. The DOM is no longer modified and both test cases work fine.

Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080930093007 Minefield/3.1b1pre

Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081029 Minefield/3.1b2pre