A First Look At Firefox 3 Alpha 5

abhinav_pc writes "PC World is reporting that Mozilla today made an early testing release available from its Firefox 3 browser. This alpha version (code-named Gran Paradiso) for the first time adds the anticipated Places feature for bookmarks. Firefox 3 alpha 5 also features a new password manager. A new crash reporting system called Breakpad is also now available in some Mac OS X and Windows builds but is not yet supported on Linux. 'Places will also be less likely to lose data in the event of program or Windows crashes. In fact, according to Connor, "We haven't figured out how to make Places lose data." For backwards compatibility and manual backups, Firefox 3 will save bookmarks in the traditional bookmarks.htm file when it closes. For other bookmark upgrades, Mozilla is planning to enable bookmark tagging, and is considering building its own synchronization client into the browser capable of backing up and sharing bookmarks. '"

Comments

my seemingly eternal question:

[Tumbleweed]

Multithreaded UI yet?

Re:my seemingly eternal question:

[starwed]

Well, here's what Brendan Eich, Mozilla's chief technology officer, has to say about multithreading: Threads suck

I'm not very clueful on such matters, but it seems like maybe the most important statement is:

A requirement for JS3 (along with hygienic macros) is to do something along these more implicit lines of concurrency support. In all the fast yet maintainable MT systems I've built or worked on, the key idea (which Will Clinger stated clearly to me over lunch last fall) is to separate the mutable unshared data from the immutable shared data. Do that well, with language and VM support, and threads become what they should be: not an abstraction violator from hell, but a scaling device that can be composed with existing abstractions.

Re:my seemingly eternal question:

[zig007]

Hm.. I am not sure what you mean by that...Implicit threads are spawned i think. Not sure though.
But just as a general thing, unless you are talking about spreading stuff between cores, an event-driven model will almost always beat a multithreaded model, at least performance-wise. There are ample of academic stuff i can dig up as reference, if you like.
Also, threads can be a pain to manage, especially with GUI-stuff.
Weird stuff usually happens. Eventually(pun surely intended).

Re:my seemingly eternal question:

[Fastolfe]

I can't speak for the other poster, but one of my chief complaints about Firefox is when the UI hangs because a web page is doing something (loading or executing some bad javascript). I like to spawn off tabs to load in the background while I'm reading something else, and I regularly find Firefox completely unresponsive until one of those background tabs wraps up whatever the hell it's doing.

Re:my seemingly eternal question:

[Tumbleweed]

Well, whether the solution to the "FF locks while loading some pages" problem (is there a Bugzilla entry for this that I can keep track of?) is a multithreaded UI, or some other nifty technology, is really a moot point for me. Mainly, I just want FF to stop locking up when some web pages load. I tend to run with lots of tabs open, etc, and I can be doing other things with the browser while a particular tab (or three) is loading. I don't know whether it's bad JS, bad Flash, or what. All I know is, it's the one major downfall of FF in my opinion. Not that it's anywhere near a big enough downfall to make me switch to another browser, and lose all that lovely functionality provided by extensions.

Re:my seemingly eternal question:

[3p1ph4ny]

unless you are talking about spreading stuff between cores, an event-driven model will almost always beat a multithreaded model, at least performance-wise.

I think we are talking about spreading between cores. Even if most machines sold before late 2006 don't have multiple cores, most machines now do. Don't most of the major OEMs sell Core2Duos now?

Anyways, power users are likely to have a machine with multiple cores, and power users are likely going to be using FF3. I don't think it's unreasonable to want a multithreaded UI.

Re:my seemingly eternal question:

[zig007]

Pages locking up the browser should not be the reason to move to multithreading..
That's just a bug that should be fixed.

Re:my seemingly eternal question:

[starwed]

From the same blog post I mentioned above:

So here's a promise about threads, one that I will keep or else buy someone a trip to New Zealand and Australia (or should I say, a trip here for those over there): JS3 will be ready for the multicore desktop workload.

Just don't expect it anytime soon. :)

Re:my seemingly eternal question:

[_xeno_]

Last time I checked (which was around the Firefox 1.0 days), Firefox's JavaScript engine ran in the UI thread. This means that any long-running JavaScript task would freeze the UI, as the UI thread was no longer accepting messages - it was running JavaScript instead.

The UI will always be single-threaded, message-driven because that's how most OSes implement their UI API. The problem is that Firefox runs too many non-UI related tasks in the UI thread. Certain tasks should be done in a background thread so that the UI remains responsive. Last I checked, there's no way to do that with JavaScript in Firefox.

I've actually had to make a webpage script "yield" the CPU by basically storing all current state and then use "setTimeout" to recall it about 50ms later. This would prevent the browser from freezing, since the message loop would get to run during the 50ms timeout. In any case, it prevented the browser from becoming completely non-responsive. Still slow and jumpy, but not completely non-responsive.

Re:my seemingly eternal question:

[zig007]

I give that argument about six years. Then the cores will be so many(100+) that the spreading is done automagically by the operating system or processor itself...
To put it in sales speak: "XXXX-tecnology makes it look like one big super-core. Core abstraction by Intel(r).". :-)

Re:my seemingly eternal question:

[kat_skan]

Yeah, that's great. Know what else sucks, Mr. Eich? The whole app becoming completely inoperative because one script on one tab is stuck doing who knows what. Smacks of the old "dialog boxes suck" line that was used to explain why we couldn't have a confirmation box to avoid accidentally shutting down the entire app when we were just trying to close a tab.

Re:my seemingly eternal question:

[3p1ph4ny]

Ah, okay, must've missed that. Thanks for the info!

Re:my seemingly eternal question:

[zig007]

Have you ever tried developing multithreaded GUI-applications?
If not, I have. Usually, it starts off fine. No problems. Then you add more stuff. The application grows.
The thing with GUI programming is that it is made to respond to operating system messages.
Mixing that (event-driven) model with multi-threaded stuff requires an amount of discipline lacking in most developer teams.
The more advanced(cool) graphical components you use, the more potholes and race-conditions appear.

Just my 3.141 cents.

Re:my seemingly eternal question:

[Tumbleweed]

Whatever the solution is, I don't much care, as long as it gets fixed. That's gotta be one of the oldest bugs in the code, and I would've thought it would be a very high-priority item. Apparently I'm wrong about that. A temporarily locked-up browser seems to be not a big deal to the devs.

Re:my seemingly eternal question:

[starwed]

You do realize the statement that X is not a solution to problem Y is not the same as saying that problem Y won't or shouldn't be solved. Right?

(And make sure to read his comments on the main post for specific responses to the issue of UI.

Re:my seemingly eternal question:

[zig007]

That they don't fix that raises a different question that is quite interesting. Well at least i think so.. :-)

A friend of mine recently talked about someone..who's name i don't remember right now(a couple of beers were involved), that worked with systems security on fighter airplanes, claimed that fixing almost only high-priority bugs made the system worse.

This was very well documented, about 20 or 30 years of development had been analyzed.
He said that if the users seemingly low-priority complaints was given more weight(adressed more often), it made problems of all severities go down. Significantly.

His conclusion was that the smaller problems contributed to a more messy system where more serious problems might go unnoticed.

Not to mention that a happy customer is better than a dead one for other reasons :-)

Re:my seemingly eternal question:

[_xeno_]

Have you ever tried developing multithreaded GUI-applications?

Actually, yes.

Mixing that (event-driven) model with multi-threaded stuff requires an amount of discipline lacking in most developer teams. The more advanced(cool) graphical components you use, the more potholes and race-conditions appear.

And? While not everything should be a thread, long-running tasks really should be. Given that all interaction between JavaScript on a webpage and the UI should be fairly well-defined through various elements, it should be possible to run the JavaScript in a non-UI thread and then sync the changes back to the UI thread when it's complete, or at set intervals.

OK, yes, I'm oversimplifying a bit. Things like the DOM creates a few thousand places where JavaScript can cause changes that should be reflected on the screen.

But still, it would be nice for each page to have its own JavaScript thread, which is free to be single-threaded on a per-page basis. Conceptually the DOM is only mutable within the context of each page, and can be synced to the UI only after certain JavaScript event handlers complete.

The only problem with that theory is that any given page's DOM is actually mutable by any chrome-based JavaScript in any window. (E.g., an extensions like the DOM Inspector can modify a page's DOM via chrome JS from another window.) So while Opera appears to do something like what I'm suggesting (I can't be sure), it probably isn't really possible in Firefox.

But still, it would be nice if a page containing while (1) ; didn't freeze the entire browser. (Go ahead. Try it.)

Re:my seemingly eternal question:

[gbjbaanb]

