Firefox 33
mozilla.org
mozilla.org
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.
Every six weeks, as it's been for like three years now...
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?
We have an ongoing project to make Firefox very good, too, but as all big projects, this might take time.
Thank you. The web is full of criticism, so it's nice to get compliments sometimes.
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.
1: http://msujaws.wordpress.com/2014/08/01/faster-and-snappier-...
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.
Now, I'm not agreeing with FF's decision; just pointing out how it is IRL.
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
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.
The whole point of having separate bars is to clearly distinguish use, and to ensure data doesn't leak. This bothers me, too.
Do you mean after you press enter? I can't replicate your finding for words that are simply typed into the location bar.
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'.
Note also that some browsers want to fix http://foo to http://www.foo.com - for Firefox, see [1] and [2]
[1] about:config?filter=browser.fixup
[2] http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entr...
Open up: about:config?filter=keyword.enabled
Set it to false.
Now things like "bjafbsaofbdnaspolnas" will just end up at "http://www.bjafbsaofbdnaspolnas.com/".
forgot to do that for a search this morning and found this has been fixed!
https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
One of the things I really hate in web development is tracking down who is messing up the events.
http://flailingmonkey.com/view-jquery-and-jquery-live-events...
https://hacks.mozilla.org/2014/09/webide-storage-inspector-j...
(It'll be in Firefox Beta later this week, too.)
Because date is one of the valid types for HTML5 inputs.
Thank you for pointing that out.
Desktop Safari and desktop Firefox do not.
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.
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.
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.
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.
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.
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.
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.
P.S.: While terrible JS widgets to exist, there has been a huge movement to make them accessible. For example see http://dojotoolkit.org/reference-guide/1.10/dijit/a11y/state.... Also, what do you think the native chrome widget is built with, C++?
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.
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.
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.
You recommend using a JS-based datepicker, what would the difference be?
This would be faster and easier since you don't have to keep the JS-based one up to date.
Their existence is why this is such a popular browser feature request:
http://msdn.microsoft.com/en-us/library/system.windows.contr...
https://developer.apple.com/library/mac/documentation/Cocoa/...
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.
it's already been disclosed that NSA uses Google PREF cookies to track users: http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10...
hence my other dispirited comment about the cookie UI... edit: reworded/clarified
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).
UPDATE: It looks like http://bugzil.la/1026538 is why the cookie keeps reappearing.
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:
https://support.mozilla.org/en-US/kb/how-does-phishing-and-m...
Oh, and Google should _really_ provide their Safebrowsing API without a cookie, too. Youtube-nocookie.com works fine too....
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.
Which brings me to another point: cross browser testing is important.
But we're working on improving that, too :)
(yeah, Firefox dev here)
(then hiding user lock-in as innovative, minimal UI)
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.
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.
e10s should make Firefox competitive. And its still quite a while before it lands.
i dont think chrome having faster js back in the days did change much user-wise. gmail was as fast in firefox as it was in chrome... ;)
- Builtin support for Keychain (without relying on an extension).
- swipe-animation when going forward/backwards in history.
- "over-scroll" (you know, when you can sort sort scroll past the top and bottom of the page).
I know it sounds a bit vain, but I simply can't make a switch unless the look and feel is native to OS X.
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.
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.
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.
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.
[0] https://blog.mozilla.org/nnethercote/
[1] https://blog.mozilla.org/nnethercote/category/memshrink/
http://www.reddit.com/r/programming/comments/25j41u/adblock_...
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)
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.
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.
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.
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.).
It was implemented by the wonderful Jan de Mooij who just last week landed another nice JS memory improvement that should be released in Firefox 35: https://bugzilla.mozilla.org/show_bug.cgi?id=1073700#c7
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.
half-screen, non-rounded thumbnails? That new UI makes me sad...
Firefox guys in this thread, how do we get the old sizes back? 9 thumbnails > 6.
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.
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".
http://venturebeat.com/2013/04/15/mozilla-ceo-we-refuse-to-b...
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.
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.
1: 30min in @ https://air.mozilla.org/product-design-at-mozilla/
> 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.
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.
Even ignoring the point someone raised of increasing the workload of already strained resources.
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.
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?
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.
When you use a browser on the web, you are literally voting for who gets the most control of those discussions.
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.
"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:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=92192...
http://www.osnews.com/story/24954/US_Patent_Expiration_for_M...
http://scratchpad.wikia.com/wiki/MPEG_patent_lists#MPEG-1_Au...
Most of the remaining patents expire in 2015. There are a few for 2017, but they're for features nobody really needs in a computer decoder.
https://wiki.mozilla.org/Platform/GFX/OffMainThreadCompositi...
(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)
There was a bug (https://code.google.com/p/chromium/issues/detail?id=409126), but it seems to be fixed. However last comment there hints on another related bug: https://code.google.com/p/chromium/issues/detail?id=407889
Maybe you have bookmarks with foreign characters on bookmark bar too?
Chrome is losing focus on what was making it great : ultralight and fast.
I'd ditch Chrome if Firefox had full html5 video support on OS X.
Nicholas's last memshrink posts were this summer, after the FF32 release...
> 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.
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.
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.
I ended up having to download it from the website, which was not an obvious experience.
Yay, another decade before we get YouTube on OS X
Settings show it only supports up to level "31" whatever that is.
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.
https://github.com/hfiguiere/no-flash https://addons.mozilla.org/en-US/firefox/addon/youtube-all-h...
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.
was hoping for native h264 to be working by now but apparently not
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/34.0...
For reference, Chromium doesn't have this issue.
>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.
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.
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.
Does this remove the horrible Australis UI?
I love the Australis UI, did they make it stay?
Don't most of HN users just use the Nightly's or the Canary build for Chrome?
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.
I've seriously come to dread browser updates lately.
Break Down is
Chrome 59.6%
FireFox 24.0%
Internet Explorer 9.9%
Safari 3.6%
Opera 1.6%
https://chrome.google.com/webstore/detail/tabs-outliner/eggk...
There's an add-on for simple vertical tabs, but I think this is even better.
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.
Source, Chrome, Internet Explorer, Firefox, Safari, Opera, Other
StatCounter 48.7% 23.0% 19.6% 4.9% 1.4% 2.3%
W3Counter 38.0% 19.0% 16.8% 16.0% 3.2% 6.0%
Wikimedia 45.9% 11.7% 16.9% 7.1% 1.6% 16.8%
NetApplications 19.3% 58.3% 15.5% 5.2% 1.0% 0.4%
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
.
Line charts over time of W3Counter data (although I am not sure if this excludes mobile or not): http://www.w3counter.com/trends