Mozilla Firefox 1.5 Beta 1 Released 626
elfguygmail.com writes "Firefox 1.5 beta1 is out! It includes many new features including a new automatic update system, reworked options dialogs, faster browsing, new error pages, memory and stability updates. Get your beta at Mozilla.org."
Memory Leak appears fixed. (Score:2, Insightful)
Extensions (Score:5, Insightful)
I smell a need for backward compatibility
New Firefox...same goofy theme (Score:4, Insightful)
I'm also hoping that my memory leakage problems on linux are solved. We'll see! Now back to searching for the safarifox theme to see if it'll work...
Re:Incompatible, duplicate extensions (Score:5, Insightful)
It's a mozilla dictionaries problem, I think - the dictionaries (which spellbound doesn't provide itself) install into the Firefox application folder, rather than into your profile folder - so when you overwrite that folder, you've just nuked your dictionaries.
If this annoys you, you could always ask the spellbound devs to provide dictionaries that install into your profile
Users need it (Score:5, Insightful)
Re:Users need it (Score:4, Insightful)
You'd also have to stop and restart the browser, thus losing whatever page you were on when you decided to update. Here's hoping that the final versions will restore your browsing session after updating (similar to recent versions of Adobe Acrobat Reader). (Yes, I know about and use sessionsaver.)
Re:my big hope (Score:5, Insightful)
I agree 100%. There are often pages that I visit which take a while to load. I load them in the background in tabs, but the whole browser grinds nearly to a halt while they load. In fact, if a flash animation takes up lots of CPU in one tab, then all the other tabs, and every other part of the user interface sometimes locks up for a minute at a time. This is just sad.
My second big gripe is just general bugginess. Yes, it takes time to iron out bugs, but Firefox has had some time. Right now, we're on 1.0.6, and honestly I'd rather see them just spend 100% of their effort on a 1.0.7 that is as close to bug free as humanly possible rather than adding more features. I'm sure the features they're adding right now are worthwile overall, but I'd much rather stay with the feature set I have now and see all the bugs disappear. The worst one is something that seems to relate to perhaps an event queue. Every now and then, something will happen that seems to cause Firefox to just stop processing events. I can press buttons and hit Command-W (I'm on a Mac), and nothing will happen. But if I hold down the mouse button inside a window, somehow this rejuvenates the event queue and these events get processed eventually. Totally, totally weird.
The worst part is that it seems that flash animations use the same thread as the user interface. So if you have a flash animation that takes a LOT of CPU, which lots of them do, then the user interface becomes unresponsive. This is just silly. You're taking untrusted code (flash from whatever web site) and letting it take CPU time away from critical stuff like being able to close the window that contains the CPU-hogging flash code!
Re:Woohoo! (Score:5, Insightful)
Bugs is bugs!
fix the operating systems (Score:5, Insightful)
I am sick and tired of every application including its own update system. They all have different user interfaces, they don't handle dependencies correctly (e.g., Firefox may upgrade its own extensions, but not the download manager that they depend on), and they make random connections all over the Internet.
When will Windows and Macintosh get decent package and dependency management so that developers don't have to put this functionality into applications anymore, and that we don't have to put up with the security risks of many different update systems anymore?
Re:Users need it (Score:3, Insightful)
Re:Upgrade man (Score:3, Insightful)
Opera seems nice, but it's not customizable enough for me. I also can't compile my own, but have to use pre-compiled binaries that links against old libraries I don't even have installed anymore.
Regards,
--
*Art
Back (Score:5, Insightful)
Nice. Too bad its taken over 11 years for someone to optimize this in a relevant browser.
I'm not a browser developer so I've always wondered why browsers do not simply re-render what has already been cached when 'back' is used. I hit 'back' and I observe network activity even when the page is entirely 100% cacheable content. The browser is probably playing with If-Modified-Since... I'd rather it just render what's cached especially when, between the time the page was first rendered and the time I hit 'back' the network flakes out and, rather than simply rendering what is already faithfully stored on my local disk, the browser hangs!
It's not just inconvenient. It's wrong in principle; 'back' should be 'back to precisely what I received previously', not 'attempt to re-get whatever now appears at the previous URL.' If I want the page refreshed, I will use the provided 'refresh' button, mkay? Thanks.
There's probably some profoundly crucial and subtle reason for all this and I've foolishly revealed my ignorance. Apply the necessary flames, but only if you have credible answers.
What I want to know (Score:3, Insightful)
I like how it looks best in Linux, but I kinda miss the Windows version sometimes...with its speed and all. And I know its not Linux/Gnome- Epiphany flies. So does a WINEd IE. Only Firefox is slow. Will that be better?
State. (Score:5, Insightful)
So, the big deal here is maintaining consensual state. I'm sure you know the basics here. Best practice is to POST when changing state on the server, and GET when reading. But, not everone does that. And it also took a long time to come up with that simple rule. The upshot is that when using browser based C/S apps, there is no good way to tell if the last action changed the state of whatever it is you're looking at. (For a simple example, think of confirming a bank transfer, and hitting back from the "it worked" page.) And even the POST means change rule doesn't always work or apply. Good app design has to play a role, but a browser has no idea if what is going on with the server.
There are other reasons why back can't always be exactly "what you got a page ago", but the above is the main killer (from the perspective of what I do, at least). Developers can make this better by playing tricks with the last-modified header and whatnot, but you're either going to sometimes get broken info or at least do a HEAD when going back, take your pick.
It is notable that the whole AJAX obsession usually completely kills the back button, and many web developers are very hot on the idea. If global state, session, and sometimes transaction can be bound that much more tightly, it does make life easier for a coder, at the expense of some great client side functionality. (Again, depending on how you think of it.)
Doesn't mean I'm not using XMLRPC - I don't mind bragging that we were doing some of this a few years ago. Having a community to trade ideas with kicks ass, and I've learned a lot from other's experimentation. But we shouldn't lose track of basics, like "the browser is not just a window frame; inbuilt functionality is important and if you make your own back buttons, you're missing the point."
Re:Back (Score:3, Insightful)
Re:I hope it will turn out more stable... (Score:2, Insightful)
Re:FireFox web page in IE (Score:2, Insightful)
Re:Deer Park !!!!!!!!!! (Score:3, Insightful)
Re:Exactly (Score:1, Insightful)
Re:State. (Score:3, Insightful)
Actually, a web browser if first and foremost a window frame. From a user point of view, most web pages don't need any state information. I would suggest that the standards guys devise a tag or something to indicate when a page should NOT be rerendered without contacting the server. Most pages need not worry, but you web app guys would have to add this little tag.
I do agree though, that there are some things in common use that can't be handled with a back-cache. These are not in 90 percent of web pages. For developers just remember, it's MY browser not yours.
Re:Exactly (Score:2, Insightful)
Wrong. Many (most?) GC implementations don't bother to run a collection cycle at shutdown - precisely because the OS will clean up anyway, so there's no point.
GC provides no guarantees against a poor design hogging memory while the program is still running, and often doesn't work well with resources other than memory.
Oh dear, the old "it's not absolutely perfect so I will reject it out of hand" line. Yes, of course GC isn't a silver bullet. It's just another useful tool that makes it easier to write programs with fewer bugs in them. Yes, of course it doesn't magically remove every single possible cause of memory leaks. It just removes one large class of potential problems from the things the programmer has to worry about.
And yes, GC doesn't solve the problem of handling resources other than memory. RAII cleans up file handles and stuff for you too. That's nice, I admit it. But there are other strategies that can handle this in a GC language. C#'s "using" statement, for example. And I don't know about the code you write, but in the code I write, the vast majority of objects do not represent any resource other than memory - so GC handles them just fine, thank you.
If doctors were C++ programmers, we'd still have kids dying of easily treated diseases daily - after all, antibiotics don't cure viruses, so there's no point using them, is there?
Re:inline-block? (Score:3, Insightful)
It should be pointed out, however, that the reason why Internet Explorer has inline-block support is that it was a previously proprietary Internet Explorer extension to CSS, that was added to CSS 2.1.
Furthermore, CSS 2.1 is only a working draft at the moment, whereas some CSS 3 specifications are candidate recommendations, which means they are ready for implementing, but CSS 2.1 is not ready.