There's one thing I don't understand of Firefox's current evolution: developer tools.
Firefox already has an absolutely excellent (third-party driven) devtool, at the root of basically all modern (browser) devtools, in Firebug. Firebug is pretty much the source of Webkit's Developer Tools (Safari and Chrome), of Drosera (Opera) and even of the utter dreck that are MSIE8+'s builtin developer tools, and one of Firefox's greatest gifts to web development (along with taking down MSIE and the idea that following standards might be a good idea from time to time)
It's not perfect by a long shot and it does have issues (which get addressed over time), but it's there and more importantly its good.
Yet they are reimplementing it bit by bit, in a less-integrated, less practical, and overall shittier way.
Why?
Why is mozilla wasting time on that?
Why couldn't they instead focus on making Firebug better and providing a better, deeper integration between Firefox and Firebug? Or by developing new API and panes trailblazed by the Webkit devtools (e.g. rendering timeline)? In fact, why not look into merging Firebug into Firefox pretty directly (disabled by default of course)?
Does anybody know? Because it boggles my mind, Firebug has had a complete console for ages and Firefox 9 added a shitty one (which mostly spends its time being spammed by irrelevant garbage due to not having a network tab) as a "quake console" (opens from the top), and Firebug has had an (excellent) DOM inspector for ages (again) and Firefox 10 adds a completely shitty one[0]... but at the bottom of the window so using both the inspector and the console takes twice as much visual space, and if you open the "styles" pane your visual space shrinks down to a postcard.
Please help, because they've lost me completely with that strategy.
[0] seriously, can't create new attributes, can't add content to an empty one (can only change existing non-empty content), pointlessly huge breadcrumb trail, blue-on-black theming which looks completely out of place, no autocompletion of CSS properties, no hyperlinking of CSS files or elements, no layout display, no object inspection, no DOM changes breakpoints, no HTML edition, no separate window, what's there is barely useful, we're talking IE8-level of functionality (of the inspector tab, IE8's devtools at least have a debugger) if even that (thought hopefully not as terminally buggy) and I'm probably forgetting half of it
What I gather from that is that they will keep developing and improving Firebug (or rather, support it, because Firebug authors aren't from Mozilla), but that they also want to experiment with other devtools that are hard to implement in the existing Firebug codebase. The devtools are also one of those new things that are now rapidly improving from release to release, so they're bound to have "version 0.9" issues.
Why couldn't they instead focus on making Firebug better and providing a better, deeper integration between Firefox and Firebug?
I was always under the impression Firefox plugins can do anything they want and have complete access to all the API. And that this is exactly why they tend to a) be more powerful than the equivalents for other browsers b) have more compatibility issues.
There are some pretty strong fundamental reasons why you want to have debugging tools be exactly in sync with releases, especially when you are making major changes to feature support and rendering. Also, in this day it just makes sense to have such tools integrated in the browser.
Now, the Firefox team might not be pulling off the execution very well (though it's a little unfair to compare an early generation product to a more evolved product) but I think it's probably the right decision for the future, hopefully they'll iterate on it enough to get it into a good state.
However, all of this is sort of beside the point. The Firebug lead went to go work for the Chrome team, so the Firefox team is in a bit of a pickle.
> There are some pretty strong fundamental reasons why you want to have debugging tools be exactly in sync with releases, especially when you are making major changes to feature support and rendering. Also, in this day it just makes sense to have such tools integrated in the browser.
That's cool and I can see that, but it does not explain why they're not building on Firebug's established base.
> However, all of this is sort of beside the point. The Firebug lead went to go work for the Chrome team, so the Firefox team is in a bit of a pickle.
Firebug already survived the departure of its founder years ago, if there's a will it can survive Barton's as well.
As I understand it there are limitations to the way firebug (as an extension) works that would make continued development and adding new features problematic. I don't know enough about Firefox's dev tools work to say whether or not it even makes sense to make use of firebug's code base and whether or not that sort of thing will happen in the future. It would be a huge failure if the firefox devs couldn't even manage to match the functionality of firebug, but it's more than a little too early to say that that will be the case.
As to the development team, there's a difference between surviving and thriving. Especially as the pace of firefox development has been accelerating I think bringing dev tool support in house is the only rational choice.
Firefox Hotfix: There are small issues that can occasionally affect Firefox users after a release. Correcting those small issues should not require a full Firefox update. With a new hotfix system, Mozilla can patch minor issues in Firefox without requiring a browser restart.
Interesting, they don't seem to do live patching, but leverage the addon system to do small updates until a browser restart is performed. This wouldn't be able to fix issues at the core of the browser, but it would still be able to do a lot.
Silent Update: The Firefox update process will be moved to the background and Windows admin passwords and/or UAC prompts will be removed. Also, users with the rare incompatible extension will have a gentler upgrade process.
Do you think this is a good idea for Windows updates for the big public? If not, how is Firefox different?
Firefox installers are signed (and so are updates), so I don't see any security issues here. On the contrary, removing the need for people to approve all those useless UAC prompts makes it more likely they will actually look at the next one to pop up and see if it is legit.
On the one hand, it's basically an enormous usability win. I don't want to manually manage all of my security updates.
On the other it's a little hard to let go of the fact that I no longer control all of the software on my own diskspace - even if, admittedly, that has been an illusion for many years now.
Is there an issue with mitm attacks at hostile wifi points of access? Dns pointing to a bunk certificate authority maybe? I am not fully versed on this though so I don't know how possible this attack is.
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 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 that a fraudulent CA can't hijack the connection with a forged certificate [2][3].
(As a side note, the fact that this is necessary points out some of the major risks in the current CA system, which will hopefully be addressed in whatever eventually replaces it...)
Even if possible, all of those would be independent on whether updates install silently or not - they have always been downloaded in the background automatically.
> Based on the Verified Email standard, Firefox users will be able to log in to Firefox to enable Sync and user-centric site logins. Users will finally be able to say goodbye to remembering countless passwords.
This! It would be great if Firefox could automatically log you into websites you already are registered on and have associated with your FF login.
It's already being used for sign-in at https://developer.mozilla.org/, and it will only get better once browsers and identity providers ship native support.
Off topic (somewhat)... I have also been using the latest Firefox Mobile nightlies on my tablet... wow. It's responsive, it's slick, it's fast... it's buggy... (it's a nightly). It's also a sign of brilliant things to come from Mozilla this year. I can't wait for the current Mobile nightlies to hit open release.
The release versions of Firefox Mobile were good enough to be the default browser on my 7" HTC Flyer tablet, but don't seem to handle the bigger resolution of Transformer Prime that well (lots of screen flickering when scrolling).
I just tried their Aurora nightly, and there things were quite smooth. Not yet Chrome-on-Android smooth, but getting there.
As always, Firefox Sync is the killer feature on mobile.
I still see a lot of areas in the process of being redrawn while I scroll.
A lot better than "this process is frozen, Kill?" that I get with Browser, though.
I didn't check yet with Aurora, but do you handle keyboard shortcuts? One thing that keeps me with Browser instead of Chrome is that it supports desktop-style shortcuts like Ctrl-L and Ctrl-R when I'm using the hardware keyboard.
Oh yes! Strong second for keyboard support in Firefox Mobile. I have an ASUS Slider, also with a hardware keyboard, and I keep wanting to go back to the keyboard when browsing. I know it's not common on tablets but when you do have a keyboard attached (or built in) it's great to have.
I've found aurora (otherwise excellent) will not scroll overflowing elements in the web app i'm developing. I can't say i've been able to test other sites since i can't think of any off the top of my head, but safe to say all other mobile browsers have worked (FFm, beta, Opera mobile, android browser and chrome-android). Is it lacking support for overflow-y / x ??
I was going to PM, but apparently there is none here, so sorry for the slightly OT.
I know that for me, loading of content while scrolling is terrible. On a forum where few images are shown, I find that quickly scrolling to the bottom of a page results in a pretty noticeable pause before rendering content.
It seems to be significantly worse when zoomed in. If it matters, here's a link to a page where I always see this behavior, though I think it's really pretty endemic: http://kolspading.com/forums/viewtopic.php?f=2&t=3
(This is on a Galaxy Nexus.)
-edit-
Oh, just noticed that my other pet peeve bug seems to have been fixed! :) When loading a link while zoomed in, you no longer see a flash of the current page zoomed out.
Thanks, that's very helpful feedback. Indeed the slow rendering/blank content problem is our top priority right now. We're working around the clock to improve its performance, switching from the Java stuff that's on Nightly right now to the same backend used to render OpenGL-accelerated content on desktop.
The only unfortunate thing is the sole focus on the native Android UI now, due to limited resources. Conventional mobile Linux which has to use XUL based mobile UI is treated as barely supported because of that.
I really think Firefox should have nailed down addon compatibility and silent updates before embarking of this FF4+ versioning adventure. It's good to see that they are both on the roadmap, but I fear it's too little too late.
As far as I understand it, they did largely nail down addon compatibility at least around the same time as the rapid releases began. Addons hosted on addons.mozilla.org have since last April [1] got automatic compatibility bumps each time a new version of Firefox is released.
What they didn't realise was that only 25% of addons in active use were hosted on AMO, and the vast majority were self-hosted. The change referred to in this roadmap is to make the browser itself (rather than just AMO) treat extensions as compatible by default (and presumably quite a lot of supporting work to make sure that's a responsible way for the browser to behave). That change has also now landed [2].
These are important problems to tackle, but we should give credit where it's due, and it's rather more than just "on the roadmap". Justin Scott gives a good overview of their thought process and actions taken: [3]
I'm tempted to agree with the first sentence, but Firefox itself did start improving very rapidly the last year. It's very hard to say, even in retrospect, if the add-ons debacle was worth it or not.
As for "too little too late": I presume you're talking about winning back people that went to Chrome because of the add-on and updates situation? This might be true, if those people are happy with Chrome, then Firefox will have to draw them back by executing better on other features.
They introduced the infrastructure (bootstrap and jetpack) around Firefox 4.x, so there have been addons that can update without restarts. The problem is people need to port addons to the new api.
I recently read about a Mozilla authored extension that gives you more performance insight. I think some features only work with special FF builds right now, though. :)
> The Firefox update process will be moved to the background and Windows admin passwords and/or UAC prompts will be removed.
Oh, God, no. If Chrome does it this way, it is not a reason to blindly copy the idea. Why the hell would I want another privileged process running on my machine?
Chrome doesn't run a privileged process, they just install the binary on user directories (specifically %LOCALAPPDATA%\Google\Chrome on Windows Vista/7). Firefox could do the same.
Because it's the best solution to deal with the problem at hand (updating another process's .exe without requiring an UAC prompt). Google and Mozilla aren't idiots, you know. Internet Explorer can circumvent this due to being able to use Windows Update. Safari and Opera (AFAIK) don't do rapid release.
Well, no, it is not the best solution by a wide margin.
There is no reason Firefox has to go into a system ProgramFiles directory when it is installed by a user. It needs to go into the user's ProgramFiles. If it is installed by an admin, then, yes, it should go into the system directory, and it is reasonable to have the updater process run as a system service. But if it's me, Joe User, installing Firefox on a shared box for my own use, then (a) I should really be able to do that within the confines of my account permissions (b) the updating mechanism should also fit into the same set of restrictions.
Just think about it for a minute.
PS. "Google and Mozilla aren't idiots" is not an argument. Microsoft aren't idiots either, but look at Vista.
But Firefox already works like that. If you install as a (non-admin) user, it goes into your user dir and there is no update service.
If you install as an admin user, it goes into Program Files, and by your own admission, there's no other way to update it than to have the update service.
The new "Australis" theme (on the roadmap for 2H) looks like Mozilla is trying to copy Chrome yet again. Don't get me wrong, Chrome does a lot of things right, but shouldn't a browser have some sort of... unique visual identity?
True. Merging the search box and urlbar is a logical step. I was worried at first at blurring the distinction between "search in my local bookmarks/history" and "send to Google", but if it works like in the mobile browsers than I might be able to live with it (show local results and offer "search on google" as an option). But I wonder how usable that would be with many search engines.
Don't like:
- The Firefox menu at the top of the window is moved to a Chrome-style settings menu on the right. Yet, no vertical screen estate was won. (I realize why this is: the top must remain free to make the window draggable, but it also shows how pointless moving it was, as you've now lost horizontal estate for no gain)
Makes sense:
- Home button replaced by home pinned tab.
- New downloads UI. Prior to 4.0 I used an extension that showed something similar to what you see in those screens.
Regarding the menu, no vertical space may have been won, but definitely a bit of horizontal -- it looks like there's enough room for an additional tab there now, which is nice. (maximized on 1366*768, it's rare that I never have tab overflow)
If you often run out of tab space, reduce the minimal width of tabs. I don't quite remember the exact variable in about:config but I was always able to find it (search for width probably). One of the first things I had to set when I was using Firefox as my secondary browser. It was 3.x but I don't think they would remove the little configuration they offered.
> Merging the search box and urlbar is a logical step.
Hmm, I hope there's an about:config setting or an add-on to undo this change. I have the urlbar and the search box assigned to different search providers. The first is accessed by Ctrl+L, keywords, Enter. The second is accessed by Ctrl+K, keywords, Enter. If there was only one search bar, I'd have to click around a bit more.
On the other hand, I completely agree with you about moving the Firefox menu. That orange button has been a distinguishing feature of Firefox for the last few releases. Moving that button to where Chrome puts its settings menu really makes Firefox look like it's losing its brand identity.
I actually think Chrome actually has a superior search interface. You start typing the keywords for the site, then hit tab and you'll be using the search for that site. It also picks them up automatically when you visit the site. I've also found it bad that firefox needs an extension to search an alternate site without changing the default.
Firefox offers the same keyword search from the address bar - you just have to define them in 'Manage Search Engines' (accessible from the drop down in the search bar). Defining Wikipedia as 'wp', YouTube as 'yt' etc, make searching much easier than using the search box.
I was actually pleased by how different it was. The only glaring similarity is the top level tab being curved. I thought they'd done a good job of stealing the advantages whilst keeping a visual separation.
The Firefox button has also moved to the right of the address bar, or at least I think that's what that button is. If anything, that's an even more glaring similarity than curvy tabs. Personally, I don't mind curvy tabs, they're pretty.
My understanding is that Google licensed the FoxIt PDF viewing engine to embed into their Chrome binaries. It probably isn't available in the open-source Chromium.
Firefox already has an absolutely excellent (third-party driven) devtool, at the root of basically all modern (browser) devtools, in Firebug. Firebug is pretty much the source of Webkit's Developer Tools (Safari and Chrome), of Drosera (Opera) and even of the utter dreck that are MSIE8+'s builtin developer tools, and one of Firefox's greatest gifts to web development (along with taking down MSIE and the idea that following standards might be a good idea from time to time)
It's not perfect by a long shot and it does have issues (which get addressed over time), but it's there and more importantly its good.
Yet they are reimplementing it bit by bit, in a less-integrated, less practical, and overall shittier way.
Why?
Why is mozilla wasting time on that?
Why couldn't they instead focus on making Firebug better and providing a better, deeper integration between Firefox and Firebug? Or by developing new API and panes trailblazed by the Webkit devtools (e.g. rendering timeline)? In fact, why not look into merging Firebug into Firefox pretty directly (disabled by default of course)?
Does anybody know? Because it boggles my mind, Firebug has had a complete console for ages and Firefox 9 added a shitty one (which mostly spends its time being spammed by irrelevant garbage due to not having a network tab) as a "quake console" (opens from the top), and Firebug has had an (excellent) DOM inspector for ages (again) and Firefox 10 adds a completely shitty one[0]... but at the bottom of the window so using both the inspector and the console takes twice as much visual space, and if you open the "styles" pane your visual space shrinks down to a postcard.
Please help, because they've lost me completely with that strategy.
[0] seriously, can't create new attributes, can't add content to an empty one (can only change existing non-empty content), pointlessly huge breadcrumb trail, blue-on-black theming which looks completely out of place, no autocompletion of CSS properties, no hyperlinking of CSS files or elements, no layout display, no object inspection, no DOM changes breakpoints, no HTML edition, no separate window, what's there is barely useful, we're talking IE8-level of functionality (of the inspector tab, IE8's devtools at least have a debugger) if even that (thought hopefully not as terminally buggy) and I'm probably forgetting half of it