After reading his blog entry, I think that I know the reason he doesn't like threads. If he codes even a tiny bit like he writes then I wouldn't be surprised if his single-threaded apps had race conditions and deadlocks.

I think he's also a little stuck in the 80s - 'virtual method calls cost'. yup they do, but on a 3GHz machine, the cost is literally negligible. The cost to allocate 1 byte of memory from main ram costs more than the entire time spent fixing up virtual method calls for an entire day! (and if I exaggerate about the comparison, let me remind you firefox allocates a little more than 1 byte of memory...)

He could easily put 1 thread per tab and not have any concurrency issues, no race conditions, no deadlocks. As long as he slapped a single mutex around memory shared between tabs and held it for as short a time as possible, then there will be no problems. Simple, easy, safe and yet so effective! You don't need to add threading within a javascript script - that'd be overengineering worthy of the FF memory leak.

Mozilla needs a new CTO, someone who can talk abotu stuff they know what they're talking about, not someone who likes to speak as eruditely as possibly (probably to make himself sound more intelligent) and leave the incomprehensible, management-style buzzword-speak alone.

Re:my seemingly eternal question:

[kat_skan]

Sure, which is why I use that dialog box example. It was a straight-forward but non-optimial solution to a major problem that was dismissed because eventually there would supposedly be some magic perfect solution that would take care of it better.

I can absolutely appreciate that threads introduce a whole host of issues that you don't have to deal with in a single-threaded app, but that brings me not much comfort when a script on ImageShack or GMail has locked the browser up for the third of fourth time in an evening.

Re:my seemingly eternal question:

[suv4x4]

I can't speak for the other poster, but one of my chief complaints about Firefox is when the UI hangs because a web page is doing something (loading or executing some bad javascript). I like to spawn off tabs to load in the background while I'm reading something else, and I regularly find Firefox completely unresponsive until one of those background tabs wraps up whatever the hell it's doing.

I second, triple, quadruple that. I absolutely hate the responsiveness of Firefox.

It's as if it's not waiting for a simple stream to send data, but doing something extremely CPU intensive. It truly seems like it locks up the entire process while it's doing something.

Neither IE7 or Opera do that and the browsing experience with those two is completely different just because of this performance issue in Firefox.

Re:my seemingly eternal question:

[Kadin2048]

I've worked on some pretty big, complex, custom business systems, mostly doing QA.

I've never seen any good metrics or studies on this, but it's been my experience that in some cases, single high-priority problems can sometimes be worked around more easily than large numbers of "low priority" bugs. Sometimes it's preferable (not always, but sometimes) to train users to avoid a large problem, and in the meantime fix a large number of smaller problems, rather than pulling everyone off of everything to fix the 'big' issue.

A smart project manager realizes when it's appropriate to throw a lot of resources on something, when it's better to train the users to avoid it and fix it later, and when some other path is best.

I have no idea if this is what's going on with FF, but it's just something I've come across in the past.

Re:my seemingly eternal question:

[kervel]

The problem with avoiding threads and using the alternatives (like cooperative multitasking + event driven models), is that it will become increasingly difficult to be responsive as an application grows. trying to handle GUI events every now and then while you are doing a lot of computation will very quickly go wrong when the amount of work you have to do becomes longer and longer. Threads are difficult indeed, and trying to avoid them might look reasonable, but it doesn't always work well. The KDE core apps tried to avoid threading for most of KDE3, but i believe that at least some of them will start using threads now (maybe it also has to do with QT supporting threads).

I don't know if this applies to firefox, as i don't know how firefox works. If firefox 2 doesn't use threads, then i'm really surprised by how responsive it is, when a lot of tabs are open (still very okay for me).

Re:my seemingly eternal question:

[gbjbaanb]

I have, and I do it today (and with MFC-based code. It doesn't get harder than that!)

The trick to making it easy is to have a single thread handling the UI, and worker threads fetching data or performing calculations. the threads change data that is shared with the main thread (I conceptualise this by passing a pointer to the object that has the UI methods, so I have data local to the worker, and data that is owned by the main object that I access indirectly). Anytime I access that UI data, I put a critical section round it, and I either post messages to the UI thread to get it to perform whatever updates I need it to do with that data. Decoupling the threads like this works really well, it never deadlocks and you never have race conditions, and it doesn't take much discipline either - just remember some data doesn't belong to you, and you follow simple rules to access it, and never try to call UI functions directly from the worker thread.

Re:my seemingly eternal question:

[romcabrera]

Opening PDF files in the browser

enough said.

Re:my seemingly eternal question:

[Tumbleweed]

Well, a web browser and a fighter jet have two rather different users. A web browser is a much more stressful environment (at least judging by the internet as a whole). :)

That reminds me - FF doesn't have anywhere near enough weapons to suit me...trolls are terrorists, right?

Anyway, I disagree that addressing low-priority items makes severities of other problems go down, as a general rule. It *can* do that, certainly, depending on what the problems are. This may very well be an issue specific to the environment of a fighter jet. The fewer distractions a pilot has, the better he is able to deal with what's going on. Information overload is a very real and deadly problem in a fighter cockpit. When you can't even hear the "pull up! pull up!" alarm because you're dealing with too many other things, that's ... not good.

But fixing a rarely encountered problem in FF doesn't change the fact that it occasionally locks up temporarily. The severity is still severe. If it was more than a temporary lockup, obviously it would be critical.

If that's the only thing they fix in FF3, I'll be very happy, as I have 2 gigs of RAM now, I can afford to let the memory use grow out of all reason. Lockups are always bad, though, no matter how perfectly the rest of the program works.

"But the program works PERFECTLY except for when it stops working for a bit!"

"Yeah, but it's THOSE times that we're complaining about."

Re:my seemingly eternal question:

[zig007]

Actually, yes. I am sure you have, sorry for having such bad tone there.

And? While not everything should be a thread, long-running tasks really should be. Given that all interaction between JavaScript on a webpage and the UI should be fairly well-defined through various elements, it should be possible to run the JavaScript in a non-UI thread and then sync the changes back to the UI thread when it's complete, or at set intervals. I see your points and believe me, i share your frustration, but as you say later on, the amount of stuff happening on a complex webpage is staggering.
Just an example, consider that web developers can choose when in the DOM event chain events are fired...Just an example of things making for weirdness..
Adding threads to that would, in my book, be like enabling hell and would make DOM programming even more unpredictable than it is.

But still, it would be nice if a page containing while (1) ; didn't freeze the entire browser. (Go ahead. Try it.) while (1) ;
Still here :-)

IANAFDH(I am not a firefox developer, however). They might know more tricks than me. I'd rather hope they did, actually.

Re:my seemingly eternal question:

[suv4x4]

Have you ever tried developing multithreaded GUI-applications?
If not, I have. Usually, it starts off fine. No problems. Then you add more stuff. The application grows.
The thing with GUI programming is that it is made to respond to operating system messages.
Mixing that (event-driven) model with multi-threaded stuff requires an amount of discipline lacking in most developer teams.
The more advanced(cool) graphical components you use, the more potholes and race-conditions appear.

What I'll say is horrible, but maybe will put things in perspective for you: I'd rather have Firefox crash from time to time, but be as responsive as Opera and IE, rather than it lock up every time I do *anything at all*, such as click a link.

Sum up the times it takes to reboot Firefox after a rare race condition crash and the times I've lost just waiting for it to unlock while thinking I may break out and cry if I gotta sit there doing nothing waiting for it, and multiple threads is suddenly looking a lot better.

That out of the way, giving each tab its own thread and not running the page in the UI thread has got to be one of the most obvious ways to improve the responsiveness of a browser.

I've been following the IEBlog at Microsoft and they said this is how they implemented tabs in IE because "otherwise it would lead to very bad performance every time only one of the pages is doing something slow". Amen, Jesus Christ in heaven!

Now all we need is for the Firefox team to see the light too. I'm not saying it'll be easy, and if you don't put proper architecture in it, it'll get nightmare to manage, but hell, it's quite very possible to do it if you have an idea what you're doing.

If Firefox needs to keep things simple so as "not to confuse the developers", then that's just the saddest excuse I've heard about its poor performance.

Re:my seemingly eternal question:

[UnxMully]

Well, here's what Brendan Eich, Mozilla's chief technology officer, has to say about multithreading

You know, as someone who invested a reasonable amount of my youth reading EE Smith's Lensman series, I find there's something unsettling about someone called Eich.

As a result, I can't help feeling that Mozilla must be a tool of Eddore and that anyone who opposes them is fighting for the good of humanity and civilisation.

I'll get my coat.

Re:my seemingly eternal question:

[the_kanzure]

Information overload

