Slashdot Mirror

They can be applied to any window w/ a key combo, and are fairly customisable.
Here's a custom one applied to Firefox, is one that preserves colours while inverting lightness.

http://m8y.org/tmp/biased-inverted-lightness.txt
http://m8y.org/tmp/inverted-lightness.txt

http://m8y.org/tmp/lightness1.jpeg http://m8y.org/tmp/lightness2.jpeg http://m8y.org/tmp/lightness3.jpeg

Arbitrary tweaks of the values. Apologies for the relative unreadableness of the script (variable reuse, bad names) was just a quick implementation of:
http://dbaron.org/log/20110430-invert-colors

To be actually usable for routine web browsing.

> How do we end up with fundamentally unimplementable standards?

See http://dbaron.org/log/2006-08#e20060818a

The issue is not that a given standard can't be implemented, but that a combination of two standards designed by two different groups of people can't be implemented.

> Worse, it calls the entire standards process and branding mechanisms into disrepute.

That's about where it was in 2006/2007, yes. That's why WHATWG got started...

> Shouldn't we be calling for the resignations of some or all of the W3C for a bungle
> like that?

Whom do you want to resign? The W3C staff? Or the people who actually wrote the standards (who are representatives of some companies, who are no longer involved in the W3C)?

This part of the standard is being errataed to be optional.

And yes, people skip parts of standards all the time if they don't think they're important, especially when the standard was created for a totally different use case (in particular, SVG as originally written was basically created to not be used with HTML and not be used on the web; there were nods to both but they were not the primary use case). How many zip decompressors actually allow multiple copies of the same file to be present in the archive and look at the index to see which one to extract? How many just grab whatever they find?

You may also want to read http://dbaron.org/log/2004-06#e20040609a and http://dbaron.org/log/2006-08#e20060818a for some of the history here...

This part of the standard is being errataed to be optional.

And yes, people skip parts of standards all the time if they don't think they're important, especially when the standard was created for a totally different use case (in particular, SVG as originally written was basically created to not be used with HTML and not be used on the web; there were nods to both but they were not the primary use case). How many zip decompressors actually allow multiple copies of the same file to be present in the archive and look at the index to see which one to extract? How many just grab whatever they find?

You may also want to read http://dbaron.org/log/2004-06#e20040609a and http://dbaron.org/log/2006-08#e20060818a for some of the history here...

> Can this thing prevent covert, un-removable install of add-ons
> (e.g. .NET Framework Assistant)?

Not yet. Being worked on.

> Does it set layout.css.visited_links_enabled to false?

You did read http://dbaron.org/mozilla/visited-privacy right? It was linked to from the article mentioned in response to the comment you cite.

The short of it is that layout.css.visited_links_enabled is still true so _you_ get to see the visited links styled differently, but the website is blocked from being able to tell apart visited and unvisited links. And yes, every single Firefox 4 beta has had that fix, including this one.

I put 4.0 beta 6 through the Kraken benchmark mentioned in the story, and the memory use never went over 400 MB. After I closed that tab, it was back down below 80 MB. I've left FF open for days or even weeks and not seen the type of growth you're talking about since about 2.0.16 or maybe 3.0.2 in the 3.x line.

Is there still some leak? Probably. In fact, in such a large project there are probably a few memory leaks and other types of resource leaks. Is it as bad as it used to be? Not at all, at least not for me. Browsing patterns could make a difference, though.

Typically, the only extensions I'm running are Firebug, a couple of HTML and accessibility validators, and Clippings.

I'm not a browser snob, mind you, and I have nothing to do with the Mozilla organization. I use Chrome mostly right now for casual browsing, but Firefox for developing anything to do with a website. I also have more than half a dozen other browsers installed for testing. I just don't see the memory leaks of the kind some people do.

My OS on the system I use the most right now is Mandriva 2010 Spring with kernel 2.6.33.7-desktop-1mnb SMP for AMD64 and libc glibc-2.11.1-8mnb2. It also has glibc_lsb-2.4.7-4mdv2010.1 installed for LSB compatibility.

