If you're seeing higher memory usage with plugins (do you mean extensions?) than without, that's a pretty good sign that you're encountering memory leaks rather than overzealous in-memory caching. Those leaks might be the fault of Firefox or the fault of the extension; you'd have to debug them to find out.
I don't think you'll find a full feature list anywhere. My changelog and the release notes mention a lot of the new features, but if you want to know whether a specific bug got fixed or feature got added, you'll need to check Bugzilla.
In this case, it's bug 334987, and it looks like it won't be done for Firefox 3.
By the way, it would be both hard to fix (because sound comes from plugins) and controversial (because some users like to leave pandora.com playing in the background while they do other things).
Being able to refer to a file inside a JAR is not new. Being able to get a list of files inside the JAR (by leaving off the filename after the "!/") is new. See bug 309296 for details.
The "debate over semantics" is happening on Slashdot. What's actually happening in the Mozilla project is that we spent the last 2 years fixing hundreds of leak bugs, and now that most of the leaks are fixed, we're noticing that fragmentation also contributes to memory use.
That said, if Firefox is using 2GB, you're probably experiencing leaks rather than fragmentation (unless you had a few hundred tabs open at some point). Is this happening for you with Firefox 3 Beta 1 or a newer trunk build?
Do you consider trying to block popup ads and spyware installation to be "depriving dollars" from "advertising-supported content"? Or are you confusing Firefox with AdBlock?
According to the financial statement, Mozilla spent $11,775,516 on "software development" in 2006. I'm guessing that mostly means salaries and benefits for employees who work on Gecko and Firefox. So the bulk of Mozilla's spending is on developing (specific) open-source software.
I don't know what the "less than $300,000" thing refers to. Maybe it refers to monetary grants to other open-source projects, or maybe it refers to things like buying laptops for volunteers so they can contribute more effectively.
Python is an ill fit for a language that's meant to be embedded in a (X)HTML, because (X)HTML does not honor content whitespace (and neither to a lot of related tools) and Python relies on whitespace for structure.
(X)HTML does preserve content whitespace. It's only text display that doesn't, depending on the value of the "white-space" CSS property. Even (some) JavaScript would break if the HTML parser replaced all line breaks with spaces.
To find a memory leak just instrument the memory allocator. See what's left when you exit the program and that's your memory leak.
The hard part is getting a leak reproduced on a developer's machine. If the developer doesn't visit the same sites as you, or doesn't use the same extension as you, he/she might not hit the same leaks.
Memory corruption is a different ballgame.
This is why I'm happy that Valgrind is about to be released for Mac.
The new time-based cache will only be for the decompressed version of the image (where each pixel is represented by 3 or 4 bytes). The compressed version of the image will be treated the same way it always has been; Firefox won't need to grab it from the site again. At worst, it will just need to decompress the JPG/PNG again.
Gecko does use per-document arenas (class FrameArena) for allocating short-lived, document-specific objects. "Frames" (rendering objects) and several other types of objects are allocated from this arena.
Many other objects associated with a document, such as DOM nodes, can be referenced from other documents, so they have to be subject to some sort of garbage collection.
Rejecting cookies outright is silly, precisely because it breaks so many sites (some of which have good reasons for relying on cookies). You should configure your browser to expire cookies after an hour or at the end of the session, not immediately.
Mozilla has considered dangling pointer use to be "probably exploitable to run arbitrary code" for a long time. I even blogged about that fact, describing what types of dangling point use are most likely to be exploitable. If other software companies refuse to prioritize those bugs until the reporter supplies a demonstration exploit that launches calc.exe or Calculator.app, they've been asking for trouble for years.
Adding support for new CSS selectors usually doesn't cause web pages to break. Especially if you're the first browser to implement them, so very few web sites try to use those selectors.
Slashdot Mirror
If you're seeing higher memory usage with plugins (do you mean extensions?) than without, that's a pretty good sign that you're encountering memory leaks rather than overzealous in-memory caching. Those leaks might be the fault of Firefox or the fault of the extension; you'd have to debug them to find out.
Why don't you want to install IE7? Lots of applications embed IE, so even if you never use Internet Explorer, you'll be safer if you update.
I don't think you'll find a full feature list anywhere. My changelog and the release notes mention a lot of the new features, but if you want to know whether a specific bug got fixed or feature got added, you'll need to check Bugzilla.
In this case, it's bug 334987, and it looks like it won't be done for Firefox 3.
By the way, it would be both hard to fix (because sound comes from plugins) and controversial (because some users like to leave pandora.com playing in the background while they do other things).
Why don't you try out the beta? I think you'd be better off using a beta than using a "stable" version that no longer receives security updates.
Being able to refer to a file inside a JAR is not new. Being able to get a list of files inside the JAR (by leaving off the filename after the "!/") is new. See bug 309296 for details.
The "debate over semantics" is happening on Slashdot. What's actually happening in the Mozilla project is that we spent the last 2 years fixing hundreds of leak bugs, and now that most of the leaks are fixed, we're noticing that fragmentation also contributes to memory use.
That said, if Firefox is using 2GB, you're probably experiencing leaks rather than fragmentation (unless you had a few hundred tabs open at some point). Is this happening for you with Firefox 3 Beta 1 or a newer trunk build?
Do you consider trying to block popup ads and spyware installation to be "depriving dollars" from "advertising-supported content"? Or are you confusing Firefox with AdBlock?
According to the financial statement, Mozilla spent $11,775,516 on "software development" in 2006. I'm guessing that mostly means salaries and benefits for employees who work on Gecko and Firefox. So the bulk of Mozilla's spending is on developing (specific) open-source software.
I don't know what the "less than $300,000" thing refers to. Maybe it refers to monetary grants to other open-source projects, or maybe it refers to things like buying laptops for volunteers so they can contribute more effectively.
Python is an ill fit for a language that's meant to be embedded in a (X)HTML, because (X)HTML does not honor content whitespace (and neither to a lot of related tools) and Python relies on whitespace for structure.
(X)HTML does preserve content whitespace. It's only text display that doesn't, depending on the value of the "white-space" CSS property. Even (some) JavaScript would break if the HTML parser replaced all line breaks with spaces.
It was a pun, using two meanings of the word "harbor". One is a noun and the other is a verb, so it shouldn't be too hard to notice...
... for selflessly pooling their resources to create what is perhaps the largest distributed computing project ever, the Storm botnet.
Better yet, put a video *on* Youtube that's just a static picture telling them they have to download another plugin to see the video.
I suppose that by real dolls you mean real *plastic* dolls dont you ?
RealDolls, which are made of PVC and silicone, should not be confused with real dolls, which are made of sugar and spice.
To find a memory leak just instrument the memory allocator. See what's left when you exit the program and that's your memory leak.
The hard part is getting a leak reproduced on a developer's machine. If the developer doesn't visit the same sites as you, or doesn't use the same extension as you, he/she might not hit the same leaks.
Memory corruption is a different ballgame.
This is why I'm happy that Valgrind is about to be released for Mac.
I've never noticed delays from GC, but dbaron (who keeps 400 tabs open) says GCs take a few seconds for him. How many tabs do you have open?
The new time-based cache will only be for the decompressed version of the image (where each pixel is represented by 3 or 4 bytes). The compressed version of the image will be treated the same way it always has been; Firefox won't need to grab it from the site again. At worst, it will just need to decompress the JPG/PNG again.
Gecko does use per-document arenas (class FrameArena) for allocating short-lived, document-specific objects. "Frames" (rendering objects) and several other types of objects are allocated from this arena.
Many other objects associated with a document, such as DOM nodes, can be referenced from other documents, so they have to be subject to some sort of garbage collection.
Did baby boomers use scrolls, too?
They've been caught lying about Opera many times.
Can you be more specific?
Rejecting cookies outright is silly, precisely because it breaks so many sites (some of which have good reasons for relying on cookies). You should configure your browser to expire cookies after an hour or at the end of the session, not immediately.
http://www.salon.com/comics/opus/2007/08/26/opus/i ndex.html
The second "censored" strip is dated next Sunday, so I guess it isn't available yet.
They are lost at sea and they want us to be a hostage to be milked until they figure out a way to get more money.
While trying to untangle your ball of metaphors, I found that the maze had no exits.
Crashing an application from a remote system means that application is not filtering [its] input correctly
Wrong. This crash has more to do with layout data structures than "filtering input".
and is subject to a remote compromise.
Only some types of crash bugs are exploitable. If this happened on Mac, we'd probably already know whether this crash was exploitable.
Firefox is only about 2/3 better (3 pages vs. 8 pages) judging by number of CVEs*.
Your link is broken (I get a cert error), so I can't tell you what's misleading about this particular vulnerability-counting scheme.
Mozilla has considered dangling pointer use to be "probably exploitable to run arbitrary code" for a long time. I even blogged about that fact, describing what types of dangling point use are most likely to be exploitable. If other software companies refuse to prioritize those bugs until the reporter supplies a demonstration exploit that launches calc.exe or Calculator.app, they've been asking for trouble for years.
Adding support for new CSS selectors usually doesn't cause web pages to break. Especially if you're the first browser to implement them, so very few web sites try to use those selectors.