Jeez FF really stepping up the game. Seems like 32 was released just yesterday.
I'm not sure if there are any performance issues since I switched to FF about a year ago when bought new laptop with SSD and 16 gigs of ram it's as fast as Chrome. As for webdev tools, they are not worse, you are just too used to webkit ones. I might even say that FF has better dev tools because you can modify request and re-send it.
I switched because Google is trying to integrate Google too much into Chrome. That's definitely not something I look in a browser since I would like it to be independent and not spy on what I type/do.
Anyway, if anyone who is contributing to FF reading this I just want to thank you for best browser ever.
> I'm not sure if there are any performance issues
I also use Firefox on a MacBook Pro(2014), I don't know if this existed before or not but, under battery > Apps using significant enery, Firefox is one of em', opening the same exact tabs on Safari doesn't show safari on the list
is this because apps that come with Apple are not included in the list or is Safari better at Energy consumption?
Yeah, Safari is good at it. I seem to remember that Apple has had battery-consumption measurement instrumentation that they only made available to outside developers recently.
We have an ongoing project to make Firefox very good, too, but as all big projects, this might take time.
You still can't edit JS like you can in chrome devtools. This is such a boon and a basic thing, really, that I can't switch until they add it. Aside from that, yeah, FF is getting pretty good.
> Improved search experience through the location bar [1]
Really happy to see this one. Previously single-word searches were so slow that I'd usually have time to remember that they are slow, press C-e, and enter the same search term in the search bar, all before the browser realises there is no matching host and does a web search instead.
I really hope this also fixes Firefox's behavior with one word searches and misbehaving DNS servers. Previously, if your DNS server returned advertising for bad DNS queries, one word "searches" would result in displaying your DNS server's ad page (since Firefox did a DNS query, assuming you meant a hostname instead of a one word search). This has been broken behavior in Firefox for quite awhile, with no workaround other than to install a different omnibar. I don't understand why Mozilla thought treating single words as hostnames in the omnibar made sense for the majority of people, especially when the majority of people are also subjected to misbehaving DNS servers.
You shouldn't be searching in the URL bar. There is a search bar for that. If anything, it should be a toggle to allow searches to execute from URL bar input, but for IT folks and others who recognize the distinction, searches from the URL bar are frustrating and insecure.
Since Firefox tells users to "Search or enter address" in the location bar, I don't think it's correct to tell users trying to search that they're using it wrong. The issue described by fpgaminer is a legitimate problem.
The fact that some may prefer stricter segregation between URL and search fields is a separate issue, as is the behavior by certain ISPs that triggers this problem.
There's "you shouldn't be ..." and then there's "what most people outside the tech world do". There is a lot of overlap between the two. In the real world, for whatever reason, many people use the location bar as a search box.
Now, I'm not agreeing with FF's decision; just pointing out how it is IRL.
Additionally, in the real world, people use the google search field as a URL bar. It really boils down to people just not understanding how things work / are supposed to be used.
You took the words right out of my mouth! I have worked on dozens of sites in all different industries and the one thing that unites them all: Google Analytics traffic shows that many people punch in a full domain name into Google and rely on Google to display the result they want.
If your website is http://hackastack.com I doubt you'd go a month without seeing a referral from Google for a search for www.hackastack.com or something similar, even if you don't use 'www' on your site
Do you have research to back up the statement that "searches from the URL bar are frustrating"? I could cite Chrome's market share as an indirect, empirical study indicating the contrary.
Regardless, your comment is tangential to mine. My comment was about a bug in an existing Firefox feature. Whether that feature should exist in the first place or not is only tangentially related.
I'm pretty sure Chrome's market share is more related to it being advertised on TV, google.com, and being bundled with other software than because of the Omnibar...
That's actually the thing I want to make sure I can entirely disable before even thinking of updating to FF33. I'm sick of browsers and other software trying their best to send as much data as they can to search engines (hi google). If I want to perform a search, I do it, period.
I know it's absolutely not the case for most users, though..
I'm pretty sure that Firefox doesn't send anything from the location bar. At least, my location bar doesn't perform any search outside of history + bookmarks, unless I press "return".
Nope. On FF33, when I type in a one-word, no-TLD hostname in location bar, it takes me to my default search engine, while asking "Do you want to go to hostname?"
The whole point of having separate bars is to clearly distinguish use, and to ensure data doesn't leak. This bothers me, too.
Note that you can use `//` prefix to mean `http://`. E.g. if you want to go to `http://foo`, you type `//foo` in the address bar. You can also use `//` URLs in HTML, it expands to `http://` or `https://` depending if the page is served via HTTP or HTTPS (this is cross-browser)
that's an interesting one. I usually use a single quotation mark when searching a URL since Google doesn't interpret it as "verbatim" anymore and seems to just discard it.
Did you type // and not \\ ? \\ does expand to file:/// for me, trying to open a network share. But // to file:/// never happened to me.
BTW, actually it seems that if I type `//foo` and `http://foo/` can't be resolved by DNS server/hosts file, Firefox does Google search, while Chrome tells that 'webpage is not available'.
> On FF33, when I type in a one-word, no-TLD hostname in location bar, it takes me to my default search engine, while asking "Do you want to go to hostname?"
Do you mean after you press enter? I can't replicate your finding for words that are simply typed into the location bar.
Especially if there's support for jquery-bound events as current inspectors are kinda useless for those (they link to jquery's internal binding functions)
It will be incredibly valuable in 6 weeks when 34 lands in stable. Or you can use Firefox Beta 34 when it launches this week and try it out now. If you choose to try the beta, you can use Firefox Portable in beta form to keep it separate from your standard local install. We generally release it same day or next day as the standard beta.
I have come to realize that these more extended elements (things beyond <select>, and input types such as password, text, or email) are actually pretty evil. Let me make a small argument in favor of this view:
1. They will provide different UI across different desktop browsers/OS's, etc. The theory was that the browser can decide what the datepicker should look like. The practice is that half of them are ugly or lack the UI you want and you can't do much to fix that.
2. What the UI looks like is still in flux and will likely remain in flux. This means that not only do you have to test/support all the currently provided UI, but you also have to be ready for unexpected changes in the future.
3. Specifically because you cannot change what the (fairly complex) UI looks like, you cannot make it match your theme. This can be a huge pain.
4. There are better JS-based datepickers out there for the desktop.
The only reason to use <input type="date"> IMO would be for a mobile-only site. iOS/Safari uses a stable native date implementation which is awesome. However, on the desktop, there is no standard datepicker widget to use the same way, so it just ends up looking weird.
What I would actually love is an <input> type that lets me just type in a date (think a date of birth field) where the input is perfectly validated. That's right, in 2014 with out state of the art browsers, this is still nearly impossible. Sure you can use a regex, but have you tried putting together a regex that validates 2/29/2012 vs 2/29/2014 vs 2/29/1900? On top of that, the patter= attribute doesn't prevent you from typing/pasting, it only provides a place to put validation that's optional. A callback mechanism for as-you-type validation would be so much better.
> 1. They will provide different UI across different desktop browsers/OS's, etc. The theory was that the browser can decide what the datepicker should look like. The practice is that half of them are ugly or lack the UI you want and you can't do much to fix that.
In theory they'd be more consistent across the platform, just like text and select boxes; I'm not seeing the problem. You're site doesn't need to have it's style imposed on every single control.
> 2. What the UI looks like is still in flux and will likely remain in flux. This means that not only do you have to test/support all the currently provided UI, but you also have to be ready for unexpected changes in the future.
Why do you care what the UI looks like? As long as the API is stable.
> 3. Specifically because you cannot change what the (fairly complex) UI looks like, you cannot make it match your theme. This can be a huge pain.
I count this as a plus, honestly.
> 4. There are better JS-based datepickers out there for the desktop.
Ugh. The less we rely on javascript for basic functionality the better.
You're js, highly themed date picker probably isn't very accessible and probably doesn't function like the rest of the system does either.
The more we can leverage the User Agent, the more we should. It's easier on developers. It's more accessible. It's more consistent across the user's platform.
> In theory they'd be more consistent across the platform, just like text and select boxes; I'm not seeing the problem. You're site doesn't need to have it's style imposed on every single control.
I agree about the in-theory part. In practice, it has not happened.
> Why do you care what the UI looks like? As long as the API is stable.
I don't. The designers do. And if one of the four major browsers looks like crap, the design doesn't get scrapped, but the datepicker does.
> Ugh. The less we rely on javascript for basic functionality the better.
Right. Then give me a validated input field where I can say "this is a date. Don't type in anything else" and the browser makes it work. Nobody has done that yet.
Basically, there is a difference between how things should work in theory and in the ideal world, and then there is the mess we deal with now and for the next 5-10 years. I'd rather have an imperfect solution that saves me developer time and gives the user a better experience, than a perfectly engineered solution where the only good thing is the API.
> I agree about the in-theory part. In practice, it has not happened.
Just like text boxes and select boxes, right? Which is why everyone is trying to re-invent them too? We all know how much those are loved.
> I don't. The designers do. And if one of the four major browsers looks like crap, the design doesn't get scrapped, but the datepicker does.
Obviously you do care otherwise you wouldn't be having this conversation. Also, the default controls don't look crappy.
> Right. Then give me a validated input field where I can say "this is a date. Don't type in anything else" and the browser makes it work. Nobody has done that yet.
Then you need to educate users on what a valid date looks like. I feel that that's much harder than using a standard date control.
> Basically, there is a difference between how things should work in theory and in the ideal world, and then there is the mess we deal with now and for the next 5-10 years
It's only an issue because everyone seems to think having absolute control over the look of their website at the expense of usability.
> I'd rather have an imperfect solution that saves me developer time and gives the user a better experience, than a perfectly engineered solution where the only good thing is the API.
I have no idea what you mean. Easier for the developer and better user experience would be the built in date picker. A built-in datepicker should be following a standard API similar to every other HTML element.
The difference between <input type="text"> and <input type="date"> is that the former has been around for 2.5 decades and looks nearly identical across all browsers, while the latter does not/is not. Also, note that you can style <input type="text"> quite a bit: different fonts, different border, different colors, padding, adding icons, placeholders, focus/unfocus behavior. Lastly, note that text inputs are extremely simple: the interaction is to get focus, type/select/copy/paste/unfocus. A datepicker is orders of magnitude more involved.
Design-wise, yes it matters a great deal. Once again on iOS, <input type="date"> works better than any alternatives. On the desktop, it is markedly worse: you get strange colors, weird layout that doesn't match your design, etc. The look and feel is in the weird space design-wise: it doesn't match anything in your OS, but it also doesn't match the site's design (almost ever).
Once again, in theory a nice well thought-out universal datepicker built right into the browser would be fantastic. In practice, I don't see that happening and the inferior JS-based alternatives end up working better in real-world products.
> The difference between <input type="text"> and <input type="date"> is that the former has been around for 2.5 decades and looks nearly identical across all browsers
So because something hasn't been around we shouldn't get it to exist.
> Also, note that you can style <input type="text"> quite a bit: different fonts, different border, different colors, padding, adding icons, placeholders, focus/unfocus behavior. Lastly, note that text inputs are extremely simple: the interaction is to get focus, type/select/copy/paste/unfocus. A datepicker is orders of magnitude more involved.
This couldn't be done for a datepicker? Those behaviors and styles couldn't be standardized.
> Design-wise, yes it matters a great deal.
And this is how we get buttons that don't work correctly with keyboard inputs; people reinventing the wheel because they can't stand not having absolute control over every aspect of their design.
> Once again, in theory a nice well thought-out universal datepicker built right into the browser would be fantastic. In practice, I don't see that happening and the inferior JS-based alternatives end up working better in real-world products.
Once again, I don't understand why people think having a myriad of input styles and behaviors via JS is better than a speced standard input supported by the majority of browsers, accessible, and well-defined behaviors.
> Once again, I don't understand why people think having a myriad of input styles and behaviors via JS is better than a speced standard input supported by the majority of browsers, accessible, and well-defined behaviors.
Because there is no speced standard input. The only speced part is the API and the markup. The implementation is left entirely up to the browser.
Once again, I am going to try to condense my point: date input is a great idea. A sane simple API for the datepicker would be great. In practice, how the widget looks and works (not the API, just the UI) has been left up the browser vendors who proceeded to screw it up on the desktop. Only one desktop browser currently supports it, and does a very poor job of making it actually usable. As is, <input type="date"> cannot be used on the desktop, IME. As I see no movement to actually spec out the UI, or to actually implement a standard customizable datepicker across all major desktop browsers, I think this effort should mostly be abandoned.
Instead I would like to see one of two solutions: (a) keep <input type="date"> and its associated API's, etc. but allow developers to at least override the default widget. (b) Scrap the entire thing and start from scratch on a new spec that politically people can actually get behind.
> The implementation is left entirely up to the browser.
This is the problem. Why not make standard inputs have OS-based UIs instead of browser-based? It would at least provide some design consistency. Could be harder to implement though.
Also adding that internationalization, IIRC, for native date input on the desktop is entirely based on the browser locale.
That's neither user friendly nor developer friendly. It just sucks.
Can i18n become a real concern for specs anytime soon? The non-US world at large would be grateful.
In fact, these HTML5 form features have just basically fragmented the development of mobile and desktop web pages. If we're gonna have different sets of features for different platforms, that's fine. Just be clear about on the api level. It was better when the date input was not even implemented on the desktop, at least we could detect it and shim accordingly, now it's basically a false positive since it's implemented without any real effort.
> In theory they'd be more consistent across the platform, just like text and select boxes; I'm not seeing the problem. You're site doesn't need to have it's style imposed on every single control.
Right, but what happens when there is a problem with the datepicker? How does the web dev debug that? It could be on the browser end, could be a problem with the html, or even the backend? What a nightmare.
It's not just CSS, though that's a part of it. What if you want to customize labels? How about error placement? Behavior when you click outside of the widget? More complex open/close interactions? Even a simple <select> gets re-implemented every so often (chosen.js) because it's use cases are too complex for what it can do. A date picker is so much more complex than that.
Which is why my complaint is about the desktop. As I mentioned, on mobile the widget actually works correctly: it looks like a native OS datepicker. Native OS datepickers do not exist on the desktop: not in the browser, not anywhere else, unless you count the Windows clock dialog.
Wow. I had no idea that Firefox lacked support for <input type="date|datetime|datetime-local|time">. I was just assuming that it did, simply because "it's not IE".
So here's something I've noticed that's confused me about Firefox's cookie handling: I have cookies turned off, but a PREF cookie for google.com keeps getting set. I've even tried blocking cookies from google.com, but I still see this cookie. I turned off Do Not Track but haven't tried disabling SafeBrowsing or all my extensions, so maybe it is one of those. Has anyone noticed this, too?
Google's Safe Browsing API (malware and phishing protection) requires a cookie. But Firefox puts that cookie in a separate bucket than the one used for regular requests. If you have cookies enabled, you'll actually end up with two separate google.com "PREF" cookies - one for regular HTTP requests, and one just for for updating the Safe Browsing lists. Disabling Safe Browsing will prevent that cookie from every being sent, and should allow you to delete it (EDIT: modulo the cookie manager bug below).
Got it, thanks. I've disabled Safe Browsing and the cookie is gone. I'm curious: Does the Safe Browsing API offer any privacy guarantees? I confess that I don't really know how it works, although based on how it works with ClamAV, I assumed that Firefox periodically downloaded something from Google that let Firefox check a given URL against a list of known-bad hashes. If that's the case, I wouldn't mind leaving Safe Browsing enabled.
> I assumed that Firefox periodically downloaded something from Google that let Firefox check a given URL against a list of known-bad hashes.
Yes, that's basically how it works. Firefox periodically downloads a database of blocked URLs. Before loading a web page, it checks this database. If the check is negative then Firefox displays the page normally. If the check is positive, Firefox will also send a hashed URL to the Safe Browsing server to double-check whether to block the page or not.
This page has more documentation, including a link to the API specification:
Haven't verified your claim but according to the linked bug, one has to wonder, what the Mozilla folks have not understand what "no cookies" and DNT means.
Oh, and Google should _really_ provide their Safebrowsing API without a cookie, too. Youtube-nocookie.com works fine too....
It's more likely to be associated with built-in malware protection/phishing protection from Google. In Firefox's settings under Security, you can un-check "block reported attack sites" and "block reported web forgeries" and these cookies should disappear after running BleachBit.
these types of cookies may seem benign and helpful to users (and maybe they are), but i also wouldn't doubt that Google uses this information for persistent tracking.
At first I was only concerned about web page access tracking via this cookie (which indeed is set because of Safe Browsing---I turned both settings off, cleared my history, and the cookie is gone). If this cookie could be abused for location tracking, maybe it would be a good idea to leave Safe Browsing disabled.
I use Firefox as my main browser but that is, sadly, not true. Chrome remains faster, especially with js heavy webapplications. Some don't work in fx at all.
> Chrome is the only app I have on my Macbook Air that pushes it into overheating, turning it into a lap-frying iron skillet.
This is even more obvious on older Macs. I've got a Core 2 Duo mini that absolutely chokes on more than a few tabs in Chrome/Chromium, but runs acceptably well with Firefox even with ten or more tabs open, and flies with Safari. I really wish someone would put out a Chromium based, stripped down browser for OS X versions older than Mavericks. I think the rendering engine is solid, it's all the fluff that slows it down.
Really? In my experience, JS heavy web apps work better with Firefox. What Chrome does better, though, is letting you switch to another tab or close the tab while a JS (or DOM)-heavy app is taxing your CPU.
What Chrome does better is identifying a few key features, and then throwing a multi-million dollar sales and marketing team at it, until enough people think its the best browser again.
(then hiding user lock-in as innovative, minimal UI)
Things like js-native games, heavy visualizations, such as the one on http://acko.net (his logo for example, otherwise take a look at his webgl renders)
Chrome also does better at hardcore number crunching, somewhere on the web, there's a demo webapp that tries to recreate images using procedural and genetic algorithms. I tried to find it, but I couldn't find it. Performance on Chrome however, is a lot better than on Firefox.
Interestingly this is not mentioned in this huge post, but according to http://arewefastyet.com/ Firefox JS is faster than Chrome and Safari in all benchmarks in both 32 and 64bit modes since quite a few month!
It used to be that Chrome marketing was pushing for this as being so much faster on Chrome than others so that's a pretty nice feat.
Because JS Speed don't matter any more, at least out of 90% of times for 90% of internet users.
Speed for casual users, means rendering speed, network speed, Browser and web page responsiveness, startup speed etc. Although Firefox did make many incremental steps over the years. It is still not anywhere near the Blink / Chromium offers such as Google Chrome and Opera.
e10s should make Firefox competitive. And its still quite a while before it lands.
I agree that native to OS X would be nice, but I would immediately disable over-scroll if it were on by default.
Luckily, FF is pretty good about giving power users this kind of flexibility. I haven't found a way to disable it on Safari for instance, though it's not my primary browser so it's not too big a deal.
Another small OS X thing that FF is missing is three-finger tap to view dictionary definitions.
The Latin1 optimization looks interesting. It seems like a big improvement for such a simple change (granted that it took one developer two months to do).
Activity Monitor reports that Firefox 32.0.3 is using 21 GB on my Mac. That makes for sluggish performance, even with 32 GB of RAM. Looking forward to trying Firefox 33.
If you go to about:memory, you can get a better breakdown of how memory is being used. If you see something that looks out of the ordinary, please file a bug in Bugzilla and add [MemShrink] to the whiteboard!
Yes, this. While extensions are often the cause of high memory usage, it's not always the case, and immediately blaming extensions makes people accuse Mozilla of passing the buck.
If you ever see someone complaining about Firefox's memory usage, looking at about:memory is always the first step you should tell them to take. The amount of information can be overwhelming but in extreme cases like this it's often fairly obvious what the problem is -- look for the biggest measurement! And if it's still not obvious after that, communicating with Firefox developers (e.g. by filing a bug) usually results in progress happening.
Yes, it is insane. I've actually never seen it that high before. I get annoyed when it's over one or two GB.
There has to be a leak of some kind, but I don't know how to diagnose it. Activity Monitor has me at 756 MB right now, but it will creep back up over the next few days.
> There has to be a leak of some kind, but I don't know how to diagnose it
Nicholas Nethercote's blog[0] has many entries on memory, memory profiling &al as he's one of the big "memshrink" guys.
about:memory might be a good start, after reading his memshrink entries[1] and maybe contacting him.
Although the very first order of business is to check your extensions, extension leaks is the most common source of trouble (and has been for a long time). Disable everything, see what happens, then re-enable extensions one by one.
Your insane memory usage is probably due to some plugin or other. Adblock is known to consume something like 40mb per tab open for example, due to injecting a large stylesheet into every single page ever opened.
> Adblock is known to consume something like 40mb per tab open for example
Nope. It's more like 4 MiB per iframe.
ABP is a well-written extension, and I am 99.9% certain that it is not the cause of a Firefox instance taking up 21 GB of memory. Please don't spread misinformation.
Apologies, I definitely misremembered the facts and should have checked up on it.
I wonder how many iframes the average page has though, especially given Facebook like buttons and similar widgets. And someone like me, who maintains hundreds of tabs, could easily take up a few gigabytes of memory per addon, even if the amount of memory used for a single frame isn't that high.
I'm sure ABP was not the cause for the entire amount of memory in this case (or perhaps not at all), but many addons, each adding a bit of weight, can add up quickly.
The only true fix is to remove it, although changing the ruleset and finding out which tab has humongous numbers of iframes is probably a good start: according to link 1 ABP has a static memory consumption of ~60MiB, plus 3~6MiB/iframe (since it's caused by the stylesheet size, I expect the precise ruleset impacts that)
Wow, that is just insane. Checking right now, it uses ~950MB for me on GNU/Linux. That's with 14 tabs (among which 2 that use flash player) and 20 active add-ons (gestures, self-destructing cookies, header modifier, adblock plus, etc.).
CPython did something similar (though more expansive, it switches between 4 different internal encodings depending on string content: ASCII, latin1, UCS2 and UCS4) in 3.3 with the PEP 393 "Flexible String Representation". I wonder if this Moz change was independently reinvented or inspired by the FSR.
Please tell me, how to return the gray background in a new tab?
And how to return to the number rows and columns of picture thumbnails not decreased when the window changes at
half-screen, non-rounded thumbnails?
That new UI makes me sad...
It looks like you still have the same number of rows, but each tile got larger so they can't all fit on a laptop screen anymore. If you zoom the page out (Ctrl/Cmd + minus) a few times, the bottom row shows up.
Firefox guys in this thread, how do we get the old sizes back? 9 thumbnails > 6.
The about:config prefs for "browser.newtabpage.rows" and "browser.newtabpage.columns" seem to work in Firefox 32, but not 33. I don't know if this is a bug or a design change.
UPDATE: This is Firefox bug 1005596. The prefs only work when you zoom out.
It looks like something about the tabs changed for Firefox 33, but I really can't tell what from that document. The two notable parts I saw were:
- If there is not enough space for the fixed size tile and it's gutters, rows and/or columns are removed from the grid.
- In the Tile Grid, there will be Top Sites tiles (based on user frequency), but also Sponsored or Partner tiles.
I don't know why the first one changed (as opposed to just scaling the tiles like they did before). The second one seems like a whole different scary thing.
I'd love a black background for new tabs. For that matter, most of the internet is too bright in my view; luckily there's some good plugins and bookmarklets to address this.
still no cookie UI fix.... very disappointing, especially for an organization that claims to pride itself on protecting user privacy while dropping google analytics and google cookies on users... probably because they're so heavily dependent on google's money.
when you go to getfirefox.com, you'll be tracked by google analytics as you're reading about mozilla's "commitment to your privacy".
think one cookie is better than two? maybe, but the context matters here. it took mozilla seven years to stop sending other google cookies along with safebrowsing update requests, including about half a year after the washington post reported that NSA was using this behavior/functionality for targeting: https://bugzilla.mozilla.org/show_bug.cgi?id=368255
Mozilla never seems to have anything to say about Google PREF cookies being trivially correlated to google logins from the same IP within a certain timeframe.
more to the point, Firefox still can't be trusted to even tell you which cookies have been dropped in its default configuration through the UI, let alone have a default configuration that limits persistent forms of tracking from its primary sponsor. i find this galling given their marketing push around mozilla's "commitment to your privacy".
I'd be delighted to use FF on iPad. I do a lot of leisure browsing/reading and I want to support FF on all my devices. Is their stand still the same i.e. We refuse to bring Firefox to iOS until Apple lets us use our web engine ?
Yes, Apple is definitely to "blame" as far as handicapping UIWebViews are concerned. That being said, the new WKWebview is supposed to have all the Javascript optimizations (and the Nitro engine) that mobile Safari uses.
Chances are that it might still not be as fast as Safari, but Firefox should bite the bullet and just do it because:
a. Firefox cannot afford to not be on all platforms. With computing devices converging and relying on handshakes (data syncing?), missing out on a major mobile platform is foolish.
b. In a related point, syncing bookmarks/tabs via Firefox sync is severely handicapped by it's absence on iOS.
c. There is a fantastic niche where FF can fit in on iOS. It'd be as privacy centric as Safari and with an iOS launch would be cross-platform like Chrome (without Google peddling their products front and centre). They could also get some inspiration from mobile Opera on iOS that has fantastic data saving features in-built.
For what it's worth, WKWebView is still astonishingly buggy and hangs quite a bit when loading some pages with XHRs. There are some other bugs that trigger these 10+ second hangs, but we couldn't delay shipping anymore so we reverted back to UIWebView.
Darn. Thanks for letting me know. I was thinking of starting to experiment with WKWebView for an app that currently uses UIWebViews.
So I guess FF using WKWebViews (even if they can get over the philosophical/techinical difference with Apple) is some ways off.
Well, Apple is also definitely to "blame" for forbidding Gecko on iPhone, a number of years ago. I may be wrong, but I seem to remember that there used to be a prototype build of Firefox Mobile that ran on iOS, but Apple made it clear that it would not be accepted on the Store.
Developing an Apple-compliant Firefox for iOS would mean developing an entirely separate browser, which basically wouldn't share a single line of code with either Firefox Desktop, Firefox for Android, Firefox OS or Firefox for Firefox OS, plus it would be using a (reduced version of) WebKit, so it would not have the same behavior as the other Firefoxen and it would require yet different Firefox Development Tools.
If this platform was a high priority, this might be feasible, but it might take several years, at the expense of some other project and Apple would still be in position to shoot down Firefox for iOS (again).
So I don't think that this is going to happen any time soon.
I agree Apple is to blame here. But, disagree with the logic.
> What's the point in them wasting their time just skinning something that is guaranteed to be slower than Safari
I'd say, consistency of user experience and sync'ing my bookmarks etc. Skipping iOS means you are losing a reasonable chunk of users who fall in the category of wanting the same browser on all their devices.
That's a developer POV. For users, Firefox is defined as the browser with that specific look and feel, that landing pages, those awesome plugins and marketplace, that tab sync, that password manager, etc.
You'd be hard-pressed to find a single non-developer who is even aware there is a difference in rendering engines (or javascript engines). The maximum they might know is that "this site is broken with that browser", but that won't relate to "rendering engine" in their mind.
So brining Firefox to iOS would give an awesome benefit for many users that love Firefox on the desktop, and encourage others for which the absence of Firefox on iOS is a nuisance or a blocker in its adoption.
It would be like selling a Jaguar with a Ferrari engine; still a weirdo, but at least fully functional. You can't seriously claim Mobile Webkit to be to a (theoretical) Gecko-on-iOS like a Fiat to a Jaguar.
And people are not "too dumb to realize". The whole point of the HTML standard is to make sure that all browser render the same. The whole point of the standard, and all the efforts of all the browsers, go towards a single goal: making all pages render equal on all browsers, that is making people NOT realize there is a difference; the technical problem of different codebases exhibiting different behaviors in rendering is just that, a technical problem to be solved.
I maintain that the developer-centric position of focusing on Gecko and thus refusing a iOS port as "useless", is actually doing Firefox lots of harm in its adoption. Firefox is the product, not Gecko.
Moreover, even if Apple eventually lifted the restriction, you want to be ready that day; you would still have to port the whole browser in addition to Gecko, including non-trivial issues like the extensions, and coordinating a solution for using extensions on all mobile platforms require years; the ecosystem of extensions need to adapt and evolve over the time. Releasing, maintaining, optimizing and evolving a Webkit-based Firefox on iOS would be still a gigantic effort and would still bring benefit; you're then free not to use it, if you only need Firefox as a way to use Gecko.
>> The whole point of the HTML standard is to make sure that all browser render the same.
> If that's the case, why is Webkit turning into IE6 on mobile? Apple is totally at fault.
uh? of course Apple is at fault there (and I never said otherwise), but this point is orthogonal to the opportunity of having Firefox on iOS with the current restrictions.
>> even if Apple eventually lifted the restriction, you want to be ready that day
> Better stop all work on Linux, Microsoft might release their kernel as GPL someday and all this work is being wasted. See, it works for silly things too.
Uh??? I'm not suggesting Firefox to drop Gecko, not at all. I'm saying that Firefox should use Webkit on iOS until Apple allows Mozilla to use Gecko (if ever), and that this would bring lots of value to the Firefox ecosystem and to Mozilla, because it would push Firefox market share for increased ecosystem effect.
> The whole point of the HTML standard is to make sure that all browser render the same.
If that's the case, why is Webkit turning into IE6 on mobile? Apple is totally at fault.
> even if Apple eventually lifted the restriction, you want to be ready that day
Better stop all work on Linux, Microsoft might release their kernel as GPL someday and all this work is being wasted.
See, it works for silly things too. Why should Mozilla be at the whims of Apple?
As for the straining resources, focusing on yet another product also affects me. Thunderbird has been left to rot, and while I don't really resent it because the Boot2Gecko project is very interesting, you can't just say that Mozilla should maintain a separate fork with WebKit because Apple says so. What if Microsoft does the same thing in the future, should they just fork it a third time?
The rendering engine is a non trivial portion of what Mozilla is. To be an advocate of the web user in standards discussions involving things like HTML5 and ECMAScript. If they do not have a large enough market share of web users on their engines, they will loose their voice in those discussions.
When you use a browser on the web, you are literally voting for who gets the most control of those discussions.
The "send to chromecast" feature on Firefox android app is awesome, but I was kinda hoping that they added this to the desktop application too. I know that stuff like this is usually left for add-ons, but there isn't a good firefox add on which does Chromecast, unlike the several options on the Chrome web store.
Is there even a stable, published API for this that a desktop app could use? I always believed that Chromecast support was a platform thing handled by the Chromecast API which is effectively a binary blob.
Regardless, I imagine that Firefox will end up with some sort of support for pushing streams when the MatchStick is released, but whether it supports Chromecast is a question yet unanswered.
The Chromecast libraries are available to all Android apps. On the PC, you have to actually run your Chromecast app inside of Chrome. So, Firefox would have to write an equivalent library.
"Like Hubert said, Chromecast isn't open source. Getting it to work on desktop would require some reverse engineering and may or may not be impossible (I've heard that the Desktop extension for Chrome is all JS though, so that code may be useable)."
You might also be interested in the "casting support" bugs:
It's disappointing that the H.264 video player support is not open source. Most of the patents managed by MPEG-LA have expired, and the ones that remain are either encoding-side only or for features nobody uses much, like interlace. Check out the patent lists.
Note that Firefox only uses OpenH264 for WebRTC video, not the <video> tag. OpenH264 only supports H.264 Baseline Profile, not the Main or High Profiles commonly used for embedded video. Also, MP4 videos often use AAC audio, which Firefox can't playback.
Cisco paid for the MPEG-LA licenses on that. Back in 2013, they probably had to, but more patents have expired since then, and it's probably out of patent now, unless they put in extra stuff like N-channel audio.
I think Firefox 33 also enables Direct3D 11 rendering on Windows. Can anyone confirm? I've just been digging through bugzilla and can't find a clear reference to that, but it's an interesting change if so.
(which is the destination of the not very obviously named link in the "Windows: OMTC enabled by default" change, I had followed it earlier to see what OMTC meant)
Since upgrading to the last version (32), Firefox has become a significant resource hog on my machine. It has become considerably worse than any other browser. Has anyone else had this issue?
For me it's Chrome that has been the resource hog and Firefox that has been a lot more swift. Chrome frequently uses 100% of one of my cpu cores for minutes on end and is very sluggish with creating new tabs (where it's sometimes faster to start up Firefox and use that to search than to open a new tab in Chrome). I'm not quite sure what's going on, but it seems some browsers just occasionally have issues with certain hardware configurations?
I used to have a large amount of bookmarks on the bookmark bar, which did cause sluggish tab switching. I've recently removed all of those which did improve the tab switching speed, but not the tab creation speed. I should probably do some more hunting through that issue tracker at some point...
I wish :( I've disabled them all, and checked chrome's internal task manager. It's the "Browser" task that consumes the CPU, and not one of the extension tasks: http://i.imgur.com/FvbDrMc.png
https://areweslimyet.com/ would indicate that a lot of the memory efficiency gains have been undone. N. Nethercote no longer writes MemShrink project updates and Snappy is listed under 'old projects' on mozilla wiki. Superficially, it seems like Mozilla has lost interest in the performance aspect of Firefox. I hope the opposite is actually true.
> We no longer take meeting minutes nor make progress reports, but the meetings still happen. Brief MemShrink updates are given in the minutes of the weekly Platform meeting (wiki, blog). And nnethercote still blogs about major MemShrink occurrences.
And in the post marked "The Final Progress Report" I said this:
> I was due to write a MemShrink progress report today, but I’ve decided that after almost 2.5 years, my reserves of enthusiasm for these regular reports has been exhausted. Sorry! I do still plan to write posts when significant fixes relating to memory consumption are made. (For example, when generational GC lands, you’ll hear about it here.) I will also continue to periodically update the MemShrink “big ticket items” list. And MemShrink meetings will continue, so MemShrink-tagged bugs will still be triaged. And for those of you who read the weekly Platform meeting notes, I will continue to write MemShrink updates there. So don’t despair — good things will continue to happen, but they’ll just be marginally less visible.
Time I don't spend writing MemShrink reports is time I can spend on improving Firefox's code.
We're still working just as hard on improving the memory usage of Firefox. We have MemShrink meetings every other week. Our focus on FirefoxOS has made improving memory usage more important than ever.
Open the location bar and type "about:memory" – it displays all of the memory usage in Firefox by component so you can look for hot spots.
Once you've opened it, click "Measure" and you'll get a huge tree view of memory allocations. Simply searching for "add-on" should quickly give you an idea of whether you have a known hog like AdBlock Plus or something more subtle.
Thanks. It looks like there is a huge amount of memory devoted to recently opened tabs that are now closed, especially from js heavy sites. I run a session manager extension, so that could be the source of these sites still using resources. I'll try disabling it and seeing if anything changes.
I've had quite the opposite experience. Chrome will use significantly more memory for me. Unfortunately, everything else works better in chrome so I'm sticking with it for now.
In the past I had same experience as you, however this has changed in the past few versions in both browsers. It probably varies from user to user depending on the individual usage.
For me as well. I'm not sure how severe it's for other people, but for me it's quickly climbes to more than 1 GB of my RAM in a couple of pages (probably after I open and close some youtube videos). It could probably be my add-ons, but then it's the browser's responsibility to keep a check on such memory hogging extensions.
I noticed yesterday that my system was sluggish. I went to check on resource usage and Firefox was using 1.5GB. I restarted it and it's currently using 600MB with 14 tabs open (one tab is a one-hour documentary on youtube)
I had a real problem updating from 31 to 32. What usually is done automatically did not work. It kept on asking me if I would like to, and after saying yes it just kept stalling. This was in 2 different workplaces and at home, where I have not had trouble before.
I ended up having to download it from the website, which was not an obvious experience.
Note: Firefox currently uses OpenH264 only for WebRTC and not for the <video> tag, because OpenH264 does not yet support the high profile format frequently used for streaming video. We will reconsider this once support has been added.
YouTube usually already works as long as you don't have the Flash plugin installed (YouTube uses Flash by default for many videos even if you've opted in to the HTML5 beta) since they've transcoded most of the video to WebM.
In any case, the bug to watch for OS X is actually different: https://bugzilla.mozilla.org/show_bug.cgi?id=1062654 That uses Apple's system implementation so it has great performance and it currently appears to be slated for Firefox 35; use the Nightly builds if you want it now and like to live dangerously.
n.b. I don't have the Flash plugin installed – easier than updating it – but if you hit some legacy YouTube / Vimeo embeds you might find these extensions useful for forcing the HTML5 player:
YouTube seems to be defaulting to HTML5 (WebM) video for Firefox Nightly and Aurora browsers, even though I have the Flash plugin installed and enabled.
I'd suspect most places are in the process of switching to use Flash as a fallback now that the native support has shipped for more visitors. Even if you don't care about the format, the improved performance, rendering quality and networking are compelling.
I am currently running Win10 Dev preview full fledged on a daily work machine. Off topic, Win 10 works great except for a few USB bugs not allowing me to format USB drives.
My usage is not as high as im reading. But a lot of my usage comes from Adblock. I have 5 browser windows open, with about 5-10 tabs each, im currently @ 760mb on Win 10.
A nice bug I get is from Firebug. When I am debugging a site, and I try to hover over my Taskbar icons to grab a new window, it flashes for about 2 seconds on whatever im hovering, and I have to try again, the second try usually leaves my taskbar windows open. If I close Firebug, this problem stops.
I also notice when I run flash (I stream mixtapes from datpiff.com), my usage goes sky high. I have been trying some debug options in about:config, and I think I have knocked the usage down by modifying a few lines.
Also another bug I experience on Win10 with Firefox is my top bar will completely disappear, I have to alt+F4 to close out Firefox and re-open. Maybe Firefox 33 will fix some of these issues.
* I managed to fix my top bar issue within minutes of my post. Don't know why, but I decided to add a skin to my Firefox ui - this fixed my issue 100% it seems, I am not getting the error at all anymore
Hmm, after upgrading and restoring the session, all of my Hacker News tabs now show a Secure Connection Failed error: "The OCSP response contains out-of-date information. (Error code: sec_error_ocsp_old_response)"
Do the Firefox releases have anything to do with the Spidermonkey releases? I've been seeing the placeholder page for Spidermonkey 31 for a couple of months now...
Did they fix the exponential usage of RAM for every extra tab yet? Stop saying that not used RAM is wasted RAM. I would like to do things with a browser in the background instead of closing and opening it everytime due to disproportionate RAM usage.
>Did they fix the exponential usage of RAM for every extra tab yet?
>For reference, Chromium doesn't have this issue.
I don't think this problem exists. I have 450 tabs open in Firefox on a 6 y/o computer with 4G of RAM. Last time I tried something like that on Chromium (a long time ago, I admit), blood started leaking from one of the USB ports.
I don't get the appeal of Waterfox. In my experience Intels C++ compiler isn't that good outside of SIMD, with inferior code generation to both GCC and Clang. What compiler are they benchmarking against on their homepage?
I don't either, but I looked at their home page, and am not really inclined to trust performance claims of someone that uses a graph like the one under "General Benchmarks: Higher is Better" which uses a nice smooth curve to demonstrate... nothing, since the different data points are unrelated.
I'm not sure, but I used to run the Nightly build on all of my Windows machines in order to use 64-bit Firefox and anecdotally Waterfox does "feel" quite a bit faster. I definitely notice fewer pauses.
I begin to use Firefox more now than Chrome. Chrome has gotten really slow. like I navigate to a url, it will redirect to about:blank;
watching youtube or soundcloud sends cpu crazy active.
i remember I switched to chrome from firefox 5 years ago because of those reasons. now I find myself using firefox for the same reason, chrome is sluggish. I also don't feel creeped out.
It hasn't done that in years. I have ~20 tabs open and about 500 MB of memory used. For comparison chrome uses the same amount of memory at about 10 tabs open.
Just had to killall firefox. So I beg to differ. They just blame the third party addons. Like ABP, because it's your fault for installing one of the most popular plugins.
Fortunately there's an easy way to get it. Can you visit about:memory when memory usage gets high, click on the "Measure" button and post the results here, or email me, or file a bug at bugzilla.mozilla.org and put "[MemShrink]" in the "whiteboard" field? Thank you.
People complaining about the memory usage all the time seem a bit strange. Just buy a nice machine and help test betas so Google and Mozilla can move faster.
Great... so what long standing piece of UI did they screw around with this time that'll make me want to tear out my hair for a week until I either force myself to get used to it or give in to installing more 3rd party plugin crap to restore the functionality of?
I've seriously come to dread browser updates lately.
They made the location bar a search bar, which is a joyous occasion for me personally. Typing one-word searches in the location bar was actually what made me tear my hair for a week, and I'd find myself coming up with searches that included two words instead of one just to skip the lengthy DNS lookup.
And it is even the #1 browser in places where Chrome can not be used (thanks to US export regulations) and in places where people think about security (Germany).
It doesn't. The point being made was that W3Schools browser usage closely correlates to HN browser usage, which I think isn't accurate. W3Schools isn't that great of a resource, and I presume that the average HN reader's expertise is such that they wouldn't rely on a resource like W3Schools.
Even worse, I've become accustomed specifically to vertical 'tree-style' tabs. I hate that I need them - it makes me less flexible than I would want to be.
The simple fact it is a separate window bothers me. I know you can't change the Chrome UI without using C++ but the Firefox version looks and works much better.
Until Chrome lets people modify the browser UI like Tree Style Tab and other addons do, I won't be interested in switching. It's a good browser for my parents, computer labs, etc. but I could never use it on my workstation.
The other simpler addon is not a separate window, but this one is much better once you get used to it. Worth it as it really takes things to a different level.
BTW you can move the tab outliner itself to a tab and close the window.
If you haven't used it before, and if you're prone to having 10+ tabs open at a time, I highly recommend it. Although I warn you that you may never wish to use Safari or Chrome again...
Chrome used to have a similar feature built-in but they removed it ages ago.
I'm not sure if there are any performance issues since I switched to FF about a year ago when bought new laptop with SSD and 16 gigs of ram it's as fast as Chrome. As for webdev tools, they are not worse, you are just too used to webkit ones. I might even say that FF has better dev tools because you can modify request and re-send it.
I switched because Google is trying to integrate Google too much into Chrome. That's definitely not something I look in a browser since I would like it to be independent and not spy on what I type/do.
Anyway, if anyone who is contributing to FF reading this I just want to thank you for best browser ever.