Mozilla, Google, and Facebook all offer bounties to researchers outside the US.
* Mozilla has awarded bounties to researchers in several European countries.
* Google says: “We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists.”
* Facebook says: “You must... Reside in a country not under any current U.S. Sanctions (e.g., North Korea, Libya, Cuba, etc.)”
Your database sizes aren't much different from mine. My places.sqlite is 73.4MB my urlclassifier3.sqlite (in ~/Library/Caches/Firefox/) is 42MB.
Firefox stores a lot of history information, including individual visits, in order to provide good predictions when typing into the address bar. I'm not sure which heuristics it uses to expire old history, or even whether it's primarily based on database size or age.
We could probably stop storing individual visit information if we fixed bug 704025. But I'm guessing that wouldn't shrink the database much, because dates are tiny compared to URLs and titles.
What exactly do Mozilla do with 100 million dollars of tax-free revenue?
The first thing we do with it is to pay taxes. It was not trivial for us to figure out how to do that.
Are they building a war chest?
You can get a sense of how much we're saving by reading financial reports from previous years. To some extent, we're saving not because we want to save, but because we can only hire people so fast while maintaining quality and culture.
That'd be 500 full time employees at 100k per year with 50 million left over in case of emergencies.
500 full time Mozilla employees and contractors isn't far off.
I've heard a rule of thumb that once you throw in benefits, offices, and travel, the cost of employing someone is about twice their salary. I don't know whether that holds for Mozilla, which has generous employee benefits but many remote employees.
every single time, Firebug and Greasemonkey stop working.
If you use a beta version of Firefox and want to use Firebug, the Firebug developers say you should use the beta version of Firebug. It would be nice if Firefox Beta automatically went out and fetched the beta version of Firebug instead of just saying the version you have is incompatible.
Greasemonkey is often more compatible than its authors let on. I'm using it with Firefox 8 Nightly and it's working fine, despite being marked as only compatible with Firefox 5. I bet it would work in your Firefox 6 Beta just fine.
There's also a competitor to Greasemonkey called Scriptish that is marked as compatible with Firefox 6 beta. I've heard good things about it but haven't tried switching yet.
track add-ons better and not refuse to load them just because they haven't yet been certified to work
That's the plan!
AMO-hosted extensions that use APIs that haven't changed are automatically assumed to work. So are extensions developed using the new SDK.
To do it safely for other extensions, we'll need to gather data from beta users (like you -- thanks!) to find out whether the extension still does its job, whether it causes crashes (crash-stats correlations), and whether it causes other widespread problems (telemetry correlations).
Future beta versions of Firefox will probably ask you whether you also want to beta-test extensions that might not be compatible. For now you have to set a hidden pref to do that.
I'm pretty sure "__misaligned_access" in that stack trace is a red herring. Notice the large offsets and multiple frames blamed on the "same function". It's probably a section of ntoskrnl for which you don't have full symbols.
In theory you can get a decent stack trace (or even stack traces for all threads) by following the instructions on How to get a stacktrace with WinDbg. In theory. I tried once and got about as far as you did.
Does that mean the goal of Rust is to become part of Firefox at some point?
Yes, the hope is that parts of Firefox will begin to be written in Rust. I heard a rumor that we might replace our HTML parser first. (Our current HTML parser has one of the weirdest build requirements; it's written in a custom subset of Java that can be source-translated into C++.)
I had always wondered why Mozilla would suddenly become interested in writing a new programming language out of the blue
As opposed to digging deeper and deeper into our unhappy dialect of C++?;)
Didn't seem like the sort of organization with so much excess resources to throw around that it would be useful to start spinning up such a thing
We're doing pretty okay on money for now:) Putting together a language research team doesn't compete directly with much of the other stuff we're doing, except maybe JS engine work. It's a long shot, but if it works succeeds, it will be worthwhile many times over.
instead of, say, buying more build slaves
IIRC, we were limited there by datacenter power or space. We recently got space in a data center in Phoenix, which should help a lot.
We were also limited there by trying to use the same hardware to test Firefox's performance on all desktop operating systems, which meant using a specific version of the Mac Mini for everything. And using the same hardware for both performance testing and unit testing. We're going to change that.
We're doing as much as we can to reduce those problems while Firefox is still single-process. For example, we recently started throttling timers in background tabs and added a sane web animation API. More and more internal APIs are asynchronous or interruptible. We've also reduced memory use quite a bit with Firefox 7; I think we use significantly less memory than Chrome in common cases now.
At the same time, we're also working on process separation. It looks like it will be ready to play with, perhaps even an option, in a few months. I don't think we'll enable it by default until we're comfortable with the tradeoff between memory use and responsiveness/stability.
And we're also working on a new programming language that could make it safe and sane to use "tasks" (likely mapping to threads) rather than processes, so we don't have to deal with that unhappy tradeoff:)
I'm curious about the change to rendering. It seems to me they're saying, "these OS layout engines (Quartz et al) are too slow - we'll just route around them".
Precisely the opposite. It's our previous abstraction layer that's too slow, and we're replacing it with a thinner one, starting with the easier things like Canvas. See Introducing the Azure project and Azure vs Cairo.
Actually, what I want from the Mozilla devs at the moment is not new features, but a solution to Firefox's memory problems.
Then you'll be happy to know that the "latest and greatest" includes some pretty big memory improvements. Do a find-in-page on The Burning Edge for "memory" or read Nick Nethercote's blog.
It seems that it's easier to motivate Mozilla developers to work on memory issues when the fixes will reach users in months rather than years.
I'm using Nightly (7) and I'm having trouble getting Firefox to use more than 400MB (explicit) even after a day of heavy use, with Gmail and Reader and Twitter as app tabs. You should try it out and report any bugs you encounter. Yes, we finally have tools that allow users like you to report useful memory leak bugs.
Slashdot Mirror
A heap-unclassified that high usually indicates a leak (and in particular, a leak that does not involve ghost windows).
Can you hop into #memshrink on irc.mozilla.org? I bet we can help you track it down further.
Mozilla, Google, and Facebook all offer bounties to researchers outside the US.
* Mozilla has awarded bounties to researchers in several European countries.
* Google says: “We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists.”
* Facebook says: “You must... Reside in a country not under any current U.S. Sanctions (e.g., North Korea, Libya, Cuba, etc.)”
Which bounty programs are restricted to the US?
Device APIs are a key part of the B2G effort. Mozilla is making those APIs and getting them standardized.
Your database sizes aren't much different from mine. My places.sqlite is 73.4MB my urlclassifier3.sqlite (in ~/Library/Caches/Firefox/) is 42MB.
Firefox stores a lot of history information, including individual visits, in order to provide good predictions when typing into the address bar. I'm not sure which heuristics it uses to expire old history, or even whether it's primarily based on database size or age.
We could probably stop storing individual visit information if we fixed bug 704025. But I'm guessing that wouldn't shrink the database much, because dates are tiny compared to URLs and titles.
Which files in your profile folder are the largest?
I was making a general point, not especially directed at you.
Sorry your experience with Firefox has worse than the norm, though.
Firefox 10 or 11 will assume add-ons are compatible by default, which is more or less what you're asking for :)
There will be a few exceptions, such as add-ons with binary components and add-ons that are known to not work.
Conversely, a bug manifesting in your instance of a program is not the same as the program being a bug-ridden piece of crap written by insane monkeys.
My first bug report was bug 27610, so we probably overlapped.
Yes, mpt was very much around. I learned a lot from reading mpt's comments in Bugzilla. It's too bad he didn't get along with everyone.
FTFY.
(If you're running an email app, a feed aggregation app, and a social network app in your browser, then your browser is going to use some memory.)
I triaged bugs back in 2000, too. What was your username or email address in Bugzilla? :)
Nowadays my focuses are security and finding bugs.
In 2009 I wrote about how to make triage more efficient and more effective. (Tyler linked to my post). And I actually triaged a subset of bugs that way when I was tasked with bringing down the number of crash bug reports.
The first thing we do with it is to pay taxes. It was not trivial for us to figure out how to do that.
You can get a sense of how much we're saving by reading financial reports from previous years. To some extent, we're saving not because we want to save, but because we can only hire people so fast while maintaining quality and culture.
500 full time Mozilla employees and contractors isn't far off.
I've heard a rule of thumb that once you throw in benefits, offices, and travel, the cost of employing someone is about twice their salary. I don't know whether that holds for Mozilla, which has generous employee benefits but many remote employees.
If you use a beta version of Firefox and want to use Firebug, the Firebug developers say you should use the beta version of Firebug. It would be nice if Firefox Beta automatically went out and fetched the beta version of Firebug instead of just saying the version you have is incompatible.
Greasemonkey is often more compatible than its authors let on. I'm using it with Firefox 8 Nightly and it's working fine, despite being marked as only compatible with Firefox 5. I bet it would work in your Firefox 6 Beta just fine.
There's also a competitor to Greasemonkey called Scriptish that is marked as compatible with Firefox 6 beta. I've heard good things about it but haven't tried switching yet.
That's the plan!
AMO-hosted extensions that use APIs that haven't changed are automatically assumed to work. So are extensions developed using the new SDK.
To do it safely for other extensions, we'll need to gather data from beta users (like you -- thanks!) to find out whether the extension still does its job, whether it causes crashes (crash-stats correlations), and whether it causes other widespread problems (telemetry correlations).
Future beta versions of Firefox will probably ask you whether you also want to beta-test extensions that might not be compatible. For now you have to set a hidden pref to do that.
I'm pretty sure "__misaligned_access" in that stack trace is a red herring. Notice the large offsets and multiple frames blamed on the "same function". It's probably a section of ntoskrnl for which you don't have full symbols.
In theory you can get a decent stack trace (or even stack traces for all threads) by following the instructions on How to get a stacktrace with WinDbg. In theory. I tried once and got about as far as you did.
Yes, the hope is that parts of Firefox will begin to be written in Rust. I heard a rumor that we might replace our HTML parser first. (Our current HTML parser has one of the weirdest build requirements; it's written in a custom subset of Java that can be source-translated into C++.)
As opposed to digging deeper and deeper into our unhappy dialect of C++? ;)
We're doing pretty okay on money for now :) Putting together a language research team doesn't compete directly with much of the other stuff we're doing, except maybe JS engine work. It's a long shot, but if it works succeeds, it will be worthwhile many times over.
IIRC, we were limited there by datacenter power or space. We recently got space in a data center in Phoenix, which should help a lot.
We were also limited there by trying to use the same hardware to test Firefox's performance on all desktop operating systems, which meant using a specific version of the Mac Mini for everything. And using the same hardware for both performance testing and unit testing. We're going to change that.
We're doing as much as we can to reduce those problems while Firefox is still single-process. For example, we recently started throttling timers in background tabs and added a sane web animation API. More and more internal APIs are asynchronous or interruptible. We've also reduced memory use quite a bit with Firefox 7; I think we use significantly less memory than Chrome in common cases now.
At the same time, we're also working on process separation. It looks like it will be ready to play with, perhaps even an option, in a few months. I don't think we'll enable it by default until we're comfortable with the tradeoff between memory use and responsiveness/stability.
And we're also working on a new programming language that could make it safe and sane to use "tasks" (likely mapping to threads) rather than processes, so we don't have to deal with that unhappy tradeoff :)
Precisely the opposite. It's our previous abstraction layer that's too slow, and we're replacing it with a thinner one, starting with the easier things like Canvas. See Introducing the Azure project and Azure vs Cairo.
Does that still happen? I thought we fixed that a while ago, and made it show an error message instead of popping up the profile manager.
Then you'll be happy to know that the "latest and greatest" includes some pretty big memory improvements. Do a find-in-page on The Burning Edge for "memory" or read Nick Nethercote's blog.
It seems that it's easier to motivate Mozilla developers to work on memory issues when the fixes will reach users in months rather than years.
I'm using Nightly (7) and I'm having trouble getting Firefox to use more than 400MB (explicit) even after a day of heavy use, with Gmail and Reader and Twitter as app tabs. You should try it out and report any bugs you encounter. Yes, we finally have tools that allow users like you to report useful memory leak bugs.
Or maybe it's a security hole in your extension that it prevents you from keeping Firefox up to date.
Good luck getting people to contribute to and use your "old and insecure" fork of Firefox.
How would that help? Opera doesn't provide security updates for old versions either.
fwiw, DreamHost says Ryan Cleary was behind DDoS attacks on DreamHost.
I'd be more worried about the senator who doesn't look at free porn on his home computer.
Where do you see Mozilla "jumping up and down shouting the version number"? The main mozilla.com page barely mentions it.