Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

With shards of broken glass embedded into the top of the wall...and machine gun nests on the other side of the wall...surrounded by a moat filled with sharks with FRICKIN' LASER BEAMS IN THEIR HEADS!!!

Sadly I think you are right. Looking at the latest beta it looks so much like a Chrome ripoff they may as well just drop Gecko for Webkit. I could understand if they made a change because it gave the user a feature that had been requested, but this strikes me too much like Cargo Cult Usability [piestar.net] where you just ape the other guy without really understanding the reasons behind the design and that just isn't a good sign.

I mean what are they gonna offer their users besides a "me too!" laundry list of appearance a

You should use the new JetPack API [mozillalabs.com] so you don't need to update your plugin every time a new version of Firefox is released. Better yet, release a plugin that tells all the other plugin developers to use JetPack.

that I don't already have? Just curious. I've looked at it a little, and it looks like building Plugins with javascript & HTML/CSS instead of pure XUL, but I'm already doing that with the next release of my plugin [mozilla.org]. It's easy enough to use the DOM to load custom HTML and insert it where you want. I've seen lots of these frameworks build up super complex stuff that'd be great if I was writing a complete application, but in the end it's just a plugin...

The SDK is designed to produce add-ons that will be forwards-compatible with future versions of Firefox, so you won't need to update your add-on every time a new version of Firefox is released. And SDK-based add-ons benefit from a security model that limits the harm that can be caused by a vulnerability in add-on code.

and

Users can install and remove SDK-based add-ons instantly, without a browser restart, making it easier to try add-ons and personalize their browsing experience. They also won't have to worry about add-on compatibility with new versions of Firefox. And SDK-based add-ons will soon load in separate processes, so slow-running add-ons won't slow down Firefox itself.

I tried making a simple addon with JetPack (a keyboard shortcut to go back to the most recent tab), and it turns out there's no way to set a keyboard shortcut with it. I'd wager that most addons use keyboard shortcuts, so that's a pretty major feature to be missing. The JetPack API seems to be in that state - it was developed because it's a good idea (and it is!), but nobody at Moz actually uses it, so it's missing basic features needed by real-world addons.

Nope. It was just on a whim because it was something I needed that moment. I brought it up in the IRC channel, the suggested solutions were well beyond the mental effort I'd earmarked for the task, and I moved on to other things. You're right though, I should file a bug.

Nah, there aren't enough of them for that. Firefox 3.5, even while being supported, is under 3% overall usage (for comparison the unsupported Firefox 3.0 that no one cares about anymore is about 1.5%; all figures according to statcounter; I bet other sources will have different numbers).

Then again, IE6 is 5% according to the same source.... but was 13% just a year ago (when Firefox 3.5 was 27%, by the way; this was before 3.6 was released).

No. I run 20+ extensions (about half for privacy and about half to have the user interface just the way I like it). Some (like verttabbar) are broken right now in FF4 even if you edit the rdf file. Small extensions do only need the MaxVersion adjusted but anything big is likely to have trouble.

