Slashdot Mirror
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. '"
...gently down the drain
- Andrew Carnegie
Ryan T. Sammartino
"Ancora imparo"
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.
Have they fixed the print bug that drops the content of webpages when they are longer than one sheet of paper?
www.timcoleman.com is a total waste of your time. Never go there.
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.
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.
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.
Actually, yes.
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.)
You are in a maze of twisty little relative jumps, all alike.
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.
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.
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).
If everybody posts their favorite bug to every story about Firefox then the moderators have too much work to do.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
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.
Yeah, only. You can get Opera and IE to use more memory than that within just hours.
What a fool believes, he sees, no wise man has the power to reason away.
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.
-- The act of censorship is always worse than whatever is being censored. Always.
Might as well just use links/elinks/lynx.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)