Mozilla
2011
The new native Android UI version of Firefox does not ship with a dedicated Error Console. Instead, all console messages are redirected to the Android system log - also known as logcat. If you have the Android SDK installed, you already have a way to view the logcat:
Firefox for Android, both the XUL and Native versions, currently requires an ARMv7 CPU. We are looking into adding support for ARMv6, but the ARMv7 limitation had one painful drawback: We could not run Firefox on the Android emulator since it only supported ARMv6.
We have been talking a lot recently about the new native UI version of Firefox for Android. Built using native Android UI widgets, packed with major speed improvements and large memory reductions. We have not been working on the project very long, but we have been making solid progress. We decided it’s time to move the native builds into our nightly delivery channel.
One of the first things I yelled about when we were debating switching to a native Android UI for Firefox was add-on support. Using a XUL-based UI meant add-ons were free. The Mozilla platform has support for add-ons baked right in. Moving to a native UI would surely kill our ability to support add-ons, right? Wrong!
You have probably seen some announcements and read some blog posts about Mozilla’s recent change in direction for Firefox Mobile on Android. We have decided to drop the XUL-based UI and re-build the application using native Android widgets. Here’s some of the rationale, from Johnathan’s newsgroup post:
Firefox Mobile recently hooked up the same performance data telemetry system used by desktop Firefox. If you use the Nightly version of Firefox Mobile, you can start sending anonymous performance data back to Mozilla. We will use this data to improve future versions of Firefox Mobile.
Lots of discussion going on recently about the affect of 6 week development cycles on binary XPCOM components in add-ons. I don’t want to re-hash those discussions, but Daniel Glazman brought up an interesting point in a comment on Wladimir’s post. Wladimir was suggesting binary component developers start moving to js-ctypes. Daniel pointed out that there are two classes of binary XPCOM components: