I don't know how Mozilla came to the conclusion that their Web inspector is actually usable.
The HTML doesn't appear when inspecting (no, that takes an extra click). The CSS appears in an extra vertical sidebar taking up even more room on the screen. You can't add a Console button, but 3D View is worthy?
I love Firefox, but this it's just plain odd they didn't integrate Firebug into core.
1) The Firebug team had their own priorities, development timeframes, and goals, and wasn't interested in being integrated in the core, exactly.
2) The Firebug code is .... not easy to work with. Actually trying to make any sort of significant changes to it without introducing some serious problems is pretty hard.
I totally understand it's way easier to start from scratch. It's a little disappointing to hear that the Firebug team didn't want to play ball.
It's not a big deal and I can continue to use Firebug, but the UI decisions still baffle me. Safari and Chrome display the HTML (which 90% of the time is what I'm after to begin with anyways) upon inspection with the CSS on the side. Being able to turn these off would be fine by me, but don't make me opt in every single time. Also, having the Console and other browser inspections would really take it to the next level.
Functionality notwithstanding, I really like the look and feel of it.
Please file bugs at bugzilla.mozilla.org! This kind of feedback is very beneficial. (Disclaimer: I don't work on the devtools, but I work at Mozilla)
That's a small tweak and shouldn't diminish the overall awesomeness that is the rest of the devtools. I actually agree with you, but have found them extremely fast and usable overall.
"Didn't want to play ball" has negative connotations that I certainly didn't mean to imply with what I said. It was just the priorities and goals that were different (e.g. back when JJB was still working on Firebug as part of his job at IBM Research, his work on Firebug needed to have a "research" component, as I understand, which led to some differences in approach from a pure "create a product" tack).
Just to reiterate what bz said for emphasis: it wasn't a matter of Firebug "playing ball". The choice to build afresh was made based on the direction that they wanted to go at the time and our own assessment of how we could get something reliable into the product.
Also, Firefox 13 (which enters beta this week) has a bunch of nice improvements including remembering whether the HTML and Style panels are open.
We're iterating at a decent pace on these tools, so keep watching. The JavaScript debugger is coming to Aurora soon and it's shaping up quite nicely. The work behind that is going to be a big win for both the new debugger UI in Firefox and ultimately for Firebug as well.
In my Nightly (don't know about current release), I just have to click once on the show html button, and if I inspect another page later, it brings the HTML panel along.
I actually find the vertical CSS sidebar to be an excellent choice. CSS (and code in general) is an inherently vertical thing (short line length), whereas the number of rules displayed is maximized using a vertical panel. A console button would maybe be a good idea, but I only use the keyboard shortcuts, so I don't mind, this prevent reducing the visual clutter.
Firebug is a seriously old and not that sufficiently maintened code base, hence the choice to write new tools, more integrated with the browser.
Yes, the style inspector is vertical for exactly the reason you cite. We're also working on a better solution so that it doesn't cause issues with responsive designs.
Firebug is still actively maintained and continues to have new releases and improvements. Firebug 1.10 (currently in alpha), for example, is now restartless and has less impact on page performance.
I was under the impression that Firebug was being actively developed again. Is that not right? They had some really cool features that Webkit inspector did not last I tried it, which was fairly recently.
I'm not even sure why they're trying to create a Firebug replacement. Isn't this how we get browser bloat, by including every possible tool with the core browser?
This is the one with a full silent update? Soon most people will be running one version of Firefox? Chrome + Firefox means 40%-50% of the Internet is getting a browser update every six weeks. This will be a boon for software developers.
Chrome + Firefox means 40%-50% of the Internet is getting a browser update every six weeks. This will be a boon for software developers.
I never understand this argument.
All we have now is two different fast-moving targets, both with a track record of introducing breaking changes. IME this just results in a significantly higher number of customers complaining to our customer support team (not Mozilla's or Google's) that our web pages/embedded UIs don't work properly any more.
I have yet to be convinced that this obsession with releasing every six weeks really gets useful features out there in a way that benefits most users anyway. As far as I can tell, about 99% of the developers using those features are people writing tech demos for the browser makers and/or trendy web design blogs. Much of the content on those sites doesn't even work on both Gecko and WebKit at the same time, never mind IE. Meanwhile, real sites still have to cope with a majority of visitors who don't have the latest shiny new features.
In any case, a lot of those features frankly aren't all that beneficial anyway compared to basic things like not freezing the entire browser UI because one tab is taking a while to load. That is something Firefox still can't do even though it's several years after every other major browser had it, and the apologists are getting awfully boring now.
No one is saying that the day a feature is released that it will be widely adopted. CSS animations, for example, can be incorporated in sites, and as performance improves, etc it will become more widely used. Some "features" are simply performance improvements (e.g. GPU acceleration, better JS JIT, WebGL improvements; Chrome added software WebGL support on the last update).
Developers will be able to clean up their CSS more often (e.g. -webkit-border-radius, -moz-border-radius => border-radius). Sure, somethings will be only for developers at first but after a burn-in and Chrome/Firefox adoption, certain features and techniques will become mainstream. IE users will get the more "generic" page. Not a lot can be done about that.
Finally, let me add that it reduces testing for developers because now you only have to test on one version of Firefox. FF 3.6 is under %3 market share, and it was retired today.
As for the not freezing, that's a different unrelated issue. I've been running the Firefox and Chrome nightly's for a year and I'm pretty happy with both.
I understand what you're saying, I really do. I just think we would do better as an industry -- in the sense of producing more real world projects that benefit real world users sooner -- if instead of everyone having an anatomical measurement contest about version numbers, we slowed down the pace of releases but tried to standardise the useful new features within a release cycle or two. There is no advantage to anyone in having essentially the same feature available in, say, Gecko and Webkit, but subtly different syntax so all the CSS has to be written twice. There is no advantage to anyone in having HTML5 video, but Google being unable to make up its mind about whether H.264 is the de facto standard because it's better than everything else or the spawn of Satan because of the patent concerns. And so on...
That again a different problem unrelated to rapid updates.
Yes, I agree it would be great if everyone converged on standards sooner. If we agree on the one true standard to create a linear-gradient, for example, then we shouldn't have to wait 2 years to get it implemented.
Btw, you are supporting all those Opera extensions too, right? :-(
No, because many people aren't using browsers that update every six weeks, and even those who are don't get the same updates every six weeks.
In this case, as far as I can see, the only new "feature" they've shipped is actually to do with the update process itself, and it's a change that is pretty controversial at that. In fact, quite a few recent updates to Firefox (and Thunderbird for that matter) haven't really had much substance at all. Not exactly a great argument in favour of the need for such rapid updates.
I wouldn't say there's a need for rapid updates; as a user, I just want them. I don't understand why users should be made to wait 6 months to a year for small features that are available now.
As a user, why do you want them? They are of no value to you unless sites or apps that you value are making use of them, and few production sites use most of the bleeding edge tech that supposedly justifies the rapid release cycle.
A lot of that tech is of more interest for app-like pages rather than classical web sites, but then you start running into portability issues: not every browser has a fast cycle, and those that do aren't necessarily including the same features at the same pace. That means everyone needs to code a fallback approach anyway unless it's acceptable for their product to support only specific browsers. Once you start down that path, the core functionality is probably there for your users even if you don't then reimplement it a second time or add enhancements using the new technologies.
Browser updates are more than just html/css/javascript functionality updates. For examle, if Google updates the UI of Chrome and they can push it to me now, why not? I don't want to wait, and Google is giving me the option of not waiting. Or if they update their extension APIs and I want to make or use an extension that relies on them - why wait? Or if they make javascript run twice as fast for me. As a user, I love being able to get those things as soon as they're ready.
> That means everyone needs to code a fallback approach anyway unless it's acceptable for their product to support only specific browsers.
This has been and always will be true until 100% of the web uses the same browser. I'm not sure what the point of stating it is, or how a rapid-release schedule makes it worse. It doesn't.
> I have yet to be convinced that this obsession with releasing every six weeks really gets useful features out there in a way that benefits most users anyway.
If it takes six weeks to push a security update, you're doing it wrong.
This is part of the problem with the fast update cycle: People are now conflating security updates (which should be out there ASAP and should make no functional changes at all) with functionality updates (which are never necessary unless you want to visit a site that uses a new feature or to use some change in the UI, have a much higher risk of unintentionally or intentionally breaking stuff that used to work, and certainly don't need to happen 8-9 times every year in any case).
So? If you ignore the "shiny new features", it doesn't make much difference if the updates are 6 weeks or months apart. They are not fast-moving targets because the already standardized technologies don't change. Pages render 99.9% alike on Chrome 4 to 19, same goes to FF > 3.5.
If you ignore the "shiny new features", it doesn't make much difference if the updates are 6 weeks or months apart. They are not fast-moving targets because the already standardized technologies don't change.
Oh, if only that were true. The number of minor issues that Firefox and Chrome have broken in their rapid updates is vast. And they break major things occasionally too. Try looking at what happened to pages using Flash or Java applets in (ironically) the initial LTS release of Firefox a few weeks ago, for example, or consider the Chrome/H.264 fiasco.
Leaving aside the things they are breaking, there is also the issue of things they are not fixing. There are plenty of long-standing and widely applicable bugs in the rendering of existing but no longer trendy features in these browsers. I don't see how you can have this constant pressure to show progress and support for bleeding edge technologies without also squeezing out developer time that would be better spent fixing bugs that already affect many users today.
> The number of minor issues that Firefox and Chrome have broken in their rapid updates is vast.
What exactly has lead you to this conclusion? As a professional web developer for a high volume website, I can't remember a single instance of Chrome breaking any html/css/javascript on our site between updates. That's not to say it doesn't happen, it just seems really rare and minor...
What kind of site do you develop that users are constantly complaining that things are breaking due to Chrome updates? I've never heard this be made as a sincere complaint before.
Please see my other posts in this thread for some examples.
The case I was specifically thinking of in that case was the Firefox bug that broke Java applets a few weeks ago, and with them everyone's web apps that use the technology as part of their UI.
It seems like everything you're talking about seems very specific to the kind of web work you do. As a professional web developer, I've never had these kinds of problems due to Chrome's or Firefox's rapid release schedules, and I've never heard complaints of it from other web devs.
And the specific case you mention here is also something that could happen in a longer-term release; rapid-release lets you fix it faster.
It seems like everything you're talking about seems very specific to the kind of web work you do.
Not being able to draw rounded corners properly is unique to "the kind of web work I do"? Yanking an entire video codec -- and probably the most popular one in the industry -- is unique to "the kind of web work I do"? Screwing up the browser if someone loads a page containing a Flash or Java applet is unique to "the kind of web work I do"?
I'm honestly not sure at this point what it is you think I do or why you think it's somehow unique. I'm drawing on several projects and more than one client I've worked with here, and just about the only thing they have in common is that they involve building a web app rather than just designing a static page. There must be many thousands if not millions of guys doing similar jobs, and I'm far from the only person to report any of the issues I mentioned.
And the specific case you mention here is also something that could happen in a longer-term release; rapid-release lets you fix it faster.
Except that if your rapid release cycle doesn't allow enough time for adequate QA then it is far more likely that you will ship broken code, and in the plug-in case the breakage was so severe that they pushed an out-of-band patch to correct it anyway. The rapid release cycle may well have contributed to causing the problem and certainly did nothing to help fix it in that case.
> Not being able to draw rounded corners properly is unique to "the kind of web work I do"?
This one I just don't understand because, ostensibly, your argument is that you have to down-code for browsers that don't support new features yet, but this is a feature that rapid-release browsers support that others didn't for a long time... It's also a trivial rendering issue and doesn't break anything if not working.
Yes, the codec problem seems specific. Most web video is handled by Flash, not the browser itself. If you're using it, you're trying "cutting edge" stuff which I thought is what you were saying isn't important to have...
And the Flash/Java issue you mentioned happened in an "LTS" release, which means that it's specifically the version of Firefox that does (supposedly) get adequate QA before release because it's only updated about once a year, with the goal of it being more stable. So it seems this kind of thing is just as likely to happen either way.
> I'm far from the only person to report any of the issues I mentioned
I'm not saying these things didn't happen or weren't reported by others, I'm just saying that the things that apparently happen frequently for you due to rapid-release have almost no effect on the greater internet. It seems like you're saying it's something that's bad for everyone, when really it seems it's just pretty crappy for your situation. In reality, rapid release is by far a net positive.
> Try looking at what happened to pages using Flash or Java applets in (ironically) the initial LTS release of Firefox a few weeks ago, for example, or consider the Chrome/H.264 fiasco
You couldn't be more wrong. I make my living building web sites and embedded browser-accessible user interfaces, and several of the projects I'm working on right now use state-of-the-art features with HTML5, CSS3, mobile devices and all that jazz.
How can you claim to use state-of-the-art features and not appreciate that those features will be more stable and more readily available than ever? And the cool new features being worked on are far, far, far more expansive, neat and "useful" (as you desire) than "css3" or "mobile devices". If you're really doing "state of the art" things, then you're probably using features that were added to Chrome and Gecko as part of one of the features that was enabled by the rapid release cycle with multiple versions and pipelines being worked on simultaneously.
Further, what breaking changes have you seen as a result of Firefox and Chrome's rapid development cycle. I mean, the features I'm discussing break regularly, but then again their specs are still in a very draft status and it's known that they will break. I can't say I've ever had a stable Javascript API or CSS rule just completely change when moving from Firefox 11 to 12 or whatever.
>"Much of the content on those sites doesn't even work on both Gecko and WebKit at the same time, never mind IE."
Honestly a lot of your claims seem to be exaggerated or I'm on a very different subset of the Internet than you.
How can you claim to use state-of-the-art features and not appreciate that those features will be more stable and more readily available than ever?
Because they aren't more stable and readily available than ever.
Browser fragmentation is worse today than at any time in history, including the peak of the Netscape/Microsoft war. At any given time, you might have to implement a given bit of styling at least three or four times over, not because the browsers differ in their functionality, but just because they all do it with slightly different syntax.
That in turn is because the browsers frequently have slightly different ways of doing things first, even if someone then wins later, which of course means everyone else has to slightly change their behaviour to match whichever standard wins.
And that's before you even consider the standard refrain that "it's all beta, we can change the APIs at any time, this functionality shouldn't be relied on for production sites, yada yada".
And then you have to consider the bugs, of which there are many in bleeding edge features, not helped by the fact that the six week release cycle is demonstrably too fast for a reliable QA process for software of this complexity.
And even when you've taken care of all of that, you still have to consider the fallbacks for older versions of IE, graceful degradation for mobile devices with limited bandwidth, and so on.
Further, what breaking changes have you seen as a result of Firefox and Chrome's rapid development cycle. I mean, the features I'm discussing break regularly, but then again their specs are still in a very draft status and it's known that they will break. I can't say I've ever had a stable Javascript API or CSS rule just completely change when moving from Firefox 11 to 12 or whatever.
Lucky you. We're lucky if an update ships and we don't get someone finding a bug somewhere.
Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next.
Another example for Chrome from a bit further back was the way they completely stuffed the drawing of rounded corners. And then stuffed it again, in a slightly different way, in the next update. And then stuffed it again, a different way again, the update after that.
Then there's the whole H.264 question. Is it supported or not? Officially it was going to be dropped quite a while ago. And then it wasn't. And then maybe it is, but actually on Windows it works anyway because of someone else's software.
Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets. That bug was known about several days before the update went out, but they pushed it anyway. Having established the scale of the screw-up, they then proceeded not to undo the update until they had a fix, which took several more days. On behalf of the customer support guys I work with who were flooded with complaints that our user interfaces had stopped working for about a fortnight, I'd like to thank the people at Mozilla for instituting such a robust and user-focussed QA process along with their rapid release cycle.
I could go on (and on, and on), but right there you have several real world examples of rapid releases pushing out fixes that broke fundamental, widely used technologies, both old and new.
Honestly a lot of your claims seem to be exaggerated or I'm on a very different subset of the Internet than you.
It's funny how often I hear that. And yet two minutes with Google searching for information about any of the bugs above will turn you up thousands of references. And I'm being kind here and not even picking on all the little details they keep breaking in more bleeding edge features, nor on all the irritation to end users rather than developers that both Mozilla and Google cause when they subtly change their UI around for no particular reason.
Seems like about half the issues you've mentioned relate to differences in syntax/behaviour. This is to be expected. That is what vendor prefixes are for. They are a known (and necessary) evil. Would you prefer to allow the design by committee approach to continue? We've already suffered through 10 years of stagnation due to this approach.
Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next.
This one sounds like a biggie. Do you have a reproducible test case to demonstrate this behaviour? I know it's time consuming, but you really should file bug reports for this type of stuff. I've filed a number over the years and they do get worked on and they do get fixed (sometimes a lot quicker than you'd imagine).
Are you building apps or websites? I can't imagine seeing the fundamentals of layout, box model etc breaking from one release to the next.
On the other hand if you're building applications that rely on vendor prefixes then I agree you do have to tread carefully.
Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets.
Software breaks life goes on. If i'd never personally shipped a line of code with a bug in it I might complain louder.
The pace of innovation is blistering. Just look at all the stuff that's come out recently websockets, webgl, flex-box, css columns, dnd, offline storage, css animation, audio, video, filreader, canvas the list goes on.
If you're building just another brochure website none of this will interest you. On the other hand life is sweet if you have the luxury of using these features. Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.
Seems like about half the issues you've mentioned relate to differences in syntax/behaviour.
If you mean the bugs I described, then no, I think all of them are genuine bugs.
There's no way to justify Chrome not redoing page layout or repainting properly after a DOM or CSS update. That's just sloppy, and it's a serious problem if you're writing app-style pages. Unfortunately, I don't have a self-contained, reproducible test case: we see this a lot using toolkits like jQuery UI when showing (or not) dialog boxes, but unfortunately it's a bit of a Heisenbug, or possibly several Heisenbugs. The general issue has been reported somewhat widely in Chrome-related blogs, though, and IIRC there were some issues already in their bug tracker that looked like they might be related. The latter led to some blog posts suggesting workarounds with JavaScript that might correct the CSS calculation errors in at least some of the cases. The issue has been there for several months, and still hits us from time to time.
The rounded corners problem I referred to was a rendering problem that made pages using the CSS3 rounded corners horribly ugly and which seemed to take several attempts to finally get right. (Of course there were browser prefixes and so on in this area as well for a time, but that's not what I was referring to.)
The H.264 issue is just a mess. The fact is that Chrome supported it, and then Google said after a future update they wouldn't support it any more. They were planning to push an update that outright removed functionality, and that functionality was in one of the few cutting edge areas that was really taking off at the time, too.
And Firefox screwing up support for the plug-ins was just poor quality checking before a release. There's no excuse for breaking something on that kind of scale, particularly when the bug was already in the tracker several days before the update was pushed out.
Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.
No, they really don't. When my clients ask why the software they've paid me a lot of money to write for them has stopped working, with the result that their on-call guys are getting woken up in the middle of the night by someone on the far side of the world who can't use their very expensive equipment any more, the answer they are looking for is not "Well, you see, we use a Java applet in this product because when we started the project a few years ago HTML5 canvas didn't have the functionality, speed or portability we needed, and that Java applet requires that the user have a Java runtime installed on their system and a corresponding plug-in for their browser, and your customers are using Firefox as their browser, and Firefox pushes automatic updates, which in a stunning piece of incompetence your customers' system administrators have not disabled, so their key systems will apply the updates before anyone tests that nothing important breaks, and in one of those updates the Firefox developers kinda broke a bunch of things on pages that use applets, and that's why the users can't type text where they should be able to, and so it's really not our fault, but at least these bugs will probably get fixed in the next release and that probably won't be more than six weeks away, so for now your platinum support guys should tell your customers to just hang in there for some unknown length of time and then they'll be able to use that very expensive hardware again, and in any case I'm sure this won't in any way jeopardize that contract you were going to get to sell them another 250 units in a multi-million dollar deal next month." No, trust me, that's really not what paying clients want to hear at all.
It's a shame you don't have a reproducible test for the rendering issue in Chrome. Until you can reproduce it there's really no telling what is going on. Do you have any links to similar issues already reported? I'd be curious to read up on them.
The rounded corners problem I referred to was a rendering problem that made pages using the CSS3 rounded corners
Any test cases for this? It really is important to see a simple test case. I've never had any issues with either Chrome or FF with corners.
Sure h.264 is a mess. If it bothers you then don't use it. The fact is that Flash is still defacto standard for video, so for consumer facing pages that's probably what you should use.
Sounds like you're upset because you got burned by a recent issues with firefox. It's reasonable to expect such a big breaking change to be caught in their regression testing. Unfortunately it slipped through. The reality is that software has bugs. All software. Yours, and mine. Every product ever shipped has gone out the door with bugs. It's unpleasant, especially when you have no control over the fix.
Seems to me that a rapid release cycle actually works in your favour. Certainly better than the MS cycle where you can expect to have to live with bugs for 18month-2years between releases. Auto updating in particular is a boon for developers. If you look at the Chrome version stats, most people are on the latest stable build and this is mostly due to auto update.
Also, if you're developing an app which is actually used for 'multimillion $ deals' then why aren't you distributing it as an application inside of some kind of wrapper such as Qt? Sounds like deploying as a regular web app was a bad technical choice for you product.
As far as video goes, Flash is not the de facto standard any more if you're working with mobile. Apple won that one. And H.264 is technically superior to the other useful formats for HTML5 video and the only format supported and/or supported with hardware acceleration on several platforms, so dropping it isn't much of an option.
Finally, on the subject of testing, it wasn't really me personally who got burned by the Firefox screw-up, it was one of my clients. Their technical people understand that there isn't much I can do about it, but that doesn't help their customer support people who have to deal with irate customers.
In any case, we actually recommend that their customers use IE rather than Firefox or Chrome these days, because for all its sins, it is a stable platform to build on and we can test against it with some confidence that end users will see similar behaviour for a useful period of time to come. No-one connected with this project likes rapid browser release cycles: not the developers, not the users, and certainly not the guys paying my invoices, who are on the wrong side of both.
> all the irritation to end users rather than developers that both Mozilla and Google cause when they subtly change their UI around for no particular reason.
This is why I use Safari. Despite the fact that Safari crashes routinely when one tab hangs up, at least I don't have to worry about the UI rearranging every time I restart.
Remember the days of Firefox launch parties? Honestly, a year release cycle feels quick.
The major change to updates in Fx12 is that the Windows UAC prompt will no longer appear for every update (by default). Some additional changes (like finishing the update in the background instead of at the next startup) are coming in a later version:
You can disable Firefox's "an update is available" nag dialog with about:config app.update.silent=true.
This pref has been available in Firefox for a long time, but I believe it wasn't enabled because people who don't restart their browser often would not get security updates in a timely manner.
Glad to see they've finally moved to silent updates. That's the feature that lost me years ago, and as nice to see it finally make it, I don't think I'm coming back from Chrome.
The problem with the "hey, before we're going to let you use Firefox, we need to download a new version for you. Wait a few minutes" screen is that it stops you dead from being able to do whatever you opened the browser to do. It's jarring enough to make you avoid Firefox for anything except the times when you absolutely need to test something on it.
That means you use it less often, which means that opening it always puts you through that annoying process. Every Single Time you use Firefox.
So over the years, they've trained me that "Firefox == Pain". It'll take them a long time to train me back.
That's actually the right way to do it.
How do you think Chromes does? Right, they're installing in the user area, not in the application area, to bypass UAC. That's wrong.
Using a service that uses authenticated connections and signed installs is similar to what Windows Update does, for the right reasons.
Best would be that Windows Update would be open to let any app hook into it for updates of course, but til then, that's as close as it gets.
No, it's not. If Firefox is installed by a non-admin user, it should go into the user's directory. If it is installed by an admin, then it should ask if this is an OS-wide installation and only then drop it into %ProgramFiles%. Chrome got it absolutely right.
Incorrect. Firefox is always installed by admin user at the first install (UAC prompt there is inevitable).
If you run an unzipped firefox from your desktop, it will not install the updater, because it CANNOT. There must be at least ONE UAC prompt ONCE. And that's where it's installed as admin, that's what UAC is there for.
You don't seem to understand how permissions work.
Firefox (or any other program for that matter) should be able to install itself when run by an under-privileged user. SHOULD. If it CANT, then its installer is designed incorrectly and its installation mechanics are wrong.
Consider a simple case when I am on a shared computer as a restricted user. In an Internet cafe or similar. I should be able to install, run and use Firefox. There's basically no technical reason why it will not be able to run under a restricted set of privileges. It has no drivers to install, it doesn't bind to privileges range of ports, it doesn't need to install a service. It should quietly go into C:\Users\dude\Program Files and make itself comfortable there.
Microsoft has a set of guidelines, in part covering where what should go. Some of these guidelines are simply retarded, they have always been. Their existence is not an excuse for not questioning them. If a developer insists on following them, it just doesn't speak much of a developer.
Well, there's Portable Firefox for that use case...
There are some benefits to installing critical apps like web browsers outside of the user's home directory. If a virus compromises the user account, it still can't touch the web browser's executable.
I've been able to install both Firefox Aurora and Nightly on my windows restricted account. Haven't tried the regular Firefox, but I'm assuming it's the same, because I installed Aurora and Nightly around version 9.
Since Chrome is in the user area, guess what, anything compromising Chrome can overwrite Chrome itself. It can then prompt you with UAC or simply have a user space trojan. (heh, and it can't compromise Firefox if it's also installed)
An updater has a several magnitudes less code to audit (thousand, millions magnitudes?).
In Firefox's case, if Firefox is compromised, it cannot modify itself (heh, it can compromise Chrome if it's also installed)
If Firefox is in UAC'd location, then a Firefox compromise would simply drop an .exe or .dll into user's directory and set it up to be launched by Firefox. As an add-on, for example, or through the same exploit it used to enter the system.
In other words, the installation location doesn't really matter. If the process is breached, the user context is f#cked regardless.
I've checked it and yes, it connects to SSL'd mozilla update servers (like firefox did on it's own in the past)
The certificates appears to be pinned (so it doesn't trust "any" valid cert, only these very certs)
Then the downloaded update appears to be a mar signed file (then again firefox did that on it's own in the past too)
If a Firefox exploit drops an exe, it will never run with admin rights. It'd have to be coming from Mozilla and signed by Mozilla. Plus, it'd have to come from their servers, because you can't just drop the exe and have it installed, the updater only trust what it downloads on it's own.
In this case, its only the updater that runs privileged (which last time I checked was a separate application). The only way you should be able to 'compromise' it would be too man in the middle, and pretend to be Mozilla servers. Even then, if it used SSL (I'm not sure it does), and had an embedded certificate, then it should be fine.
Yes, the Firefox updater uses SSL and other mechanisms to prevent man-in-the-middle attacks. The update payload itself is signed with a private key controlled directly by Mozilla, to avoid vulnerability to CA compromises [1]. The connection to the update server uses SSL and performs additional checks to ensure not only that the SSL certificate is valid, but that it matches one of a small list of known certs or issuers, so a bad CA can't issue a forged certificate [2][3].
The scenario you just detailed is rather contrived and is possible in any software deployment scenario.
Why the downvotes? As the other comment points out this is a really stupid security bit to nitpick as all of the alternatives are equally vulnerable in an equally contrivable scenario manner. One way or another privileges have to be granted. They can be granted in one place or another and have largely similar if not identical implications at the very least in terms of the net effect that can be had.
> A service per application to handle updates is not very good.
Why not? The only problem I see is that it bloats out the list of services, and that list has been dying for some kind of hierarchical reorganisation for some time.
Alas, that's more of a messy patch over Windows' lack thereof, IMNSHO (Windows Update indeed exists, and updates the Windows OS, but that's about all you can do with it).
How is it responsible for them to bypass UAC at all? When did it become OK to circumvent the security features of the user's OS in order to install software without his knowledge?
Chrome and Flash are installing services, but they also create tasks in Task Scheduler. Will Firefox do this as well? Can one delete the services and have only the tasks running?
I'll bet you a beer or whatever you like to drink we're going to see a flurry of exploits around this service.
I happen to have written a similar service a couple of years ago for a very different purpose and let me tell you one thing: this is nothing less than a backdoor.
You run a program from the service and make sure it runs in the user's session. The problem is, how do you decide a program is "legit"?
You're going to tell me "you check against a digital signature". Except it doesn't work. You can only check parts of the binary, not the whole binary (as some content is unpredictable once it runs).
The other big problem - assuming they have a perfect gateway - is that a vulnerability in Firefox could become catastrophic as it could go through the service to run as a privileged user and wreak havoc.
1: Firefox always used UAC for updates. Did it wreak havoc? Because believe it or not, UAC = admin rights. That's because Firefox always installed itself in program files.
2: You could exploit Google's update service as well. Do I see flurry exploits around it? Much much smaller code base. Much less complex tasks.
3: A digital signature signs the whole binary. Not parts of the binary. Do you know how this works? There's no such thing such as signing a partial binary.
> You're going to tell me "you check against a digital signature". Except it doesn't work. You can only check parts of the binary, not the whole binary (as some content is unpredictable once it runs).
I read this a few times, and I still don't get why you wouldn't check the whole binary. Care to elaborate?
> You can only check parts of the binary, not the whole binary
Not only would they be signing the binary in its entirety, they're almost certainly signing every single byte of the update package, right down to the very last manifest file and license agreement.
Has anyone got a link to a clear explanation of this new Mozilla Maintenance Service, please? I'm trying to find reliable information, but it's hard to see the wood for the trees in most of the documentation/commentary I'm finding.
I did notice that something popped up on one of my computers, having triggered an alarm in one of my security tools. I automatically told it to block the installation, the same as I do for anything else that presumes to invite itself onto my system without first explaining what it does and asking my permission.
It does seem to have sneaked in on my work PC, but seems to have configured the service to run with manual startup only. So what exactly triggers this service, and what kind of security implications are there? In short, do I really want this (given that I really don't care about absurdly frequent updates unless there's a security alert that requires an immediate fix) or should I nuke it?
In case anyone opens their Firefox 11 client and it doesn't automatically recognize there is an update available, you can go to Help -> About Firefox and it will grab the update.
Wait for the download to finish, then click the "Apply Update" button and you will be updated to Firefox 12.
I believe Mozilla sometimes "soft launches" auto-updates to a subset of Firefox users to find any new issues before opening the flood gates to update everyone. But, as you point out, manually checking for updates should always find the latest version.
Beta and earlier users tend to be different in a lot of ways from regular Firefox users. Soft launching surely helps the download servers, but a large point is to watch for new crashes, so that any emergency fixes can be put in before unthrottling the release.
Past issues include antiviruses that crash Firefox because of their invasive monitoring. While ideally these things would be caught by QA or early adopter users, there's no way to test all possible combinations of software.
Be careful, though. If you go to the About dialog, it will begin downloading and installing the update automatically, without getting your permission, and you won't be able to cancel it from within the browser.
It seems to have subtly broken TreeStyleTabs on OS X, which is a shame because I am addicted to it, but at least it's still usable (the tabs take up ~150 pixels of vertical space). Hopefully this will resolve itself with a TST update.
That said, wow, the OS X improvements are huge. Previously I could only force quit if I wanted to shut down to free memory or whatever, but now it closes normally. I'm also not seeing the same kind of memory usage, but it's early so I'm not sure how long that will last.
It's purely the visual component I mentioned, the functionality seems to be okay, although it's reported as broken in the add-on manager. I have the tab bar docked on the left vertically and the tabs are ~3x taller than they should be.
I'm the same way about switching to Chrome, by the way. I would love to but I just can't picture life without TST after so many years.
I don't see the tabs taking up extra vertical space, although 3x the size should absolutely be noticeable. I did, however, have a problem yesterday when watching a fullscreen video: if I put my cursor on the left side of the screen, the tab bar would appear (as though I had it set to auto-hide) and obscure that portion of the video. It was quite annoying because the sensitive areas extended all of the way to the top left of my screen, where I have a "corner" set up on my Mac to disable the screen saver.
Ah, you know what, I just figured out what the issue was. I was using the "metal" TST skin and when I switched it to another one, the 150px-tall-tab problem went away.
A big problem for Gecko which does not exist for WebKit is XUL extensions. If you think about it, XUL extensions must run in UI process (unlike Chrome extensions), but XUL extensions can also access web content which lives in web process. It is nearly impossible to make this 100% compatible...
I thought most Mozilla software was internally based on XPCOM. Then why can't they just proxy the interface calls to go to a different process via standard IPC mechanisms? (I've no knowledge of XUL extension model thou)
The issue is that extensions expect to access web content synchronously, so you need synchronous IPC for perfect compatibility, but that causes your UI process to block on your web process.
I did not mean that it's technically related. Rather, that it's my opinion they won't do it until then. The reason is that there is too much to rewrite/change/fix.
Then if they do manage to do it (and do it right), well, I'd have been wrong :)
To the contrary: it will be a shame when they implement full screen if take away the current layered option. Firefox is the last major OSX browser to work in fullscreen while still allowing apps to be above or below it. With Moom's hotkeyed window positions--it's extremely convenient to bring a text editor to focus and still be able to scroll the web in the background.
Mozilla, please don't let this happen!
So you can run apps full screen and swipe between them. It's like focus mode for apps, switching becomes very fast, and it unifies the Macbook Air experience and iPad experience for multitasking.
They haven't gotten rid of the "checking for compatibility updates" dialog - which was the worst part of the Firefox upgrade process in the first place.
Until FF fixes their extension compatibility, stops breaking plugins with each release, gets rid of version verification for all the popular plugins, and finds a more streamlined way (non-modal, ffs!) of prompting you to enable/disable extensions that are now broken or require more permissions, they'll still be playing catchup to Chrome's autoupdate procedure.
Well, they're playing catch up on that, that's for sure.
But my understanding is that they're adding the necessary features one by one.
Next is silent updates (=no dialogs). This one is just "no UAC prompt".
Nothing, actually! It's already in our Nightly builds, and will be appearing in Aurora some time this week. You can grab Nightly at http://nightly.mozilla.org
Can you give us some insight in to the decision making process when prioritizing feature additions then? It seems bizzare to me that it's taken since the first developer preview in Feburary of 2011 to get the feature in to merely the nightlies.
Both Firefox and Chrome increment their version number every six weeks, so it's easy to see that at this rate in a year we will have Chrome 26 and Firefox 20. :)
In an ideal world, we'd get an update every day. Continuous integration, a comprehensive test suite, a few million hackers test for a day, then and out the door. There's always a train leaving the station.
The HTML doesn't appear when inspecting (no, that takes an extra click). The CSS appears in an extra vertical sidebar taking up even more room on the screen. You can't add a Console button, but 3D View is worthy?
I love Firefox, but this it's just plain odd they didn't integrate Firebug into core.