https://blog.mozilla.org/addons/2009/06/10/introducing-add-on-collections/

https://addons.mozilla.org/en-US/firefox/collections/

about:memory says it's 80% "heap-unclassified"

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.

Please read https://developer.mozilla.org/en/Zombie_compartments and file a bug https://bugzilla.mozilla.org/enter_bug.cgi if you cc :kbrosnan I will do my best to forward it to the correct people.

https://support.mozilla.org/en-US/kb/how-firefox-android-use-permissions-it-requests not sure if the most recent changes made to it for the Beta are live.

For phone users there is a completely rewritten Java based UI. This results in a much faster startup time and we have Flash support. Two of the largest complaints in the market feedback.

No it does not. Addons need to be re-written for mobile. Jetpack/Addon SDK make this process simpler but it still takes some work.

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?

Mobile is the first place where it is trivial to implement due to hardware decoders. Desktop still has the decision to either pay MPEGLA for a license and ship something like libx624 on all platforms or decode using the system installed codecs when present.

Google already has a h.264 license due to YouTube. Apple probably does not pay anything as they control several key patents involved in decoding h.264. Even if they do pay they would get a royalty distribution from MPGLA for their patents that are in the pool.

There is a big difference when you build a browser around a phone and building a browser from the ground up on a diverse set of phones. Our early work on boot2gecko is showing a large difference between running Linux with a Dalvik vm and then a browser with a JS vm and just running Linux with a browser and a JS vm. That being said we are in the middle of a major rewrite of Firefox mobile with a Java front end. See my reply to the grandparent of this thread for details.

We are working on a Java front end for Firefox mobile. Performance on devices that were marginal at running XUL Firefox mobile is much improved. There were a couple design decisions that made Firefox mobile slow to startup. First it was a testbed for Firefox multiprocess work. Secondly shipping as a full NDK app as complex as Firefox could not compete with Java app startup time due to library unpacking. This was exacerbated on phones that had a poor filesystem such as the Galaxy S.

If you want to give the Java native version a try it can be downloaded from http://nightly.mozilla.org/ It will require you to enable installing of non-market apps on your phone.

Device APIs are a key part of the B2G effort. Mozilla is making those APIs and getting them standardized.

This is working fairly well on Nightly and Aurora. On Beta (11) soon.

Adding Flash to Firefox was a considerable amount of work. Adobe and Google rather drastically re-wrote NPAPI. The only documentation on how Flash worked on Android is the Android source. This work represents several hundred person hours to get it working.

TBH Flash support is in the current release version has a pref for flash on 2.2 and 2.3 but the experience is rather poor, hence it being disabled with no UI to enable it. about:config change plugin.disable to false. Judge Flash progress against the Nighty or Aurora builds. The Beta 10 or release 10 builds are not representative of the Flash experience for 11+.

Debian tends to have large and historical patches that make large upstream patckages fit the Debain way. For example I'm takling about packages such as OOo/LibreOffice, Apache httpd, Mozilla Firefox, etc. Arch goes in the other direction, make as few changes to the upstream package as possible.

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.