Nah, information overlook is the killer. The "overload" craze may still be with us, but really the problem is overlook and managing attention. And don't hide information just because it may overload some browsing users, some of us really do want to see thousands of search results per page instead of having to continuously return to the mouse or tabbing keys to get to the next page of search results, etc.

Addressing new features can cause programmers to go back and improve previous functions. Wasn't that the idea of code reuse?

And I like the idea of users == fighter pilots. :)

Re:my seemingly eternal question:

[zig007]

Yep, that's how it is usually done.
However, this is about doing multithreaded GUI stuff, just like you say one shouldn't("never try to call UI function directly from the worker thread").
The problem here is also about timing and predictability. The web developer must know in what order stuff happens.

Re:my seemingly eternal question:

[dedazo]

Which can be clearly translated to "The current code base is a mess and we'd be committing suicide if we tried to do this simple thing with it. Therefore, we need to rewrite large chunks, and that's going to take a bloody eternity, so don't hold your breath"

However, I believe the OP was referring to the Mozilla UI core. Is that affected by the JS engine since the browser itself is a XUL component? I have no idea. I tried to look at the Firefox code once and nearly gouged my eyes out after a few hours.

But that blog entry really sounds like a mix of "I'm smarter than you" and remedial marketspeak.

Re:my seemingly eternal question:

[zig007]

If we are talking multiple threads for multiple tabs, i am with you, since that is a natural separation.
I was under the impression that this was considering multiple threads within a page?

Re:my seemingly eternal question:

[Tumbleweed]

I was talking about information overload being a killer for fighter pilots. The situation is very different between that and a browser users. I agree - gimme all the freaking search results, etc. I hate paging through data. I have a scrollwheel on my mouse for a reason.

I think the idea of code reuse was to not have to reinvent the wheel every time. When you separate functioanlity into functions, you're actually LESS likely to improve older code until you have to hack in some new bit of data into the old. That's my opinion, anyway.

Re:my seemingly eternal question:

[zig007]

Oops. I didn't read your comment well enough. I am...at least more..with you on multiple threads on multiple tabs. It was using them within a page i was ranting about.

Re:my seemingly eternal question:

[bill_mcgonigle]

You don't need to add threading within a javascript script - that'd be overengineering worthy of the FF memory leak.

Doesn't Firefox render itself using XUL and Javascript?

David Hyatt (former Mozilla coder) seems to have figured out how to do threading in Safari, anyhow. Firefox is still my main browser, but Safari is very slick.

Re:my seemingly eternal question:

[zig007]

Anyway, I disagree that addressing low-priority items makes severities of other problems go down, as a general rule. It *can* do that, certainly, depending on what the problems are. This may very well be an issue specific to the environment of a fighter jet. The fewer distractions a pilot has, the better he is able to deal with what's going on. Information overload is a very real and deadly problem in a fighter cockpit. When you can't even hear the "pull up! pull up!" alarm because you're dealing with too many other things, that's ... not good. I think it could be applied to normal applications as well..
Granted, there is some obvious differences but I can recall at least two or three major bugs i have found in the last year while fixing minor ones.
Also, the issue of customer satisfaction is there as well, people do not feel comfortable using a system with a lot of annoying bugs.
At last but not least, constantly sidestepping minor bugs leads to strange usage patterns which sometimes can unearth bugs but also hiding them.

Yeah, this is not about FF3 but i felt like a change of subject :-)

Re:my seemingly eternal question:

[suv4x4]

A requirement for JS3 (along with hygienic macros) is to do something along these more implicit lines of concurrency support.

He said that? Shit.

Let me put things perspective. Tamarin (the Adobe Flash script engine) is currently implementation of JavaScript 2.0 and not 3.0. It'll show up not in Firefox 3, but Firefox 4 earliest.

To get it from JS 2.0 to 3.0 (which doesn't exist even in the form of a draft yet), it'll probably mean few more major versions, Firefox 7, Firefox 8 maybe?

Firefox doesn't just run JavaScript in the pages on JavaScript. Instead, the whole damn thing is a big swat of JavaScript, that talks to the XUL/Gecko components.

So it'll be some 5-10 years before we see multithreaded Firefox? Nice. Perfect.

Now.. when do we expect multicore desktops and laptops to start showing up, and the competition (IE/Opera/Safari) making use of multiple threads to massively improve the responsiveness of their UI? Oh yes... yesterday.

Why is this whole story so familiar? It's Netscape all over again:

"Let's just wait and add bloat and not do much about our biggest problem, since The Solution Has To Be Perfect. Threads suck, instead we'll wait for Something Perfect to manifest in reality for us."

At the same time the competition uses whatever's out there and works, and runs past them.

And they will be like "oh shoot, we can never fix this in time, it's all based on JavaScript/XUL, we need a rewrite". Then they disappear for 5 years while trying to rewrite their newly formed mess, and Microsoft stops development at IE8 and stagnates.

Nice.

Re:my seemingly eternal question:

[Carewolf]

There is no threading in Safari.. Sorry.

Re:my seemingly eternal question:

[bill_mcgonigle]

There is no threading in Safari.. Sorry.

What do you make of this?

Re:my seemingly eternal question:

[Anonymous Coward]

If firefox 2 doesn't use threads, then i'm really surprised by how responsive it is, when a lot of tabs are open (still very okay for me).

Load a big page or a few (say, the /. main page) and while it's still loading, hit ctrl-t to start a new tab and start typing a URL. You'll notice that if the other page is still loading, you won't get the list of completions for that URL.

Oddly enough, even though the UI isn't responsive enough to open the completion list, it will respond to enter, so if you type sla[tab][enter] hoping to get slashdot to load, you'll end up either pulling up an empty google search (if the tab was recognized at least) or at www.sla.com (after the browser attempts to guess what you meant by "sla"

Re:my seemingly eternal question:

[Tumbleweed]

I've definitely found unnoticed bugs before while working on other things (every week, it seems), but I think code reuse would tend to minimize that, in general.

And I certainly wouldn't advocate ignoring all minor bugs until big ones are fixed, but this bug in FF has been around since the beginning. That and the memory usage are really the only two things I experience that I would consider major bugs, and I can work around the memory usage now that I have a ridiculous amount of memory.

Re:my seemingly eternal question:

[Dan Ost]

I wish I had mod points.

That was the most insightfully depressing summation of things I've ever seen.

Re:my seemingly eternal question:

[starwed]

I don't know very much about programming, but I'm pretty sure that converting a single-threaded app the size of Firefox to a multi-threaded model is anything but straightforward.

Re:my seemingly eternal question:

[Tack]

Neither IE7 or Opera do that and the browsing experience with those two is completely different just because of this performance issue in Firefox.

I don't know about IE7 or Opera on Windows, but at least on Linux, Opera suffers from the same responsiveness problem as Firefox. I did try this last year, after a spat of disgust with Firefox. I just downloaded the latest version of Opera and tried again: open one comment-heavy slashdot page (I picked the recent one about the Creation Museum) in the background and try to use the UI. Both Firefox and Opera get head-fucked while crunching on the page.

In fact Opera is even worse: the whole time I've been typing this comment (in Firefox), Opera has been stuck spinning its wheels sucking 100% CPU, and the UI refuses to render at all. (It's repeatable, I just killed it and tried again.)

I'm embarrassed on behalf of both Mozilla Foundation and Opera Software

Re:my seemingly eternal question:

[Chandon Seldon]

Thing is, single threaded apps aren't going to stay even marginally useful for more than about 20 more minutes. Maybe there are hard problem in threading, but putting each tab in a tabbed browser into its own thread isn't one of them.

Re:my seemingly eternal question:

[Chandon Seldon]

But just as a general thing, unless you are talking about spreading stuff between cores, an event-driven model will almost always beat a multithreaded model, at least performance-wise.

It's true that a synchronous event loop generally has better throughput on a single processor core than any sort of multi-threaded construct. But, that doesn't make it the right architectural choice for a web browser. First, computers are fast enough that a 15% throughput penalty is irrelevant compared to the much more important issue of latency - when I click in a Firefox window, I want there to be a thread listening, I don't want my event to wait in a queue for half a second for the event loop to get to it. Second, I hear multi-core processors are pretty common, and my guess would be that they're getting more common rather than less common.

Re:my seemingly eternal question:

[Chandon Seldon]

Loading java applets is what annoys the crap out of me. Firefox stops responding for like 10 seconds.

I'm visualizing the simple code to spawn a thread for each tab, and... I have no idea why they aren't doing it. None.

Re:my seemingly eternal question:

[Chandon Seldon]

What's the hard part here? You have a main thread that handles everything that isn't actual per-tab content. You spawn a thread for each tab, and have it basically the same code it's running now. The only difference is that UI events for the tab-content need to be either A.) sent by the windowing system to the tab's thread or B.) accepted by the main thread and queued up for the tab thread.