As an aside, I am always very vocal about hating Opera because I have found it impossible to configure the interface just the way I like it (in some cases I want it adjusted with pixel precision and have just the righ

Geez, I've been on the FF4 beta for like 5 months now almost. IMO it's much better and stable. Almost all of my extensions work in it too.
If your extension doesn't work with 3.6, edit your install.rdf file and change the MaxVersion to 3.6 (or wildcard)

I've been using it since last march, and aside from some issue with non working extension when they did some big changes it worked fine and it's much faster than ff3

I've tried FF4 twice, both times letting it go in less than a week. It has been faster than 3.6.x but it has this horrible tendency to cause my plugins to stop working. I had a scenario in which I couldn't use Google Chat (in Gmail) to make calls out. It worked under Safari and FF3.6 but it kept telling me to download the plugins. Flash also stopped working and sites like YouTube wouldn't load. When I looked the plugins up via about:plugins nearly all my plugins had failed to be recognized by FF4, where all

If your extension doesn't work with 3.6, edit your install.rdf file and change the MaxVersion to 3.6 (or wildcard)

Nah. Just install the Add-on Compatibility Reporter [mozilla.org] plugin and help the beta effort. This add-on lets others run irrespective of the version, but then you can also rate the compatibility of all plugins and indicate if they work or not.

Ditto here - made the switch after Thanksgiving and have had very few problems - certainly nothing I couldn't deal with with a little googling or forum digging. All my extensions (with the exception of Fox Lingo) work fine - I hacked all the rdf files months ago.

This last release is fantastic, pages are rendered noticeably faster. I switched over my other computers (Ubuntu, Mint, Win XP and Win 7) around beta 9 and have had even fewer minor issues on them, probably because they don't have

Are you sure it's FF4 and not your extensions? I had to use FF3.6 for a bit a while back and couldn't believe how slow it was compared with FF4, and I think FF4 actually had a few extensions where the 3.6 install had just the default ones.

Yeah, kinda... it will warn you constantly and force you to make a decision on every start up. I'd kind of like something a little less obtrusive - maybe a little icon with an exclamation point or something.

I thought it meant that Mozilla wouldn't have more releases, period. I'm sure I'm not the only one who read it that way--a much better headline would have been "Mozilla to have faster release schedule following Firefox 4" or somesuch.

All they would have to do is call some of their betas number releases.

No. A beta release is (in general) bug fixes and improvements to existing code. They generally don't introduce swaths of new features, that's what the FIRST beta did, the rest are fixing problems with those features. The fact that they have had more than 11 betas of Firefox 4 is proof that what they are trying to do is necessary. They made 4.0 too big.

This is a trench op on the marketing side, to make pointy heads happy that Firefox can be in version 7 this year and version 10 next year. Apparently something pending about betas exhausted them.

They are going for more releases BECAUSE the betas exhausted them, and that's a good decision. What they are trying to do is go to a smaller, more focuse

But that's boring and informative (and correct) and certainly doesn't get you to go "wtf?" and click the story. Or comment on it and generate more traffic. It certainly doesn't lead immediately to insightful discussion by developers on release schedules, development cycles, and that sort of thing. You know, news for nerds. Stuff that matters.

Even AFTER I understood the headline the thought, 'Mozilla is imploding like Netscape did, with stupid browser decisions,' was still running through my head. - BTW this article is a dupe. I read about Mozilla doing rapid FF5, FF6, FF7 updates around three weeks ago.

I don't want my browser going through a bunch of revisions so that I'm always fucking with my computer software/updates, instead of doing actual work (or play). I can't help thinking this is just Mozilla panicking because Chrome is challenging their #2 position, and it will end up being a major PITA for the user.

all they have to do is make firefox scale to multiple cores. There's no reason the UI from the current webpage I'm browsing should grind to a halt because I loaded 5 slashdot discussions in the background using middle-click. Both Chrome and Opera 11 have no problem handling this.

And before someone chimes in and posts this [mozilla.org] saying that they're working on it, take a look again, that page hasn't been updated since May 2010.

At the moment I couldn't care any less about javascript benchmark speed. I just want multicore scaling from Firefox and then I'll be happy.

And before someone chimes in and posts this [mozilla.org] saying that they're working on it, take a look again, that page hasn't been updated since May 2010.

I am afraid that page is out of date, I edited the 'Status' section of it now - thanks for pointing it out!

The status of multiprocess Firefox is that we have been working very hard at it, and made lots of progress. In fact Firefox Mobile is multiprocess already, you can run it right now and see that the UI remains responsive even if you load lots of tabs, JS heavy sites, etc. So that shows that rendering, networking, etc. etc. are ready for multiprocess.

But getting desktop Firefox to be multiprocess will take more time, since there is a lot more stuff to support there, in particular addons, developer tools, etc. The plan is to finish that stuff later this year.

You have to be kidding. Firefox is faster and kicks the other browsers asses. This whole speed thing must have something to do with non-GNU/Linux platforms cause I'm just not seeing it go slow. A browser shouldn't need additional cores to run fast. This sounds like "me too" thinking. While it might improve certain things I'm extremely sceptical. Video is already being accelerated and having 10 tabs open is not something that slows Firefox down. Maybe you are on MS Windows and that has something to do with i

"Firefox 4 will be the last major browser release from Mozilla, as it looks to mimic Chrome's speedy release schedule â" echoing previous statements that Firefox 7 would arrive this year. "What we want to do is get the power into users' hands more quickly,"

I welcome all efforts put into Firefox. What I would not want Firefox to copy from Google's Chrome browser is the 'removal' of basic functionality from the application.

Here's why: -Even after all these betas, Chrome does not have a functional print preview to date! Wait...Google Docs lack this function too!

Why would Docs have it? Every browser is going to print a little differently, there's no way for Docs to know what exactly to display.

As for Google, I agree that it is taking annoyingly long (there is a feature hidden behind a flag but last I checked it didn't do anything) but they may be trying to get it to work properly with Google Cloud Print, which would add a nice layer of complexity onto it.

So they can't release certain functions unless they call the browser FireFox 14 or 82 or 198? Does it really matter what "version" it is, as long as you've given the functionality you're adding or the tweaks you're making considerable thought and testing? This sounds an awful lot like "they're on version 13, so we have to catch up in version numbers so people won't think we're a much older out of date product!".

As it stands, we've been getting a new major point version every 12-24 months. What's wrong with

It makes the lag to shipping new web-facing features and performance improvements too long. As a result you end up with situations like the current one, where Firefox 3.6 is significantly worse than the already-shipping competition (except IE8) in various performance and standards-compliance metrics... while the builds as of June of 2010, say, were much better than 3.6.

This isn't about version numbers; it's about getting new features into the hands of users faster and not gating feature A, which is completely done, on feature B, which might get done sometime.

It makes the lag to shipping new web-facing features and performance improvements too long.

If it means the resulting product is bug-free (read: well tested) and of higher quality--- so be it. That is what I want, not the latest white wall tires.

As a result you end up with situations like the current one, where Firefox 3.6 is significantly worse than the already-shipping competition (except IE8)

I DON'T CARE if FF beats IE[0-9] or Chrome by 3.2ms on some arbitrary and isolated metric or has some new gee whiz but unused feature. Don't be suckered into a rat race by obsessive blogger types. As long as the experience is good and snappy, and the performance (dis)advantage isn't too lopsided I'll go with the well tested version every time. Screw the competition. Quality sells itself. In a similar way, I don't care if KDE/Gnome# tracks the latest Windows7 ideas. In a way I wish they wouldn't if it's just for the sake of it. Do your own thing, make it better, learn from others when you can, and they will come.

I don't want bleeding edge. I want something I can trust my https connection to my bank, gets out of my way and is reasonably snappy, and does not leak memory or privacy left and right due to a quickly grafted new feature. That's it.

Rapid-update philosophy sounds good for early adopters and hobbyist users (does Chrome have much traction in the corporate environment?)

But what about corporate environments that require software to stay stable and on fixed known-working versions? For example, Firefox 3.6 broke compatibility with a plugin that we have widely distributed at our site, and the solution to this issue requires another mass deployment. We've had similar issues with Java's auto-updater breaking compatibility with some applications (and no, we're not an IE6 shop).

First of all, kudos to Google for finally going with MSI. It's like providing an RPM and makes everyone's life easier.

Now, that said, the situation with respect to delayed updates is fundamentally different because Chrome hasn't provide security updates for older versions. You're essentially running snapshots all the time. Any IT department would have be bonkers to follow that model.

As if having to support 3 major browsers wasnt a web design nightmare enough..now to support multiple versions of each..yay. I can hear it now.. well.. it looks ok to me, but I got a support email that it looked like (random crap) for this person, looked like (wierd problem) to my other friend and this (random thing) didnt work for one of my friends at work.. see about that will you? Oh.. they all said they used FireFox if that helps.

If you develop with standards in mind, this shouldn't be an issue. Most of the updates to the browsers will be feature updates, not major rewrites of the rendering engines. If those change at all, it'll be to better support standards, not to drastically change the way things currently work.

I know.. and agree.. it is still a support nightmare when there are multiple flavors of the same browser running around.. Im just whining I guess.. I am just so tired of designing and developing for multiple browsers.. the web dev nightmare since Netscape/IE.. I was there...and I wasnt amused then..and Im still not.

It only gets worse when you consider that HTML will become a 'living standard', so you'll be shooting for a moving target (HTML spec) through a moving foreground (rapidly evolving browser)

I'll gladly develop for standards, but which standards should I shoot for? Yesterdays standard, last weeks standard, last months standard? Should I shoot for a specific browser implementation of a particular standard?

I doubt it will be that bad. The history is one of divergent platforms, but html5 goes to some length to eliminate lots of those problems, so the problems where IE6 supports completely different stuff than Firefox and Chrome will be much reduced, and pages that look good in browser version X should look about the same in browser version X+3.

So it goes from a nightmare of supporting multiple browsers to a problem of deciding when such and such a feature has wide enough support.

It is Not so bad unless you have to support ie as well. Firefox 4 and Chrome and opera behave pretty equal if you dont go for the latest whiz bang stuff which is not yet finally specified.It used to be way worse.

Either that or they have found new ways of fucking up the UI which are so bad, each one deserves its own major release number?Turning it into a Chrome-lookalike and requiring an addon for the status bar while useless animated bling is included by default is certainly a successful start in that direction

The bigger issue is that it makes for more confusion for the users. If you're creating a major version with only changes warranting a minor revision increment, you're making it a lot harder for end users to know when to worry about an update and when not to. If it's just a minor revision then there should be little if anything to worry about, but if it's a major revision those are supposed to be limited to more substantial changes. Jackasses like Google opting to eliminate minor revisions completely in term

Try searching online for a very special necklace for your wife's 40th birthday and then have THAT still following you around when she is around a few hours later. Cue some very fast bull-shitting excuses and a very quick close-down and cache/cookie clear as soon as she left again.

ESR described the most efficient way to release/produce free/libre/open_source software long ago.

Mozilla seems to be late to the game in realizing that the cathedral approach is not the best way to manage software releases when you are actually participants in the bazaar.

Quite ironic, actually, since Netscape was the first publicly visible software product to embrace to "open source" philosophy back in the day. The release of the Netscape source code was quite shocking and simultaneously gratifying at the time. I was quite gratified personally to be able to compile a Netscape browser from source and surf the web back then. Thank you, ESR.

Before you say that since it happens to you it must be my addons, it[1] happens with 1 tab open to about:memory in Safe Mode. The only thing left to do is try a clean profile, but if a dirty profile can make an idle Firefox eat all your ram that's still a bad bug.

Are you sure you're seeing leaks? Firefox will use a certain % of free memory for cache. Just because memory goes up and doesn't come back down immediately doesn't mean the application is leaking. Mozilla's position would seem to be, and I entirely agree, that as long as you have the memory you might as well put it to good use instead of letting it waste away as free memory.

Certainly every browser has memory leaks, and browser releases fix memory leaks all the time. The question is -- do the memory leaks leak enough memory to cause problems? In Firefox's case, the answer seems to be "no", because Firefox uses less memory than other browsers when performing common tasks [dotnetperls.com]. If you think you have found a bad memory leak in Firefox, you're welcome to write up a benchmark that will demonstrate Firefox using more memory than other browsers.

Except that javascript can hold references too right? And hence you lose the A in DAG - javascript on one tree could hold a reference to another tree, which in turns hold a reference back to the first tree.

Javascript itself is a non-trivial runtime engine, and likely a source of a lot of leaks.

Sure it's possible to have browser without any memory leaks, just like it's possible to have one without any bugs. Not very likely, however.

Here's a simple idea for you. When i close a tab everything associated with it memory wise should be freed. You can tag stuff when its alocated that it belongs to so-and-so tab. When the tab is closed everything, EVERYTHING, even plugins and JS get killed/freed. There. Memory leaks fixed.

It's a nice idea, but it's not going to fix every memory leak. Even garbage collected systems have memory leaks [ibm.com]. A web browser is far, far more complicated than you're thinking. One reason your idea won't work is that many objects are not owned by a single tab.

^^ Join the club.In my case it's usually memory leaks related to having previously handled large amounts of images and also some addons.Once Firefox has reached a critical mass between 1 and 1.5 GB it always finds ways to crash. Granted, it's a way of freeing up memory, but I'd prefer ones that don't include possible loss of data in open tabs.