One problem Firefox has had even into the 3.6 line is that it doesn't always get rid of JavaScript objects created for a piece of content when that content goes out of scope. That is, you open a web page, it creates a JavaScript object but never GCs it, and when you close the page FF might miss GCing it upon closing the tab or navigating to another page. This is something the JavaScript engine should clean up, and it is definitely a Firefox bug. It can also happen for Firefox's reconfigurable interface chrome. There's an extension for Firefox meant to catch this particular class of problem when it happens, and it'd be handy for the the developers if people reported this as the source of a leak specifically so they know where to look for the leak. Leak Monitor reports these JS garbage collection object leaks to the user, who cna then complain more specifically about what kind of leak is going on. The author of that extension says that some short-term object leaks that get caught a few cycles later make the reporting kind of messy for the 3.x branches, though.

> for example, standards don't seem to have been Job One for some time

Standards have in fact been Job One, but the nice thing with standards is that there are so many to choose from. If you don't have the resources to implement them all, or think some of them are actively bad for the web (P3P comes to mind), you don't implement them. See also http://dbaron.org/log/2006-08#e20060818a

For the specific thing keeping Mozilla from a 100/100 score on Acid3, see http://weblogs.mozillazine.org/roc/archives/2010/06/not_implementin.html

What has _not_ been Job One, unlike Apple, is making up new functionality and proposing it for standardization. Maybe it should have been; it's certainly an effective marketing technique for making it seem like you're ahead on standards.

Do as I did a while back and set layout.css.visited_links_enabled = false in about:config.
Not knowing whether one has seen a page already sucks though. Mozilla said at some point [1,2] that it is hard to fix that issue.
I'd be happy it if CSS/JS couldn't see :visited, but the browser can set its color.

[1] http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/
[2] http://dbaron.org/mozilla/visited-privacy

> I'm referring to the fact that you can't count on HTML5 documents being well formed
> like you can with XHTML.