Perhaps there have been really stupid architectural decisions in Firefox that hurt this plan, but if that's true they should be getting fixed *now*.

Re:my seemingly eternal question:

[Chandon Seldon]

Firefox should be moving to multi-threading anyway, because SMP has been solidly mainstream for years now. The fact that it fixes this entire class of bugs for free is just really nice.

Re:my seemingly eternal question:

[Goodgerster]

That's actually the fault of your PDF reader, which I suspect is Adobe's crapware - ever tried Evince (on Linux)?

Re:my seemingly eternal question:

[StonyUK]

If you're using Windows, try Foxit, it is orders of magnitude faster to open and render than Adobe Reader.

Re:my seemingly eternal question:

[cheater512]

He could easily put 1 thread per tab and not have any concurrency issues, no race conditions, no deadlocks. ... You don't need to add threading within a javascript script - that'd be overengineering worthy of the FF memory leak. Please dont contradict yourself. It makes yourself look stupid. :P

Everything using Gecko uses a UI powered by (yep you guessed it) Javascript and XUL.
Click the Home button? Thats javascript swapping the clicked image in and changing the url.
Kinda makes you realize what a bloody good job the Mozilla guys have done.

The javascript engine needs threading because every single thing you see on the screen was created by javascript.

Re:my seemingly eternal question:

[cheater512]

Why is this whole story so familiar? It's Netscape all over again: What? Does IE really have excellent threading? :S

Gecko runs very nicely on old single core computers.
I really dont see why your bitching about it not being able to use 256 cpu cores.
It simply doesnt need to.

Re:my seemingly eternal question:

[beyondkaoru]

did your friend work on this? :)

http://www.defenseindustrydaily.com/2007/03/f22-sq uadron-shot-down-by-the-international-date-line/in dex.php

Re:my seemingly eternal question:

[bdjacobson]

All I want is to be able to middle-click a link into the 8th tab and be able to scroll down on the current page (either normal scroll or auto-scroll) at the same time without waiting for the page in the background to render. If you want to keep it single-threaded that's fine, just tell it to wait until I'm not scrolling to render that page I just opened in the background.

Re:my seemingly eternal question:

[hughperkins]

Threads are incredibly useful, but the issue is not the development itself: its the testing. Creating a new thread, and playing with locks and so on, is pretty easy; but how are you going to guarantee that your application is thoroughly tested? Normal unit tests just dont cut it.

So, you create threading/locking standards for your code, and hope that it works, but you're never really 100% sure.

Re:my seemingly eternal question:

[gbjbaanb]

let try again, please read what I typed, not what you think I typed :) "They don't need to add threading within a javascript script."

The engine doesn't need to be MT, you just need to run several instances of it. ie 1 engine per tab, and another one to handle the main browser. Then you don't need to put any thread-aware code in the engine at all.
(this is a bit like the unix debates between forking and threading - I'm saying you can 'fork' a new JS engine to handle each tab instead of having a single JS engine that processes each tab concurrently)

Currently the JS engine doesn't do threading, so when you click the home button, everything else stops for a little bit. Sure, you don't notice it, but you do when 1 tab starts loading a pdf.

I think some of the argument about threading in JS is confused between adding thread facilities to the JS language, and simply adding better concurrency support to firefox. I really don't care for javascript+threads but I do care about a responsive UI of firefox.

Re:my seemingly eternal question:

[gbjbaanb]

In the applications I work with, that are several million lines of code and have add-on modules, normal unit tests don't cut it either. You end up testing a lot and ensuring you have facilities to stop a hung app to get a crashdump so you can see the problem, fix it and ensure it doesn't happen again. Similarly with non-threaded apps, a crashdump is sent, you see the problem and fix it. Meanwhile you do the best you can to ensure no bugs get through even though you know some will.

No app is 100% verifiably correct, not even tested, tested and tested spacecraft control systems, to medical applications, to aircraft control systems. These things are tested so much but you still get the odd bug in them.

Re:my seemingly eternal question:

[HR]

Your conclusion is not a sound one without actually examining the code. The difficulty of converting the code results from the underlying data structures and how data gets shared among the internal modules. You have no idea what this looks like from examining only the user interface being rendered on the screen.

I haven't examined the code but I know that you cannot claim that the underlying code/data is well segregated merely because the pages are being rendered in separate tabs in the UI.

Re:my seemingly eternal question:

[Fastolfe]

I hope you're talking about the Linux or OS X version, because otherwise you're talking complete balls.

Please re-read the parent post.

Re:my seemingly eternal question:

[cheater512]

Wouldn't your way mean multiple instances of Gecko?
And that would be very very messy.

Re:my seemingly eternal question:

[Chandon Seldon]

Consider this brute force solution: We know that the browser can handle running with one tab now. We know that the rendering engine can be embedded in other browsers with different tabbing setups. They could just embed separate instances of the rendering engine in each tab. Sure, they might have to redo some of the UI. Sure, it would take a ton of RAM. But... it would work, and it would be multithreaded, and they could tune it to have shared data as needed from there.

Re:my seemingly eternal question:

[Tim C]

It's the fault of the PDF reader that the entire browser freezes while a single tab opens a PDF?

It's the reader that's freezing, true, but that shouldn't render the rest of the browser unusable, and it wouldn't if the browser was properly threaded.

Re:my seemingly eternal question:

[Chandon Seldon]

Why not split things out into multiple javascript interpreters then? Why does per-tab javascript even *want* to run in the same interpreter as UI code?

It feels like a lot of design tradeoffs were made in Mozilla that trade 100k of RAM for like a second of UI latency. Bad deal.

Re:my seemingly eternal question:

[rs79]

Opera started doing that with slashdot the day slashdot changed to be one big table. It didn't
used to be this way.

What I do to get aorund this is code in two tables, a small first one and the rest in a second one so browsers can display something while the page is loading. The problem with tables is the browser can't render it till it's read all of it in.

Re:my seemingly eternal question:

[Carewolf]

Separate process for NetscapePlugins, that's how they work. Separate process for I/O, that's also pretty standard when using Caching.

The rest seems to be silly stuff WebCore is using to created Qt-like timer events, but the events will still be executed in the main thread after being signaled.

So nothing that Firefox doesn't also do.

Memory Hog

[MrSteveSD]

I just wish they'd fix the memory situation. I shouldn't have to jump through hoops to stop Firefox consuming 200 megs of memory when I only have one tab open. It's been that way for as long as I can remember and I've used it on several different machines.

Re:Memory Hog

[yakumo.unr]

i've use it on several machines, both straight from install, and with adlbock, filterset.g updater, webdev toolbar installed, never seen it anyhere near that unless I have a seriously huge amount of tabs open.

Re:Memory Hog

[yakumo.unr]

I meant to say from firefox 1 beta's, through various final builds of 1, 1.5 and 2.

Re:Memory Hog

[Anonymous Coward]

Firefox isn't .net.

also it's a memory hog on EVERY platform.

Re:Memory Hog

[jsoderba]

The Windows virtual memory manager swaps out minimized applications. This has nothing to do with the way the app is written.

Re:Memory Hog

[Anonymous Coward]

It stores the last 10 (?) pages in cache, if you're viewing *cough* galleries it's the images that are consuming your RAM. I've had memory usage over 500MB and heavy swapping... err...

Re:Memory Hog

[CastrTroy]

What are you doing? Opening up a 150 MB XML file in that one tab? Seriously. I know Firefox has some memory problems, but that is not anything like I have ever seen. Most of the actual "leaks" i've seen involve flash and web pages that continually add stuff to the DOM with javascript and leaving them open overnight. I haven't seen many other huge memory problems. I've had Firefox open for days and have browsed to hundreds of pages and I'm still only using 132 MB.

Re:Memory Hog

[xipietotec]

Firefox with all my extensions and everything turned off starts at about 60mb's. And it grows. Having more than one tab open especially helps grow firefox. As it is I have about 40 extensions and a theme running (most of my extensions are actually to change the default UI of firefox itself). Worse, opening more than 1 tab will cause greater and greater memory leaks, flash or no. In fact, opening flash or java at all actually increases ram useage in a one way street. E.g., closing the page does not actually decrease ram usage that much. As it is I regularly have about 15 tabs open in firefox at minimum. My record is getting firefox to eat up over 600mb's of ram, I left it running by itself for a few days. As it is, I kill it at least once or twice a day. Beryl is like this too btw, once every few days I have to kill beryl and emerald because of memory leaks. I gave up on kiba-dock and went with the slightly less functional and occasionally buggy Avant-window-navigator, as kiba-dock works like this too! I had kiba-dock running for 3 days (it normally uses maybe 4-15mb of ram) and it had ballooned to 300+mb's of ram usage.

If I wasn't so attatched to my favorite extensions I would drop firefox in a heartbeat for epiphany or Opera if Opera was open-source.

Re:Memory Hog

[Sergeant Pepper]

Firefox caches things in your memory if the memory is not being used. If you try to run something that needs that memory, you'll see Firefox' footprint drop as it releases it.

This is a good thing; it prevents you from having to load frequently visited pages multiple times.

Re:Memory Hog

[gbjbaanb]

and I'm still only using 132 MB. 'only' lol.

Re:Memory Hog

[Trogre]

That is most definitely NOT the case. Even on Linux, having a few tabs open for a few days causes memory usage >500MB. And that's not misreporting since the whole system starts swapping and being terribly unresponsive by about this point. Restart firefox and the problem goes away again for a few days.

Re:Memory Hog

[Trogre]

At least it would be, if it were true.

Unfortunately it doesn't work that way. Try to load another large applcation and Firefox is pushed out to swap. Alt-Tab back to Firefox and you're in Heavy Swap Land (population: you).

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.

Re:Memory Hog

[bunratty]

Yeah, only. You can get Opera and IE to use more memory than that within just hours.

Re:Memory Hog

[bruno.fatia]

I think 640k should be enough for any browser..

Re:Memory Hog

[Skeith]

Firefox 3 fixes the memory usage very well. Since its alpha the memory usage changes rapidly but the build I tested used identical, and sometimes less, amounts of memory on windows.

Hope Breakpad is better than old system

[Mathinker]

I'm glad to hear that they're finally replacing their proprietary crash report system. The old one never worked for me at my work, and without it working no one at Mozilla was interested in any of my bug reports (OK, actually only one).

Re:Hope Breakpad is better than old system

[BenoitRen]

It wasn't even their idea. Breakpad, formerly airbag, was started by SeaMonkey and Camino people because they couldn't use TalkBack on tinderboxen (building machines) that weren't owned by the Mozilla Foundation, since it's proprietary, etc.

So it kind of angers me that now they're benefitting from it when they didn't do anything for it, and left other projects in the cold when it comes to crash reports from non-trunk versions.

Places

[morgan_greywolf]

"We haven't figured out how to make Places lose data."

rm -rf .mozilla

Re:Places

[WhyDoYouWantToKnow]

Come on, that's hardly a cross platform solution.

Re:Places

[morgan_greywolf]

Sure it is. It works on Linux, NetBSD, FreeBSD, AND OpenBSD!!!

(For Mac OS X, rm -rf ~/Library/Mozilla)

Re:Places

[sunami88]

Come on, that's hardly a cross platform solution.
Don't worry, I'm sure they'll "somehow" find a way to port it before it is released.

Alpha?

[FlyByPC]

There's just something about hearing "Alpha" and "browser" in the same sentence that's scary. The *release* versions are dodgy enough, even in Firefox.

I'll wait, thanks.

Re:Alpha?

[RedElf]

It could be worse, it could be I.E.

Re:Alpha?

[rayvd]

True. :-) However, I've been using Gran Paradiso for the last 3 or 4 months now as my primary browser. It does crash once in a while, but the session recovery works very well and the new Gecko engine is just much speedier (especially for large tables) than Firefox 1.5.x/2.x. Worth it for me.

