Mozilla is currently, building and releasing XULRunner simultaneously with Firefox releases. Releases can be found here.
XULRunner releases for 1.9.0, 1.9.1 and 1.9.2 branches (matching Firefox 3.0, 3.5 and 3.6 respectively) are available. The question now becomes “How long does Mozilla keep releasing older branches of XULRunner?” We’d like to re-purpose some of the resources used to build older branches.
Therefore, we intend to stop posting XULRunner builds and releases from the 1.9.0.x branch soon. This would only affect Mozilla building and releasing XULRunner 1.9.0.x. The source code to XULRunner 1.9.0.x would remain available and developers could always build and release their own XULRunner packages from the source code.
Security updates and fixes may still happen on the 1.9.0 branch. If you depend on the 1.9.0 branch and want to get these fixes into your project, you’ll need to build XULRunner yourself.
Mozilla will continue to build and release XULRunner from the 1.9.1 and 1.9.2 branches.
Please feel free to provide feedback on the pros and cons. We’d be interested in knowing how this action affects users of prebuilt XULRunner releases. Follow up on the newsgroup posting.
Apple introduced the viewport meta tag in mobile Safari to help web developers improve the presentation of there web pages on the iPhone. We added support for the viewport tag in mobile Firefox for the same reasons.
The viewport tag allows web developers to set the width, height and scale of the browser area used to display web content. However, some websites are not doing a good job configuring the viewport tag and it affects the presentation in Firefox.
When setting the width or height, developers can use a fixed number of pixels or use the constants: device-width and device-height. The iPhone is 320px wide in portrait and 480px wide in landscape. Other devices have different screen sizes. It seems the “width=320” is a popular fallback though. See how Facebook and DeviantART display in Firefox on the N900 (480px in portrait and 800px in landscape):
Don’t get me wrong. I like “touch-friendly” web pages on my mobile device. However, the iPhone is not the only mobile device out there. If a web developer has gone through the effort to make a “touch-friendly” web page, please configure your viewport to work in other devices. It’s easy!
Prism’s long march to final release got a little closer recently with the release of Prism 1.0 Beta 3 (Linux too). Prism is now using the same Gecko 1.9.2 as used in the newest Firefox 3.6 release. A big thanks to Matt Gertner for keeping Prism development moving along. Firefox for Mobile has been keeping me very busy.
I noticed some other people are eager for a Prism release too: Webmonkey, Business2.0, Reddit
There has been a lot of discussion about the future of the Mozilla add-on infrastructure. I think it’s clear now that Mozilla is not removing the classic add-on mechanism. In fact, Fabrice Desré found a nice bit of news on an upcoming feature (via comments on Atul’s post):
Fabrice: Does the fact that jetpacks are now XPIs mean that the “no restart after install” feature will be implemented for traditionnal add-ons ?
Atul: That’s correct! We don’t have a bug filed for it yet, still need to do that, but the idea is that if an extension includes certain metadata in its install.rdf that essentially tells Firefox “look, I know how to unload all my resources reliably”, then Firefox will trust it and call a certain function whenever the extension needs to unload itself.
Mossop: I’ll just elaborate a little. Plans are naturally in flux right now but the idea is to allow XPI packages to install without restarts if they wish, however there will be constraints. They will be responsible for doing everything themselves, which means (at least in my head right now) we won’t automatically load chrome or components from these extensions. Instead we will just do startup and shutdown calls into the extension and allow it to register/unregister what it needs by itself. This means that just marking an existing extension to work without restarts wouldn’t get you anywhere, you still need to do the extra work to handle the startup/shutdown parts.
This is great news for add-on developers! I’m sure MDC will have some code snippets for dynamically loading chrome overlays and components to make it easy to support no-restart add-ons.