While true, that doesn't matter that much if the parsing algorithm is well-defined. And the current problem is that you can't count on any documents actually being produced as XHTML (with the right MIME type; there's plenty of stuff out there with the XHTML doctype, and most of it is not well-formed).

> All for the sake of people being able to write sloppy markup

They already do this, and are enabled by the fact that web browsers "deal". The parsing specification if entirely for the benefit of consumers of the crap that the producers are generating no matter what.

The other alternative is fatal error handling and all consumers sticking to their guns on that (which even for XHTML they're not so much). As you note, XHTML tried this approach. It failed in the marketplace, for various reasons, ranging from lack of IE support to it being too much pain to author with the tools people were using.

> Imagine if the JPEG format had been forced as the only format leaving no scope for
> animated gifs?

Then that would be a poor standard. I don't see what that has to do with the HTML5 draft.

> WHATWG is a group that was setup by individuals, which is a far cry from the W3C
> which as you rightly state is quite well represented.

Not quite. WHATWG was set up by individuals officially representing Opera, Mozilla, and Apple. The W3C is a pay-to-play industry consortium. Both take input from various sources, but in the end for WHATWG the steering committee has members from the above three organizations and for the W3C the consensus need only be amongst the paid-up members. Which is better for the web depends on whether you trust the above three organizations to develop web technologies more than you trust the average W3C member...

> The W3C was on the right path

Do you mean not having made any meaningful progress on actually delivering anything other than a recasting of HTML4.01 into XML syntax in years? Or do you mean having made some progress on defining a completely new language that would be incompatible with both XHTML1 and HTML4.01 and that had no clear strategy for how anyone would actually start using it?

Note that nothing prevents work on XHTML2 from continuing. It would hardly be the first time the W3C has produced specs that don't work well with each other, or even flat-out contradict each other.

Note also that HTML5 does have some serious issues on a lot of the details; those need to be worked out. But the overall approach of something that can actually be adopted incrementally seems to be the correct one to me. It's already paying off: the web platform is moving forward for the first time in years, and might even stave off the Silverlight-like beasties.

Additional recommended reading:

http://www.jwz.org/doc/worse-is-better.html (which sort of sums up why HTML5 is getting more traction than XHTML2).

http://dbaron.org/log/2006-08#e20060818a (which explains more or less how some of the people who started the WHATWG came to be working outside the W3C in the first place).

But on the Acid3 Web standards test, a program that focuses on DOM (document object model) support

And such urgently needed features as SVG animation, SVG font support, as well as problems found in commonly-used browsers, i.e. FF and IE. The tests are incredibly biased.

David Baron said it best: what matters more, standards support before or after the test? After all, would you rather see worked on first or (one of the Acid3 tests) proper whitespace preservation of the class attribute?

Is the doctype <!DOCTYPE html PUBLIC> invalid?

Validity is a property of documents; a doctype declaration alone cannot be valid or invalid. But that code is incorrect, you've forgotten the public identifier. That code also puts other browsers into quirks mode.

Is the ISO HTML 2000 version doctype invalid?

There's more than one ISO HTML 2000 doctype declaration available. As for correctness, that depends on whether or not you screw the syntax up. But next to nobody uses that doctype anyway. Can you name a single HTML tutorial that mentions it? The OP wondered if he was reading the wrong tutorials, in my experience, it's common for tutorials to miss out doctypes altogether and unheard of for them to mention ISO-HTML at all. So we can reasonably eliminate that from consideration as well.

Is it considered invalid to put the XML prolog before the doctype of an XHTML document?

It is not invalid, but you shouldn't do so when serving it as text/html as it goes against the compatibility guidelines in the XHTML 1.0 specification, which RFC 2854 requires you to follow. Further, Internet Explorer hasn't chosen quirks mode for documents with XML prologues since version 6, so that's not the issue here either.

Is it considered invalid to put an SGML comment before the doctype?

There's nothing wrong with that, although again, it's not something tutorials teach. You can divide HTML tutorials into two different groups: one doesn't mention doctypes and the other says that the doctype must come first (or straight after the XML prologue).

Wikipedia says all of those situations will put some IE versions into quirks mode despite the presence of a doctype.

But "some IE versions" isn't relevant here, we are talking about version 8 in particular. Are you actually looking for an explanation for the problem, or are you just trying to find a way of blaming Microsoft? Doctype switching has been around for many years, all major browsers do it, and it's silly to blame Microsoft for auto margin centring not working when Internet Explorer has supported it for seven years.

I thought it was me providing you information to help you figure out your problem. If it's occurring only on your machine, that sounds like it's the number (2) situation I describe. If you still think it's the number (1) situation, it's still up to you to write a useful bug report. You can read what folks are saying about Firefox 3, and I don't see any hint of it having any memory problem. In fact, they seem to be saying there isn't one.

I have had Firefox 3 beta 3 open for a week with several tabs open at all times (including opening and closing tabs regularly) and it's consumed less than 200 MB of RAM. I see other people in this discussion saying they never see a memory problem in Firefox. In another recent article, there were at least two other posters who said they keep Firefox running for one or two weeks and it doesn't use more than a few hundred MB. Anyway, when you give a set of steps to reproduce a bug, you should give the specific steps to perform.

When I do that, Firefox uses about 100 MB of memory, about the same as any other browser. Besides, you give nearly exactly David Baron's example of a useless bug report. In order for problems to be fixed, we must come up with specific problems, along with a detailed set of instructions for how others can reproduce them. Then we can file a bug report on each specific issue. Can you point out any specific problems in Firefox?

When I say "steps to reproduce" I mean a specific, detailed set of steps to reliably reproduce the problem. Read How to Report Bugs Effectively and Please file good memory leak bugs for more information.

If it's not worse than any other browser, why complain specifically about Firefox? Why not just say all browsers suck, without specifically mentioning Firefox?

Memory use is a combination of necessary memory use, caches, memory fragmentation, and memory leaks. What you're describing sounds like memory leaks, not caching. The good news is that in Firefox 3, Mozilla developers' "extensive testing shows an occasional leak here and there and we are working to fix those, but in general we aren't seeing many leaks anymore." If you see any way to reproduce any memory problem in Firefox 3, please report it with the set of steps used to cause the problem.

There have been no "vehement denials issued by the Firefox team regarding the memory leaks," unless by that phrase you mean "politely asking for how to reproduce memory leaks." If you have a way that others can reproduce the problem, please file a bug report so the bug can be fixed!

Here we go again... could you explain to me how I could see "high memory consumption" in Firefox, significantly higher than other browsers use? Please give a detailed set of steps for how I could reproduce the problem on other computers. If you do, I'll file a bug report so the problem can be fixed.

So, you've filed a report for this -- right?

What flamewar? For nearly two years, Mozilla developers have asked users to file good memory leak bug reports and have even supplied tools for doing so. If you're still having problems, simply report them and they can be fixed. You can report any bugs in Firefox 3 beta directly to Bugzilla, or discuss them in the MozillaZine Firefox Builds forum first.

There's most definitely memory leaks there. Even the memory leak detecting extension popped up for me so often that I had to uninstall it.

Sorry, but "Open a bunch of tabs that use plugins." isn't exactly a reproducible set of steps. I open a bunch of tabs that use plugins all the time, and I have seen memory usage go up to 400 MB, but memory usage almost always goes back down to below 200 MB after I close the tabs. Don't all browsers use lots of memory when you open a bunch of tabs that use plugins, and then release the memory when you close the tabs?

If you still think that Firefox has memory problems that other browsers don't have, please give a specific set of steps to follow that causes high memory usage in Firefox and not other browsers.

I wish they would just focus on fixing the memory leaks first.

They may not be completely ignoring the massive memory leaks that Firefox 2.0 still has, but they sure as hell aren't communicating that they are actually looking into them and have any intention of fixing them.

What massive memory leaks? Can you point out a single, specific "massive memory leak" in Firefox 2? I don't see any except small, infrequent leaks.

As for communicating that they are actually looking into them, see this page about how to report memory leaks and this list of memory leaks fixed in 2006.

You really need to give a detailed set of steps to perform to see the problem. I leave Firefox open, going to lots of sites and having lots of tabs open, to sites that use JavaScript, Flash, and Java, and I don't see any obvious huge problem. After several days I can see some leaks from the leak-gauge script, and I have reported several memory leaks. However, even in the worst circumstances it seems like I would be able to use Firefox for many weeks at a time without having any serious memory use problems, even with only 1 GB of RAM.

You might want to reinstall your operating system. There have been several clues recently that third-party software can cause Firefox to hog memory.

If you're still convinced that it's a problem with Firefox, help to narrow down what the problem is so it can be investigated.

I've surfed with SeaMonkey every day for several days without closing it, and the memory use still hangs around 100 MB. If you see memory use go up to 300 MB and want the problem fixed, you should describe what you're doing to cause that so the bug can be investigated. Until then, all we can say is that we simply don't see the problem you're referring to.

Do volunteers care about tracking down memory leaks?

No, they just want to complain about them rather than help track them down.

If you do want to help track down memory leaks, it might be good to start a discussion on MozillaZine.

I suspect much of ff's balkiness comes from IE specific coding on sites. When those sites change, maybe that will go away. In the meantime, it happens more than I (and a lot of others) like.

[...] Does anybody know if development efforts for Firefox 2 have included memory management? I can't seem to find any record of that online.

Maybe this MozillaZine Knowledge Base article about memory problems in Firefox holds the answer:

Memory leaks can cause Firefox not to release memory that it is no longer using, especially with older versions. There has been a lot of effort to reduce the leaks in recent versions, and Mozilla developers have have created tools to detect them. [4] [5] To minimize leaks, you should upgrade to the most recent version. The most common memory leaks appear to be fixed in Firefox 2. [6]

I've had situations where, upon running the app FRESH, it's shit all over 70 megs of my memory - on RC3. And on /. alone. Opera in the same environment only uses ~30

Dozens of memory leaks have been fixed in Firefox 2. A memory benchmark shows Firefox 2 consumes less memory than IE 7 or Opera 9.

If you're still seeing a memory problem in Firefox 2, what you should do is describe steps to reproduce the problem so the bug can be reported and fixed.

Full SVG support, integrated and sorted (should have been done before)

"Full SVG" doesn't make it entirely clear what you want, given the different versions and profiles. Most web browser developers seem to dislike the recent SVG Tiny 1.2, because its design is unsuitable for the web. Mozilla already has bloat problems with their SVG implementation (partly their fault, partly because the spec is large and complex), and some developers want a simpler SVG because most people don't actually need SVG - they just want proper scalable images in web pages. (The same applies for wanting animated PNGs, but not needing MNG). None of that is an excuse for bugs or missing features in what they've already decided to try to implement, though.

Whole page zoom seems to be an area where Firefox is falling behind at the moment - as far as I can see, the plan is to do that for Firefox 3 (which has a new graphics system) some time next year. I believe that new graphics system will let them do nicer image resizing too.

They must be absolutely sick of hearing about it by now and would like nothing better than to be able to get rid of it once and for all.

I definitely agree with you that it's reasonable to expect firefox to be stable. I can think of one difference between your buddy's PC and yours, though: the browser history. Maybe if you have some spare time, you could look at a weblog entry from David Baron and see if you can make the problem occur somewhere else.

Sorry, I wasn't engaging in "personal attacks on anyone who runs into difficulty." I pointed out the poster was fabricating an obviously untrue report about the number of Firefox users decreasing. I have noticed many other people fabricating other bad news about Firefox (such as the recent hoax about security problems), and often the "bad news" can easily be proven untrue.

As for your genuine memory problem, I'm sorry to head about it. I use Firefox for days at a time, and memory use stays at around 100 MB for me. If you want something done about the problem you're having, you'll have to give enough information that other people can see the bug on their own machine (as easily as possible). Simply saying you see the problem after a day or two of use doesn't help, because most people see memory usage stay low, even when running Firefox continually for days.

Does it matter? Stock Firefox needs at least half a dozen extensions just to get the basic functionality it should come with by default.

For the rest of my response, I'll follow your lead and truncate your post to soundbites.

...I've never seen it happen in Opera...

If you'd read my post, I said "mostly due to plugins" -- which you conveniently left out, and which affects Opera, Konqueror, and IE just as badly as Firefox. I've never had Firefox lock up hard past 1.0 that wasn't obviously related to a plugin (esp. Macromedia Flash or Adobe Acrobat) crashing the browser while loading/unloading a page. That's about as strong a promise as you can make when your product loads 3rd party native code.

...the problem is probably due to an extension...

There's a vast realm of difference between a plugin (executable native code) crashing the browser vs. an extension (XUL plus Javascript). The former crashing the browser is inevitable. The latter crashing the browser is sloppy, although some leaks are inevitable. (More on that in a bit.)

You said, "My gut says..."

Yup. I'm a programmer, have been since I was a wee one, been using C and C++ for 10 years, played with Object-Oriented Pascal back in the day, coded serious Java and Perl, written the occasional assembly, walked uphill in the snow both ways, etc. My gut is a finely crafted, state-of-the-art early warning system for catching bugs -- especially memory leaks, NULL pointer dereferences, double free() bugs, buffer overflows, yadda, after using C for that long. Like all heuristical systems it's far from perfect, with false positives and negatives both, but as an early warning system it works wonders. I haven't read the Firefox source code from top to bottom, although I'm fairly certain no lone human could, and I haven't even given it a serious skimming, so I don't have anything more than an educated guess to fly by. But I've seen some surprising interactions between "simple" GDI calls and Windows video card drivers, including previous ones where Firefox crashes under one driver version but runs fine after a driver upgrade (or even a downgrade). (This might or might not stem from the fact that, for speed, Firefox stores bitmaps in video texture RAM on Windows, and asks the X server to do the same on Linux.) I also know from past experience that HTML pages with <embed> and <object> tags crash all browsers far more often than HTML pages without, regardless of the browser in use (and not by virtue of the HTML itself, if you catch my drift). Video drivers and plugins are two likely suspects, and they're the first place I'd point gdb if I came across the RAM/CPU bug on my own machine.

...no one on the Mozilla Foundation team has investigated the CPU hogging bug...

Now, my memory may be faulty, but my entire post was based on reading someone's investigation into the RAM/CPU bug a few years back. Unfortunately, I didn't bookmark it and some creative googling hasn't turned it up. However, I did read Bugzilla in-depth to double check that I wasn't missing anything. (More on that in a bit.)

Your googling, OTOH, showed me two things: (1) a sizable number of people misinterpret the in-RAM cache and Back/Forward cache as memory leaks, not features; and (2) several extensions do/did cause Javascript memory leaks, but are being rooted out one by one (via debug builds and the Leak Monitor extension).

Just to make sure I wasn't missing anything, I did a fairly thorough sniff through Bugzilla. I searched all products for "leak", then personally read all 27 INVALID bugs and all 5 WONTFIX bugs. I didn't see one that wasn't legitimately so.

(Please note that Bugzilla forbids d

> Firefox also seems to be a huge memory hog,

See this article:
http://kb.mozillazine.org/Reducing_memory_usage_-_ Firefox

It will tell you how to recude memory usage and also points you to an extension which you can use to track down extensions that leak memory: http://dbaron.org/mozilla/leak-monitor/

Of course! They've written the Leak Monitor extension to help extension authors to find leaks in their extensions. As far as I know, there's no way to limit the memory an extension uses without causing additional problems, or to kill an extension that's using too much memory. If you have a detailed suggestion for how extensions or plugins could run in their own processes, perhaps you should explain it.

The image was uploaded by David Baron, one of Mozillas lead developer I think that is claim enough.

Whenever you close a tab or window and a leak is detected, you'll get a message about it. I used it for a few days and discovered several minor extentions I'd been using were causing some very large leaks.

No one is denying that there are memory leaks. However, they're not common (occuring on only about 1% of visited pages) and often very hard to reproduce reliably. You can help by using the memory leak tool and reporting good memory leak bugs.

For a look at what is being done about memory leaks, read this article

No kidding, this article is also from a well-know firefox developer, they're fixing lots of memory leaks.

Apparently the top poster is one of those people who lovse to get karma for apparently-insightful articles. "Cyricz said that firefox developers don't care about memory leaks!". I mean, who wouldn't believe someone who says that a software developer don't want to fix a serious bug in his software?

I wonder what paragraph is the "most telling". The one where the firefox developer says that memory leaks are something normal? I'm running firefox in a 512 MB machine and I have never seen firefox eat 400 MB, right now it's eating 48 MB of RAM and that looks fine to me, specially when they're improving and fixing leaks on each release. I know opera is more resource-friendly....but then, opera is far from being as featureful (call me when opera can be as configurable as firefox + thousand of extensions) so I don't really see it as an alternative, just like IE.

Firefox developers are working hard to beat Microsoft. Maybe I should remember that if Microsoft controls the web browser market it controls a big part of the internet. The firefox developers are working hard to fight that - and they're fixing memory leaks on the way.

Have you been here? http://dbaron.org/log/2006-01#e20060114a
and helped do something about it?

Also see here
http://www.squarefree.com/2006/02/04/memory-leak-p rogress/#comments
about progress made and being made.

Do you really want regular users using all those risky extensions?

So, is it Firefox and Thunderbird thrown together in one executable? Or is it something more or less.

It's both more and less. It has a different approach to what such a program should be. Firefox and Thunderbird operate on the principle that it needs to be usable by the proverbial grandmother, and make a lot of sacrifices to get there. Features that are considered "bloat" or confusing are cut rigorously, the user interface gets lots of polishing, and everything that isn't considered essential for basic operation is delegated to the status of extension (which leads to a number of problems). Because of this, Firefox and Thunderbird are supremely usable products, which I'll heartily recommend to any computer novice.

SeaMonkey on the other hand continues the tradition of the Mozilla Suite, which cared less about appearing clunky and confusing, and is far more customizable and ultimately usable for power users, web developers and other geeks. The SeaMonkey people understand that people can have ways to browse which aren't intuitively obvious to grandmothers, but which are ultimately more efficient, and that enabling this is a great good.

As a result SeaMonkey has a number of features that aren't present (by default or at all) in Firefox/Thunderbird, ranging from roaming profiles, to the dom inspector and javascript debugger, to tighter integration between the email program and the browser to far more preferences exposed and easily editable. On the other hand, Firefox has more money behind it, and so has been developing rapidly in some areas, resulting in a large gap in SeaMonkey in an area such as extension management (of course, extensions aren't as necessary for effectively using SeaMonkey, but it's still a big gap).

So, to answer your three questions:

Compatability with Thunder/Fire themes and extensions.

Partly, depending on the specifics of the extension, and the effort its developer went to. I answered this question more fully here.

Does it share the same security holes, or will it have its own ;)

It will mostly have the same (as most security problems are in the backend), but a few less in the frontend, as SeaMonkey has tighter review requirements than Firefox does. (I can think of one big security problem in the last year that was related to extension management which was only present in Firefox, not in Mozilla/SeaMonkey.)

Will it be udated as often as Thunder/Fire?

Yes, that is the goal, give or take a few weeks and some point releases. A SeaMonkey 1.1 release should come around the time of Firefox 2.0, and a SeaMonkey 1.5 for whenever Firefox 3.0 happens. (They'll be matches fairly closely in time, as both depend on the same branches and heavily tested stable code.)

Have a look here:
http://forums.mozillazine.org/viewtopic.php?t=3714 80

Ben Goodger 20060122: Battling Firefox Bloat http://weblogs.mozillazine.org/ben/archives/009620 .html
David Baron 20060114: Please file good memory leak bugs ! (bug 320915)
http://dbaron.org/log/2006-01#e20060114a
https://bugzilla.mozilla.org/show_bug.cgi?id=32091 5

Helping is as easy as following the directions

I have long wondered why web interfaces aren't much good. The technologies are there; Java applets, Flash, Python could do it, JavaScript could with a few extensions, XUL, heck, even C, compiled on the fly. All these stop just short of integrating well with the web and the client platform. Why? Why has nobody managed (or tried) to take the last step?

Because the only ones who could, the W3C, have abandoned HTML. They want you to move to XHTML(2), XFORMS and SVG. Therefore they are no longer in the business of extending regular HTML.

David Baron in his blog commented about the disinterest of the W3C with regards to supporting the existing API set.

HTML does not have the necessary elements to do rich ui's well. There is no widespread client-side web technology that does have what it takes (flash and java come close, but have single-supplier, standardisation, integration and accessibility issues). Like you point out, with just a few HTML extensions the web could become dramatically more useful for rich UI's, but the W3C has shown zero interest in doing that.

And then ofcourse there is the problem of 90 percent of the client space running a browser which has not seen development this millenium. But with HTA's you could conceivably figure out some kind of extension that does work in IE too. If there was some kind of unified push to make regular HTML and the existing web technology "good enough", it could succeed.

Secondly, they have plans to change the milestone cycle to allow for more time to fix the Gecko layout engine to be smaller and more efficient.

Why is Gecko allowed to undergo fairly hefty changes? Easy. Apple's release of Safari brought attention to KHTML. Heck, Mac rumor sites had all but crowned Chimera (now Camino), based on Gecko, into the OS as the default browser. Then wham, out of left field, here's Safari.

Why did such a large company go away from what the open source community considered the gold standard, Mozilla and its technologies? KHTML was a smaller codebase than Gecko, and easier for a new project to make completely their own. That's right, there was a better open source alternative out there most people had never really thought about.

People started talking about KHTML, Safari, Mozilla, and Gecko. Apple managed to shine a new light on what had been seen as acceptable without question because of, get this, a lack of competition (!) in the open source browser community. Until the little man came on the scene, Mozilla and its Gecko brethren had a near monopoly on the "not-IE" browser market.

So the next time someone wants to know what Apple's given the open source community after taking BSD for the core of its new OS, you'll know what to tell them. Not only has Apple open sourced Darwin and checked their improvements back into KHTML, they've also provided a competitive peer for Mozilla and other open source projects.