Re:Alpha?

[XnavxeMiyyep]

The alpha browser gets the first choice of mates. Don't be a beta browser!

Password managers

[BendingUnit]

I still don't fully trust a password manager. Seems like having all my passwords in a single file isn't a good idea. Maybe I am just a caveman.

Re:Password managers

[joe 155]

yes they are insecure, but someone needs to break into your computer before they can have access to it - and if they've already broken in it wouldn't be too hard to install a key logger.

If password managers allow you to have strong passwords and different ones for each thing then they give more security than they risk, I think.

Re:Password managers

[ryants]

Seems like having all my passwords in a single file isn't a good idea. Maybe I am just a caveman.

"... put all your eggs in one basket and then watch that basket."
- Andrew Carnegie

Re:Password managers

[RedElf]

Seems like having all my passwords in a single file isn't a good idea. Of course it's a good idea if they are the passwords for important things, like the login to your 401k, bank accounts, etc. Then all you need to do is post that file here under the GPL v3 and we'll keep it safe for you.

Re:Password managers

[buswolley]

Key-loggers yes. Having you passes in a pass manager should help minimize damage from a virus installed key-logger.

Re:Password managers

[sconeu]

Hey, would you say that "even a developer can do it"?

Re:Password managers

[gbjbaanb]

When you get a fax, do you wonder if there are demons inside the fax machine typing it? Damn demons! This explains why it takes so long for the fax to come out and why its always fuzzy and at a slight angle - why can't we have angels in these machines? then my faxes would appear as shining gold, crisp, easily read script, and the spam adverts would be replaced with wittily crafted jokes.

Re:Password managers

[gbjbaanb]

try out keepass, which has features that defeat even keyloggers (who would only get a ctrl-v message).

Actually, come to think of it, why doesn't Mozilla take the keepass code, compile it in to firefox, and put a different ui on it? How much easier would that be than writing a new one from scratch, that won't be as quick to develop, good, or as secure.

Re:Password managers

[BZ]

They couldn't legally do it even if they wanted to, at least without explicit permission from the keepass developer. keepass is licensed under the GPL. Mozilla code is licensed under a more permissive license (once that gives you the choice of treating the code as being licensed under the GPL, LGPL, or MPL). As a result, using keepass in Mozilla code would be a license violation (e.g. it would amount to distributing keepass as LGPL if someone uses the Mozilla code under the LGPL).

Gotta love licenses. ;)

he

[El Lobo]

[blockquote]"We haven't figured out how to make Places lose data."[blockquote]

Yes, because it is too easy to lose data using normal bookmarks....yeah, right.

Re:he

[Looshi]

Actually, I've lost my entire bookmarks file a number of times in Firefox. Once was due to my own mistake, but a couple of times the bookmark file actually got corrupted. I'm looking forward to a new more efficient bookmark system

Losing Data

[Anonymous Coward]

"We haven't figured out how to make Places lose data."

Call the Microsoft Office Design Team. They'll help you with that in a snap!

Small changes are a good thing

[Wicko]

I think its a good idea they aren't throwing some giant new feature into the next version. Might be a good idea to just have a basic browser, and use addons for features you find necessary. And they could develop their own addons as well, for those who might not trust user submitted addons.

Re:Small changes are a good thing

[toleraen]

Gecko 1.9 isn't exactly a small change. The big changes are in there, they're just in the back-end of the browser.

No Places for Me

[esconsult1]

I've discovered google bookmarks, and nothing beats bookmarking at work and going home or using the laptop to pickup where I left off. Places is a quantum leap behind that. You can use del.icio.us bookmarks and that toolbar too. Unless all you ever use is a single computer, I really don't see a good reason for Places. Using Places is like paying per minute for domestic long distance, you can do it, buy why?

Re:No Places for Me

[jswigart]

Why wouldn't google bookmarks or others be able to simply upload the new database file? Is it correct that it uses an sqlite database? It would be trivial for these shared bookmark extensions to upload that or to inject what they do upload and download back into the database. It's not a competition, google bookmarks is a supplemental feature afaik.

Re:No Places for Me

[Wicko]

Foxmarks may be of some interest for you. Although with Google Bookmarks you probably have cross platform support.

Re:No Places for Me

[toleraen]

Call me paranoid, but I don't want my home bookmarks mixed in with my work bookmarks. Nor do I want to go home and have work staring back at me. Separation is good.

But if you want there are add-ons that sync your places bookmarks with your del.icio.us/google/etc bookmarks. So really it's helping facilitate the use of those services.

Re:No Places for Me

[Ctrl-Z]

Using Places is like paying per minute for domestic long distance, you can do it, buy why? Pardon me? How is it anything like that at all? I don't have any problem paying per minute for domestic long distance. If you don't make a lot of long distance calls, it can be cheaper than a flat-rate plan. But, I guess I also keep separate bookmarks at home and work, so maybe you are onto something.

Re:No Places for Me

[daeg]

Places has a lot more capabilities than just bookmark organization.

Places also introduces the ultra-compact SQLite into the bookmark and history arena. Hopefully as adoption of SQLite continues we can see less Mork files and other file types in the Mozilla applications.

As a system administrator, it would be completely awesome to integrate directly with my users' SQLite files, introducing bookmarks at logon, reorganizing them at logon, etc. Currently I have to parse HTML files and other such atrocities.

And before you scream that a SQL engine is bloat -- SQLite is obscenely small and compact.

