All modern web-browsers except IE9 are vulnerable to a huge memory leak
code.google.com
code.google.com
Am I missing some way to install IE9 on XP?
If you are seriously having an issue with IE9 crashing and aren't just looking for a reason to zing Microsoft, try updating your graphics drivers... Unfortunately having to worry about that sort of thing is the price you pay for the fast low-level GPU drawing/compositor operations.
- JavaScript auto complete text doesn't display right, it is a different font size shadow that obscures the typed text.
- Pressing tab multiple times will not cycle autocomplete, but instead jump the focus out of the console and into the search prompt.
- Really minor, but I prefer a terminal where the output and input are simply in the same line rather than in seperate locations that require looking back and forth.
- If I declare a function "hello" in the terminal, and then type "hello", it merely prints "hello()" instead of printing the source of the function. Printing the source of the function with no extra work is especially valuable if I grab the non minimized version of a new javascript library and want to poke around and see what everything does.
+ I do think the "Net" tab displays requests a bit more concisely than Chromium. This could be beneficial if you are dealing with pages with lots of pictures.
= CSS and DOM inspection seems about equal.
My main concern is JavaScript though, as my current app is doing all of its rendering client side with only the Model layer on server.
That said, the Chrome dev tools are pretty righteous, too. :)
The RFC says the data can be retained in history buffers as part of normal operation and as far as I can tell that's what is happening here.
Is there a Gecko bug for this issue yet, so I can add myself to the CC list?
While the images are live, they're stored on the X server, because that's where they need to be drawn; in many cases this will just place them directly into the graphics memory. There _are_ existing Gecko bugs on trying to reduce X server resource usage by dynamically deciding which images to store in the client and which on the server... The bugs are mostly motivated by thin client setups where the X client actually has a lot more in the way of hardware resources than the X server does. Of course those are high-latency X setups (compared to your typical desktop), which makes storing the images you really need on the server all the more important.
Frustratingly, the chromium and webkit devs seem to have been ignoring it. In my case, it made one of my products completely unusable on all webkit-based browsers... which includes Android, WebOS and iOS. Sigh.
(This affects all Webkit based browsers)
Currently FF Nightly is 6. That will become Aurora 6, then Beta 6, and then Firefox (final) 6. The features in all of those should be the same, except that we might fix some bugs along the way and/or disable some features if they are not stable enough after testing. No new code is landed on Aurora, Beta or final, except for those fixes and possible disablings.
to the o/s this bug would just look like a memory hungry program so it just keeps on allocating more memory... once all physical memory has been used up, the o/s has to swap out old data to disk and re-use addresses for this program that just doesn't stop asking for more memory... i.e the program doesn't know it's doing stupid shit and the o/s doesn't know it is hosting a stupid program..
it's kinda like a house party where everyone starts the night normal, then as the night goes on some idiot doesn't recognize their own limits and they keep drinking more and more and the host doesn't know what this guy is doing and before he knows it he has to clean up vomit in the morning...
hope this makes sense..
On a desktop OS, the user has a much larger breadth of software loaded and is only using a subset of a handful of software's allocated memory at once. As long as all of that can be in RAM at once, everything else can be safely swapped out without serious performance degradation. The OS can even prefer to swap out long-dormant processes (like, say, the rarely used SSH server on your desktop) to use that RAM for disk cache.
However the reported bug is non-trivial, therefore it would be very strange if it would manifest itself identically on different non-related browsers. They might all leak, but I doubt they all leak 1M for 22kb file.
Chrome and Safari both use webkit. Of course that doesn't explain Firefox.
I'm not sure what you mean by IE being 'native' to Windows. Regardless of what MS tried to pull 10 years ago, IE being included with Windows does not make it part what the rest of us call the OS. It's an application.