Firefox 3 Beta 3 Officially Released
firefoxy writes "Mozilla has officially released Firefox 3 beta 3. This release includes new features, user interface enhancements, and theme improvements. Ars Technica has a review with screenshots. 'Firefox 3 is rapidly approaching completion and much of the work that remains to be done is primarily in the category of fit and finish. There will likely only be one more beta release after this one before Mozilla begins issuing final release candidates.'"
While you're asking for it to be "faster", other people are asking for a smaller memory footprint.. considering that most performance issues in a browser are related to caching, they can't please all the users all the time.
How we know is more important than what we know.
High memory usage is different from memory leaks - every time you open a new tab it stores in ram some of the previous and next pages in ram. So if you do a lot of surfing on different tabs it very quickly goes up to 100MB in ram. You can disable that from the settings but you lose the ultra-quick back and forward capability.
Control is an illusion, order our comforting lie. From chaos, through chaos, into chaos we fly
I get them to work by setting extensions.checkCompatibility to false.
A few still refuse to work, but most do.
Now, can someone tell me how to keep my bookmarks always sorted by name? The two extensions I know of that do this job ignore my "don't check compatibility" instructions and still refuse to show up in the menus.
i am a soviet space shuttle
Exactly! You would think there would be some 'legacy plugin support' for people to enable if they so desire.
There is. Install the Nightly Tester Tools plugin. It adds a "Make All Compatible" button in your Add-ons dialog that does pretty much just what it says.
ZuluPad, the wiki notepad on crack
That's a user interface paradigm that's decades old now, and just because the bunch of monkeys coding IE think it's fun to throw it out the window doesn't mean it's a good idea. Microsoft has the anti-Midas touch for interfaces these days anyway (cf. Vista generally, that new Office abomination generally, drop-down menus that hide half their contents for no particular reason, etc.). Emulating them would be a terrible idea.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I'm hoping that they bring forward Tamarin support in Firefox. Any chance of getting fast javascript before Firefox 4?
Yes I do, but how many average users are going to know that? I'd be willing to bet that the Parent didnt even know that...besides, thats only one of many features that its lacking in comparison to Opera, Avant, etc. There isnt much coding invlived to add a context menu on right-click, or even a tooltip saying "Yadda Yada for Yada!"
The reason I want FF3 is to get whole-page zoom.
http://arstechnica.com/journals/linux.ars/2007/07/27/firefox-3-gets-full-page-zoom
I use a 110 dots per inch monitor. I hate, hate, hate all web pages that were laid out with WYSIWYG design tools, with fonts set to 7 pixels tall and columns also specified as a certain number of pixels wide.
I don't have eagle eyes and I don't like to sit close to my screen. So I have my personal CSS forcing fonts to a minimum size... which makes some pages ugly, and other pages unreadable (depends on how much the page designer hard-coded with pixel sizes). I'm also using the ImageZoom extension to scale up images... which means the scaled images cover up lots of text on many web pages, and fancy graphical navigation buttons often don't match up with their clickable regions.
And I have a 16:10 ratio monitor... which means that often I will read a web site and there will be a narrow strip of text in the center, and tons of wasted space to either side, again because some web designer hard-coded things with pixel counts.
I used to wish that web designers would make sites that can adapt to unusual screen sizes. Well, the WYSIWYG tools aren't going away, so now I just want to zoom my pages.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Mozilla Firefox, Portable Edition 3 Beta 3 was released a few hours after the announcement. It's packaged with a launcher so it runs self-contained so you can use it from a flash drive, iPod, portable hard drive, etc. But it's also handy for trying out the current beta without affecting your local install. You can even run it from your desktop to try it out and then delete it.
It's available from the Mozilla Firefox, Portable Edition 3 Beta 3 homepage.
Portable versions of Firefox, GIMP, LibreOffice, etc
Actually, the perceived performance issues of Firefox mostly stem from the fact it's a single-threaded architecture running on a JavaScript+XML interpreter (XULRunner).
There is indeed only one thread handling the UI and DOM, but there are multiple threads. Network operations, file decoding and so on run in separate threads from the UI. MAking a multithreaded UI is quite hard; note that IE (at least 6, most likely 7 too) does that too, with the difference that you can have separate windows in different processes altogether; but then they can't talk to each other through JS.
The only time this architecture is really a problem ATM is when JS from a page sucks up CPU: it bogs down the whole UI.
Moving to a fully multithreaded architecture is a very hard problem, esp. for such a complicated application, with such complex interactions as a web browser. Every single little thing would have to be synchronised, with big deadlock risks at each turn.
The only possible approach is to divide work among threads such as there is minimal, well understood interactions between them. You can't for example just have one thread per window, because HTML+DOM+JS expect to be able to touch other windows from the same domain. You could divide processes by originating domain; that's what Apprunner does.
But then you have coordinate communication between the windows and the bookmarks, history and so on. Not too hard to do, but has to be weighed against the minimal gain.
Eventually, we will have to take advantage of many-cores CPU. That means that even DOM parsing will have to be multithreaded, for use on ultra low power 256 cores mobile cpus. Robert O'Callahan is working on this. But what you have in this case is a number of related threads with a very limited scope, and precisely defined interactions.
You can read more on these issues at his blog:
Parallel Dom Access
Night of the living threads