Re:No Places for Me

[RobertLTux]

nicd try but you do know that you have to choose a pin for google sync for a reason (and it does some sort of encryption also)

DId they fix the print bug?

[lhouk281]

Have they fixed the print bug that drops the content of webpages when they are longer than one sheet of paper?

I don't care about new features

[Anonymous Coward]

I want to know if the geriatric, yet debilitating, bugs have been fixed. For example, bug #154892, "splitting absolutely positioned frames" that prevents people from printing many web pages from Firefox.

I'd also like the developers to think about the little subtleties that, as a Mac user, I take for granted from other applications. For example, when Firefox creates a new window it shouldn't be falling off the bottom of the screen.

Also, why does Firefox insist on displaying two different Mozilla pages after Firefox has been updated rather than just displaying my regular start page? This is rude and insulting. It does nothing for me. Finally, after 45 minutes with Google, I did figure out how to effectively disable this "feature" (about:config then change the keys named startup.homepage_welcome_url and startup.homepage_override_url to my regular start page) so that I merely get two start pages instead. (BTW, this "feature" cannot be disabled in Camino -- it appears to be hard coded in to the application bundle.)

There are many things I like about Firefox, specifically several extensions, but other things like those mentioned above that routinely drive me nuts -- I could keep listing them, but will spare everyone.

I would like to kindly suggest that the Firefox developers sit down and fix the irritating quirks, ancient bugs, and brain dead behaviors before adding new ones.

Re:I don't care about new features

[Tickletaint]

It's never going to happen, at least not with the current crop of Firefox devs. They can solicit for suggestions as much as they want, but the fact is that if they have to ask, they'll never know. As long as all the developers come from a PC heritage—even the Mac developers—the OS X version of Firefox is going to feel like a port from Windows/Linux land.

I'd suggest Safari loaded up with extensions as a good alternative. If you absolutely must use Gecko for some reason, even though it's bloated and less standards-compliant than WebKit, there's always Camino.

Privacy, that's why

[Selanit]

Why prefer local bookmarks to Google Bookmarks, you ask?

Because what I choose to bookmark reveals a good deal about me, and I'd prefer not to hand that information to a corporation. Even one whose motto is "don't be evil."

The article mentions that the Mozilla devs might integrate their own bookmark synchronization code straight into Firefox. I might consider using that, as long as I can set it up to use MY server for storing the data.

Good idea...

[eddan]

Quote from the blog entry on the new password manager:

The first part, a long slog of untangling and porting the old C++ code to JS, is now complete. Now, THAT sounds like something you want to do. I always mock up something quick in C++ and port it to JS afterwards.

Re:Good idea...

[kazade84]

Hell no, if I want speed and efficiency I mock up in C++ then develop in VB....

Honestly, how is that a step forward? No wonder Firefox gets slower with each release.

Linux does not crash anyway.

[Marcion]

The fact that crash handling system does not support Linux yet is not a big problem. I have used Linux distros for five years as my main system, and I use computers __a lot__ each day, and I never had a unrecoverable freeze-up or crash like in Windows, I have had other problems of course, but I have had never had Linux crash. I have also had Firefox instances open for weeks with no trouble.

No if they could make it look less ugly and more native on GNOME, that would be nice.

Re:Linux does not crash anyway.

[Chandon Seldon]

Create a file named "freeze.sh" with the following contents:

bash freeze.sh &
bash freeze.sh &
bash freeze.sh &
sleep 10h

Run it, count to 100, and then fix it without rebooting.

Re:Linux does not crash anyway.

[morgan_greywolf]

Okay.

$ ulimit -u 1024
$ cat >freeze.sh
bash freeze.sh &
bash freeze.sh &
bash freeze.sh &
sleep 10h
$ chmod 755 freeze.sh
$ ./freeze.shfreeze.sh: fork: Resource temporarily unavailable
freeze.sh: fork: Resource temporarily unavailable
freeze.sh: fork: Resource temporarily unavailable
freeze.sh: fork: Resource temporarily unavailable
freeze.sh: fork: Resource temporarily unavailable
freeze.sh: fork: Resource temporarily unavailable
...

*starts new terminal window* on original terminal hits ^C

$ pkill -9 -f freeze


On original terminal:
./freeze.sh: line 4: 29062 Killed bash freeze.sh ./freeze.sh: line 4: 29064 Killed bash freeze.sh ./freeze.sh: line 4: 29065 Killed bash freeze.sh

$ ps -ef | grep freeze
morgan 388 32583 0 09:12 pts/4 00:00:00 grep freeze


Never rebooted.

Any questions?

Re:Linux does not crash anyway.

[Chandon Seldon]

ulimit -u 1024

Cheater. Yes, Linux gives you the tools to prevent that code from being a problem. There are other examples I can give, and most of them have counters. My point is this - Linux, as it comes out of the box, can be made to freeze up by misbehaving user code. With the default settings in most Linux distros, the code I gave you will result in such a freeze.

Nothing to see here.

[the_kanzure]

Maybe it is time that we seriously discuss the state of browsing the world wide web and suggest some new browser features to implement, not just "bookmark tagging". Can't we come up with something to increase browsing productivity more than "bookmark sharing" ? Brainstorming in groups is useful in this situation.

I use the Opera browser to open up 200+ tabs in one single session at a time, and it would be useful if they implemented more session management, such as the ability to add tabs to specifically saved sessions. Same goes for Firefox.

Let's increase the number of pages that we can view per day. When you look at the numbers, we view a surprisingly small percentage of the content available on the WWW re: nearly any subject. The fact that the limit to the number of tabs that can be opened in one active browsing session is somewhat dependent on how much the browser can handle at once seems silly- cached tabs and an ability to predict which tabs the user might pull up next would be useful (though no fancy prediction algorithms, that would be too much).

There is a suggestion on the Opera discussion boards about a "rush mode" for viewing tabs such that you can strategize which tabs you are to go to next when you close the current tab. That would be a useful plugin to implement. Speaking of which, where do we draw the line between plugin and component to distribute with the browser?

The web history features can also be improved, perhaps graphical illustrations of the pathways through the world wide web would be an improvement, such that there is no longer this linear time dependency, when in truth we go through many tabs and have many separate histories building at once. There's lots of information being lost in current history tracking.

And, does anybody else use browsers as extensively as I do? I would be interested in meeting with some of you and discussing strategies for increasing web browsing and content consumption rates.

Re:Nothing to see here.

[buswolley]

I would like a way to organize my tabs into trees(2 dimensional) This way I can create a logical organization to the pages I've found and how they relate

Re:Nothing to see here.

[tqft]

"
And, does anybody else use browsers as extensively as I do? I would be interested in meeting with some of you and discussing strategies for increasing web browsing and content consumption rates."

Most of this are things that could be done with Places - charting your path etc.

http://wiki.mozilla.org/Places

Rush mode is interesting as dialup user atm I know what is like to wait and then have to find something quickly and have to wait and wait. FF 3.0aX has a drop down box for listing the tabs open/being opned - so the first part of the problem is solved. Now just to separate the box and allow work on it - maybe talk extension here because playing with the internals of what gets prioritised sounds like a nasty job on any one problem - but multiplatform.

Re:Nothing to see here.

[the_kanzure]

Tab trees

Yeah, and it would also be useful to integrate queues and session management with this sort of tab trees, such as migrating a branch towards the history archive, or queueing up numerous links to go explore at some later date. Maybe more useful would be the ability to restructure the currently opened content (either the paged content or the tabs themselves) via some quick Javascripting, to account for whatever new forms of information we find on the big WWW. There is little difference between opening up new tabs and forking attention, so the adoption of ideas from kernel memory management could work. (Go bug Massalin?)

Re:Nothing to see here.

[the_kanzure]

Drop down boxes are not appropriate. Side panel scrollbox of opened tabs is the way to go. Firefox has plugins that allow for vertical tabbing and there is native support in Opera.

Re:Nothing to see here.

[tqft]

or right click on the tab and change it's priority.

but the first hard part is done - functionality that exposes the opened tabs.

"Side panel scrollbox of opened tabs is the way to go."
I think this argument was actually had quite loudly during the initial development and basically decision was extension it if you want it - I could be wrong it was a long time ago.

Ummm, no.

[SEMW]

Yeah, yeah. Most likely, you are falling victim to Windows' misreporting of memory usage. [...] Try this: in Win XP or 2000, look at a piece of software that has been running for a while. go to task manager and look at the memory "used". Minimize the piece of software. Look at the memory usage again. Amazingly, it will have dropped dramatically. Well, yes. If you've minimized a program, the chances are you're not actively using it at that moment, so it makes sense to swap some of the memory that program is using out to the pagefile, to make some space for whatever programs you *are* actively using.

There's a solution if you consider this a bug: in about.config, create a Boolean pref called "config.trim_on_minimize", with a value of "false". This will just tell the OS to not trim memory usage when you minimize Firefox. The downside of this is that the rest of your machine will be much slower when you're not actively using Firefox than it would otherwise, because it's hogging a load of memory even though its minimized.

Personally, I'd leave the OS default behavior alone; if Firefox is minimized it doesn't need to keep a load of crap in memory just because you're uncomfortable with the concept of memory management. In the meantime, stop spreading FUD.

Re:Ummm, no.

[MyLongNickName]

Not FUD. This doesn't apply to Firefox, but you can see how it works with .NET assemblies here: http://www.itwriting.com/dotnetmem.php

Windows does not accurately show how much memory is being used by applications using managed memory.

Re:Obligatory Star Trek 2 quote

[Procyon101]

Firefox alpha-6 segfaulted 6 minutes after it was installed here. Breakpad never bothered to report our progress. It was only through the power of my superior intellect that I was able to install a previous build.

Re:bloat bloat code your bloat...

[fullphaser]

merrily merrily merrily, bug free is but a dream

Re:Does it pass ACID2?

[aengblom]

Firefox 3 includes Gecko 1.9, which passes Acid.

Cute

[Anonymous Coward]

I guess It'll be easier to maintain, mostly UI, events, interface to security components and storage. It's perfect for scripting. Also I gather the longterm plan is to merge in the Adobe tamarin code, meaning script will be JIT compiled.

I remember a similar comment to yours from the KDE guys, but just looky at all the extensions firefox has. Frankly, given the performance of KJS compared to poor old spidermonkey, I'm not surprised they felt a need to mock something.

How about fixing some long standing CSS bugs?

[Mad Merlin]

It'd be nice to see some progress on :nth-child() support and positioning for generated content support. Konqueror supports both of these already, and it'd be nice to have feature parity there. Don't bother mentioning IE, because I don't care about IE.

Re:How about fixing some long standing CSS bugs?

[Kelson]

Well, you could always look at what they have added to CSS support:

• The display property's inline-block and inline-table values are now implemented.
• The font-size-adjust property now works on all platforms; previously it was only supported on Windows.
• rgba() and hsla() color values support (bug 147017)
• :default pseudo-class support (bug 302186)

Mod Parent up

[xipietotec]

way the hell up, I second, third, and fourth. We have quorum, put it in the minutes.

(I has no karma lest I'd do it myself)

Cold Case

[bunratty]

I just wish they'd fix the memory situation. I shouldn't have to jump through hoops to stop Firefox consuming 200 megs of memory when I only have one tab open.

What memory situation? I keep asking for details about it, and no one can seem to give any. When I have one tab open in Firefox, it usually uses less than 100 MB of memory, and often less memory than other browsers. For example, with this page open, Firefox 2.0.0.4 has Mem Usage of 29 MB and VM Size of 20 MB, Opera 9.21 has Mem Usage of 34 MB and VM Size of 32 MB, and Internet Explorer 7 has Mem Usage of 28 MB and VM Size of 21 MB.

If you're seeing Firefox use more memory than other browsers, please explain in detail what you're doing to cause it to use so much memory, and then the problem can be investigated and fixed. Until then, there isn't anything to go on. It's a cold case.

Are you by any chance..

[Anonymous Coward]

Paris Hilton?

Breakpad? Are you kidding me?

[DogDude]

How about instead of spending time writing software the handles all of the bugs/crashes better, actually FIXING the damn bugs? I don't understand why this relatively slow-moving codebase is still so riddled with bugs. If not for Adblock, I'd be using IE!

Last One Please

[bill_mcgonigle]

If everybody posts their favorite bug to every story about Firefox then the moderators have too much work to do.

Re:Obligatory Star Trek 2 quote

[dkleinsc]

Glad someone got to it before I did.

Re:Does it pass ACID2?

[suv4x4]

IMHO, they should first focus on making Firefox 2.x pass ACID2. I'm using Opera 9.21, because it passes ACID2 and had the fewest security bugs. Web standards compliance matters, because non-compliance makes creating rich web sites a royal pain.

Passing ACID2? Is this sort of like passing GAS3, maybe?

While busy explaining how important standard are, you forgot to mention ACID2 isn't anything like an official standards test, and doesn't confirm standards compliance.

It just confirms it supports the features used in ACID2, in the precise context of the ACID2 page. Opera has rendering bugs and many unsupported features just like Firefox.

Why doesn't anyone port Dillo to windows?

[zymano]

Use dillo if you got linux. only 400k.

http://www.dillo.org/

http://sourceforge.net/projects/dillo/

Re:Why doesn't anyone port Dillo to windows?

[Kelson]

Remember, that 400k does *not* get you scripting, CSS, or plugins. You aren't going to be viewing YouTube with Dillo anytime soon.

Re:Why doesn't anyone port Dillo to windows?

[Anonymous Coward]

> You aren't going to be viewing YouTube with Dillo anytime soon.

Bonus!

Re:Why doesn't anyone port Dillo to windows?

[MrNormS]

Might as well just use links/elinks/lynx.

Re:Why doesn't anyone port Dillo to windows?

[gerrysteele]

pah, might as well just use telnet

Re:Why doesn't anyone port Dillo to windows?

[Sodki]

There is Dillo for Windows: http://dillo-win.sourceforge.jp/

Contributing Corporations

[obender]

Out of curiosity I did a find and grep on the source tree to see what companies contributed to the code base. I have to say there is at least one I did not expect. Here they are in no particular order:

IBM, Intel, Oracle, Mozilla, Microsoft, Netscape, MITRE, Digital Equipment, Novell, Activestate

I looked for the Microsoft code and it was just stuff copied from the SDK samples. Still, I did another count:

find . -name '*.c*' -exec grep -i Microsoft {} \; | wc -l
332

I would be really curious to do the same search on the IE7 code base, this time looking for Mozilla

Re:Contributing Corporations

[SpaghettiPattern]

find . -name '*.c*' -exec grep -i Microsoft {} \; | wc -l

Buddy, you just counted the lines that contain microsoft. Without doing an actual analysis myself I take most lines will be code and comments for/on compatibility with MS targeted sites/pages. I don't expect MS to actually contribute to FF since they have a competing product.

still crapppy mac ui

[coaxial]

Up and down arrows still activate the dropdown in the location bar instead of move to the front and end of the typed text like on every other mac application in existence. Won't use it until it's fixed. Can't use it until it's fixed.

And fan boys, don't try and say that it up and down arrows are stupid, that's irrelevant. It's platform convention. Don't say that it's impossible to use a drop down without binding activation to the down arrow. Safari does it just fine.

Re: bloat bloat code your bloat...

[Dolda2000]

I'm glad that opinion hit the first post, because it was my first reaction after reading the summary as well -- "Wow, lot's of new features. So, what about the bloat?"

On my system, Firefox is easily the most memory-hungry process. I actually have to restart it every few days to make it stop eating all my RAM (although as of a few upgrade ago, it seems to be taking care of the shutting down automatically... :/). The one reason I'm using Firefox is thanks to the plugins (in this case, SessionSaver is extra good), but even so, I've been thinking quite seriously about switching to Opera instead. Free Software enthusiast as I may be, I do value technical merits as well, and Opera does seem to be doing very well (or at least a lot better) on that point.

I realize that it probably isn't all that easy to write a good web browser, but I also cannot help thinking that the fact that the entire UI is written in XML and JavaScript doesn't exactly help. I have been thinking very seriously about starting to write my own web browser (I can't really say I care if many websites don't look correctly), but I've been running into stumbling blocks when it comes to the documentation of certain web standards. In particular, I cannot find any exact specification of exactly how things such as CSS "float"ing elements are supposed to be treated (as far as I've been able to see, the CSS specification just says that they are "taken out of the flow", whatever that means). If someone can point me to reliable documentation on that, I'd be really happy.

Re:Breakpad? Are you kidding me?

[Kelson]

RTFS. Breakpad isn't just for crash recovery, it's for crash reporting. It should improve the information they get on the bugs, including bugs they didn't already know about, which should make it easier to fix them.

Re: bloat bloat code your bloat...

[Anonymous Coward]

Surely you're joking; do you have any idea in what's involved in creating a layout engine from scratch?

Libcroco is used in Inkscape and there's been talk of restarting development. Gnome have a skeleton of a browser based on Apple Webkit (khtml derivative) in their CVS somewhere and then there's the dillo codebase;

A web browser is too complex a task to develop on a part time basis, and it also is a fast-moving target. I dedicated seven years full-time to it, and I'm willing to dedicate more. This doesn't depend on me anymore as I had to take a job to pay the bills. We made great achievments with Dillo and it would be easy to quickly push FLTK2-Dillo if we could have both core developers working full time on it. This is a tiny deal for some sponsors (e. Cell phone maker), and we wish it could happen soon. Through this time we've been supported by individual's donations, and we thank them indeed for believing in our project and to help make it grow to what it is.

If you as a reader, or user, or interested party have a good idea, sponsorship or development time to devote, please don't hesitate to contact me to try to arrange for the future of Dillo.

The flow of a document is the flow of a document with respect to behavior of inline/block elements and the box model. Basically it's how text wraps around an image. If you don't get that floats remove an element from the flow, you aren't going to be writing your own browser any time soon.

Re:bloat bloat code your bloat...

[ampathee]

I'm getting pretty sick of this kneejerk comment to any firefox related story. Seriously mods, that was insightful?

Leak Monitor Extension

[bunratty]

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.

The leak monitor extension is for finding memory leaks in extensions, although on rare occasions it can find a memory leak in Firefox itself. If that extension is often reporting leaks, you almost certainly have an extension with a severe memory leak, such as one of the problematic extensions listed in the MozillaZine Knowledge Base. If you can get the leak monitor extension to report a leak even when you have no extra extensions installed beyond what comes bundled with Firefox 2, please give a set of steps to reproduce the leak so someone can write a bug report.

Yes....

[Ayanami Rei]

Yes. All XUL browsers have a single-threaded javascript instance running the interface.
No. Safari's javascript engine is not multithreaded among open windows/tabs (but the interface is).

It would benefit all browsers if multi-threaded javascript were possible, and the event model kept "document" (i.e. window/tab) centric with cooperative event dispatch being the rule there unless otherwise specified in the language (for backwards compatibility).

Re:bloat bloat code your bloat...

[Goaway]

They know it is insightful because it was modded as such all the other times it was posted on Slashdot.

The future is not that bleak.

[Ayanami Rei]

Spidermonkey has (simple) patches to support threading. While there's no built-in language primitives for it the core was almost already threadsafe anyway... it just needed an interface.
I've actually played with it in jsext and I was kind of surprised.

Of course it's not so cleanly implemented as in java with monitors and critical sections being a language component. You have to interface objects that wrap stuff if you want to share mutable data between threads.

Nevertheless it would be a quicker fix for Firefox if they just had the core spawn off threads that handled the event loop for each document root (open window, tab, frame). And shunt off cross-document calls into a message queue in another thread for dispatch (same thread could be used to take messages from the interface and route them into the windows)

Meanwhile the event-trigger javascript running in each document would look at act single-threaded sequential and not know anything was different.

Re:The future is not that bleak.

[BZ]

The problem with this approach is that it violates the synchronous run-to-completion semantics web code assumes. In particular, shunting off cross-window function calls through the event loop would lead to races in web JS code, which is absolutely expecting everything it can see (including things it opens via window.open) to be running in a single thread.

Combined with the fact that in Firefox web and non-web JS are both around and that non-web JS can touch all objects in all open windows, threading things becomes a bit of a pain...

Re:The future is not that bleak.

[mikefe]

Then enforce run-to-completion within each "site" boundary.

Javascript isn't supposed to be able to call code in other sites, so make the thread boundaries the same as the site boundaries.

Re:The future is not that bleak.

[BZ]

Site boundaries are not immutable: see document.domain. And there are ways for script to request expanded privileges that allow cross-site access; see enablePrivilege.

Re: bloat bloat code your bloat...

[cheater512]

I've never had a problem.

Seamonkey is at the moment chewing on 113mb of ram and thats with 17 tabs open and 25,000 emails in my Inbox (and much more in other folders).

I wouldnt go as far as saying its lean but imho thats pretty good.

Use Camino.

[Ayanami Rei]

Firefox runs its own UI/user-experience engine. The whole XUL bit. Keypresses enter the front and they get treated the same on every platform. There are no isOS="MacOS" checks in the keyboard code in Chrome to determine what to do if you press up or down. It does the same thing everywhere.

So, use Camino. It uses the Mac UI and just renders using Gecko.

Re:Use Camino.

[coaxial]

No point. I have safari.

Re:bloat bloat code your bloat...

[Lorkki]

I agree. Bloat is such an easy word to just throw around, especially since it seems that you don't need any justification to use it anymore. I'm quite certain that the GP doesn't have the faintest idea of how the new implementations of these old features compare to their previous equivalents - on the other hand, there's long been a consensus that bookmark management needed an overhaul.

But I guess that's how it goes when you get popular enough. Improve or not, someone's going to hate you anyway.

Re:Breakpad? Are you kidding me?

[jesser]

Breakpad doesn't have anything to do with crash recovery other than including a "Relaunch Firefox" button. Firefox's session restoration is a separate thing.

Re:Does it pass ACID2?

[BZ]

Passing ACID2 is not just a matter of a few minor bug-fixes. There was a fundamental architecture problem that needed to be fixed to pass the bit that was failing; this took several years of work on a branch to resolve and involved largely rewriting the code that does actual layout of the web page. That sort of change is not going to happen in the stable builds based off Gecko 1.8 (Firefox 1.5 and 2).

Re:bloat bloat code your bloat...

[ampathee]

So, Firefox sucks because of OpenOffice.org and Thunderbird? Gosh, that makes sense-a-plenty.

Anyway, I'm not saying the argument couldn't be made that ffx is 'bloated' (don't believe it myself, but there are plenty of people who do). However the OP failed to make any kind of coherent argument - he just made up a silly little rhyme parroting the popular opinion - therefore, NOT insightful.

Re: bloat bloat code your bloat...

[HeroreV]

the entire UI is written in XML and JavaScript doesn't exactly help. I have been thinking very seriously about starting to write my own web browser

It's completely insane to write a new web browser just because you don't like how the UI of Firefox/SeaMonkey is implemented. First of all, Gecko doesn't have to be used with XUL. Galeon/Epiphany, Camino, K-Meleon, and others all use Gecko to render web content while using traditional methods for the browser UI. Secondly, Gecko isn't the only open source layout engine. (Shock!) KHTML has better support for the web than any one-man project could ever have.

In particular, I cannot find any exact specification of exactly how things such as CSS "float"ing elements are supposed to be treated ... If someone can point me to reliable documentation on that, I'd be really happy.

http://www.w3.org/TR/CSS21/visuren.html#floats
Your post is completely ridiculous. You claim to be "thinking very seriously", but you obviously haven't done the slightest bit of research. You have no clue how much work it would be to write your own layout engine and web browser UI.

Re:bloat bloat code your bloat...

[Stalks]

..I didn't say that..
Yes, you did.

..argue that..
Yes, you did.

..or indicate anything close to that..
Yes, you did.

..Oh, I see you have been mod'd troll..
No, he didn't

Basically you made the point of Firefox playing catch-up with Microsoft, then cited examples of other OSS. Sort of like going off-topic in the same post.

Re:12 character freeze

[robzon]

3. Patent the patch

Ceti Alpha 5?

[josquint]

KAAAAAAAAAAAAAAAAAHHHNNNN!!

sorry.... couldn't stopy myself quick enough before hitting "submit"

Guess I'll be modded "Redunant" for that...

[Aleksej]

...but public IE releases never admit they are alpha!

What I was thinking...

[Ayanami Rei]

... is that scoping rules be leveraged to work around this issue.

Most code that I'm aware of that works with multiple document roots tends to interact with other windows by function calls (and sometimes grabbing references to "foreign" objects which it later accesses). I think the way to avoid race conditions in these cases is to have the js engine marshall access to these cross-window objects transparently through the reference (so that all property access is actuall get/set calls). And then to protect those functions with mutexes, and block the "owning" thread from execution while the foreign process is modifying its globals.

Using a separate thread deliver cross-calls (and UI events) would be best so that you can avoid deadlocks.

Not quite.

[Ayanami Rei]

Safari isn't XUL, sure (I didn't claim it was).

But KHTML widgets still only hook into a single javascript thread, no matter how many of them there are. The javascript has run to completetion semantics. (This is kinda assumed by, well, everything out there, Web 1.0, Web 2.0, etc.)

This is better for user interaction than XUL if only because non-javascript pages can't be locked up by javascript non-responsiveness in another tab or frame. But if your google maps mashup gets into a infinite event loop then its going to screw up your google mail in your other tab. (I proposed a cross-browser approach to a solution to THAT particular problem).

Re:Breakpad? Are you kidding me?

[luserSPAZ]

Hint: you can't fix crash bugs you don't know about (or can't reproduce)!