Recent blog entries for mbrubeck

Better automated detection of Firefox performance regressions

Last spring I spent some of my spare time improving the automated script that detects regressions in Talos and other Firefox performance data. I’m finally writing up some of that work in case it’s useful or interesting to anyone else.

Talos is a system for running performance benchmarks; we use it to run a suite of benchmarks every time a change is pushed to the Firefox source repository. The Talos test harness reports these results to the graph server which stores them and can plot the recorded data to show how it changes over time.

Like most performance measurements, Talos benchmarks can be noisy. We need to use statistics to separate signal from noise. To determine whether a change to the source code caused a change in the benchmark results, an automated script takes multiple datapoints from before and after each push. It computes the average and standard deviation of the “before” datapoints and the “after” datapoints, and uses a Student’s t-test to estimate the likelihood that the datasets are significantly different. If the t-test exceeds a certain threshold, the script sends email to the author(s) of the responsible patches and to the dev-tree-management mailing list.

By nature, these statistical estimates can never be 100% certain. However, we need to make sure that they are correct as often as possible. False negatives mean that real regressions go undetected. But false positives will generate extra work, and may cause developers to ignore future regression alerts. I started inspecting graph server data and regression alerts by hand, recording and investigating any false negatives or false positives I found, and filed bugs to fix the causes of those errors.

Some of these were straightforward implementation bugs, like one where an infinite t-test score (near certain likelihood of regression) was treated as a zero score (no regression at all). Others involved tuning the number of datapoints and the threshold for sending alerts.

Some fixes required more involved changes to the analysis. For example, if one code change actually caused a regression, the pushes right before or after that change will also appear somewhat likely to be responsible for the regression (because they will also have large differences in average score between their “before” and “after” windows). If multiple pushes in a row had t-test scores over the threshold, the script used to send an alert for the first of those pushes, even if it was not the most likely culprit. Now the script blames the push with the highest t-test score, which is almost always the guilty party. This change had the biggest impact in reducing incorrect regression alerts.

After those changes, there was still one common cause of false alarms that I found. The regression analyzer compares the 12 datapoints before each push to the 12 datapoints after it. But these 12-point moving averages could change suddenly not just at the point where a regression happened, but also at an unrelated point that happens to be 12 pushes earlier or later. This caused spooky action at a distance where a regression in one push would cause a false alarm in a completely different push. To fix this, we now compute weighted averages with “triangular” weighting functions that give more weight to the point being analyzed, and fall off gradually with increasing distance from that point. This smooths out changes at the opposite ends of the moving windows.

There are still occasional errors in regression detection, but as far as I can tell most of them are caused by genuinely misleading random noise or bimodal data. If you see any problems with regression emails, please file a bug (and CC :mbrubeck) and we’ll take a look at it.

Syndicated 2013-11-10 19:53:00 from Matt Brubeck

A good time to try Firefox for Metro

“Firefox for Metro” is our project to build a new Firefox user interface designed for touch-screen devices running Windows 8. (“Metro” was Microsoft’s code name for the new, touch-friendly user interface mode in Windows 8.) I’m part of the small team working on this project.

For the past year we’ve been fairly quiet, partly because the browser has been under heavy construction and not really suitable for regular use. It started as a fork of the old Fennec (mobile Firefox) UI, plus a new port of Gecko’s widget layer to Microsoft’s WinRT API. We spent part of that time ripping out and rebuilding old Fennec features to make them work on Windows 8, and finding and fixing bugs in the new widget code. More recently we’ve been focused on reworking the touch input layer. With a ton of help from the graphics team, we replaced Fennec’s old multi-process JavaScript touch support with a new off-main-thread compositing backend for the Windows Direct3D API, and added WinRT support to the async pan/zoom module that implements touch scrolling and zooming on Firefox OS.

All this work is still underway, but in the past week we finally reached a tipping point where I’m able to use Firefox for Metro for most of my everyday browsing. There are still bugs, and we are still actively working on performance and completing the UI work, but I’m now finding very few cases where I need to switch to another browser because of a problem with Firefox for Metro. If you are using Window 8 (especially on a touch-screen PC) and are the type of brave person who uses Firefox nightly builds, this would be a great time to try Metro-style Firefox and let us know what you think!

Looking to the future, here are some of our remaining development priorities for the first release of Firefox for Metro:

  • Improve the installation and first-run experience, to help users figure out how to use the new UI and switch between “Metro” and desktop modes. (Our UX designer has user testing planned to help identify issues here and throughout the product.)

  • Fix any performance and rendering issues with scrolling and zooming, and add support for double-tap to zoom in on a specific page element.

  • Make the Metro and desktop interfaces share a profile, so they can seamlessly use the same bookmarks and other data without connecting to a Firefox Sync account.

And here are some things that I hope we can spend more time on once that work has shipped:

  • Improve the experience on pages with plugins, which currently require the user to switch to the desktop Firefox interface (bug 936907).

  • Implement a “Reader Mode,” like Firefox for Android. (A pair of students have started working on this project, and their work should also be useful for adding Reader Mode to Firefox for desktop.)

  • Add more features, and more ways to customize and tweak the Metro UI.

If you want to contribute to any of this work, please check out our developer documentation and come chat with us in #windev on irc.mozilla.org or on our project mailing list!

Syndicated 2013-11-10 17:20:00 from Matt Brubeck

Congratulating the IE10 team

Back when Firefox 2 was released (six years ago this week!), the Internet Explorer team started a friendly tradition of sending Mozilla a cake as congratulations. This continued for Firefox 3 and Firefox 4. After Firefox switched from major releases once or twice a year to incremental updates every six weeks, they sent us cupcakes for the next few updates instead. :)

Since IE10 for Windows 8 is shipping today, I thought it would be fun to revive the tradition by delivering a cake to congratulate the IE team. Here’s the cake right after I picked it up from Baked Custom Cakes, with the Firefox logo in painted fondant:

Fellow Mozilla developer Eitan Isaacson drove with my wife Sarah and me to Microsoft Building 50 in Redmond, where program manager Jacob Rossi helped us deliver the cake to a group of IE team members:

The IE team posted their thanks through their official Twitter account. (As you can see from their picture, the bottom border of the cake got sligthly restyled in transit, but it still looks quite edible.) Less than 30 minutes later, Microsoftie Michael Bolan tweeted that cake was already gone. (I hear that the sugary Firefox logo was also eaten shortly afterward.)

So congratulations to the Internet Explorer team on your latest release, and we hope you enjoyed the cake!

Syndicated 2012-10-26 21:38:00 from Matt Brubeck

Metro Firefox without Windows 8

A few weeks ago I started working on the Firefox “Metro UI” project, for Windows 8’s Metro (or Modern) touch-screen environment. While we’re still working on getting our first preview builds ready for Windows 8 users to try out, you can already check out the current source code from the elm branch and build it yourself if you want to get involved and help us fix some bugs.

What you might not know is that you can run “Metro” Firefox even if you don’t have Windows 8. It’s been possible for a while to build and run on older versions of Windows using the -metrodesktop flag. Today I landed a patch to make this work on other platforms too. To build the latest elm source code on Linux or Mac OS X, follow these instructions:

  1. Clone the elm repo: hg clone http://hg.mozilla.org/projects/elm/
    (If you have already cloned mozilla-central or some other repo that shares with it, there’s a faster way to do this.)

  2. Create a .mozconfig file with ac_add_options --enable-metro

  3. Build Firefox as you normally would.

  4. From your objdir, run dist/bin/firefox -metrodesktop (Linux)
    or dist/Nightly.app/Contents/MacOS/firefox -metrodesktop (Mac)

  5. You can visit about:config and enable metro.debug.treatmouseastouch (then restart the browser) to simulate touch interaction with the mouse. Right-click to simulate the Windows 8 edge-swipe gesture, which displays the toolbars.

This is still experimental and mostly untested. Elm might accidentally break on non-Windows platforms from time to time (because of course we are doing all our main development and testing on Windows). While it’s not a perfect replacement for running in the real Windows 8 environment, I hope this is a useful option for adventurous Firefox contributors who want to experiment with the Metro code but don’t have convenient access to Windows 8.

Syndicated 2012-09-20 00:42:00 from Matt Brubeck

Mobile web developers: Your users hate it when you do this

Mobile Firefox beta releases include a “Feedback” add-on (like the one in Firefox 4 beta for desktop), which lets users tell us what they think about the new browser. Based on a sample of feedback from mobile beta testers, the most common complaints are about:

  1. Speed
  2. Fitting text to the screen when zoomed in
  3. Mobile vs. desktop versions of web sites

The first two are straightforward, though not necessarily easy. We’re always working on performance, and we have experimental text reflow code (currently available in the Easy Reading add-on). But the last item is more complicated…

Browser detection pitfalls

Web sites can read the User-Agent header sent by your browser to see what browser and OS you are using. Some sites use that information to decide whether to send a “full” version of a web page, or a version formatted for mobile devices.

This can go wrong in several ways. If your browser or device is new, or wasn’t tested when a site was developed, that site has no way of knowing whether it is “mobile.” Users may also change their User-Agent to work around content restrictions or access different media formats. And some sites make incorrect assumptions, like that all browsers with “Android” in their User-Agent string are based on WebKit.

Even when the browser is known, readers and publishers might not agree about whether the mobile or desktop version is better. Based on our feedback, some users want to switch from full sites to mobile sites while others want just the opposite. And some devices, like large touch-screen tablets, combine aspects of handheld and desktop computers.

Solutions

Looking through these complaints, many people are under the mistaken impression that the browser, rather than the web site, decides whether to display mobile-formatted pages. Even the New York Times' David Pogue gets this wrong in his Galaxy Tab review:

When you visit sites like nytimes.com, CNBC.com and Amazon.com, the Galaxy’s browser shows the stripped-down, mobile versions of those sites. According to Samsung, there’s no way to turn that feature off and no way to visit the full-size sites. You can delete the little “m.” in the Web address until you’re blue in the browser, but the Galaxy always puts it right back.

Web developers: your readers are begging us to display your content in their preferred format. We want to help them, but we can’t do it alone.

(I wrote an add-on called Phony that lets mobile Firefox impersonate the User-Agent strings of other browsers. While this improves the experience on some sites, it breaks it on others. Masquerading as another browser can lead sites to serve non-standard markup that do not work in Firefox.)

Because browser detection is never perfect, web sites should let readers choose between mobile and full content. They can try to guess the right version by default, but please let users opt in or out.

Best practices for web developers

Here are some first steps typical mobile web sites can take to make their readers happier:

  • When possible, serve the same content to all browsers. You can use stylesheets and scripts to customize your layout for different display sizes, as in this beautiful site by Jon Hicks.

  • There are valid reasons to use User-Agent sniffing. But if you must use it, test in as many browsers and devices as possible and learn the correct way to detect various browsers. For example, you can detect Gecko-based browsers by looking for Gecko and rv:, and you can detect mobile Firefox by looking for Fennec/.

  • If a “mobile” user requests a page that isn’t available on your mobile site, serve the full version to them anyway, rather than redirecting them to an unrelated mobile landing page.

  • Let users switch from your mobile site to your full site and back. You may remember users' previous choices for convenience, but let them change their minds again.

Further reading

For much more comprehensive development advice, see Yiibu’s thoughtful and practical approach to building sites that work across many different browsers and mobile devices.

Coming from a different perspective, Andrea Trasatti (developer of the device-detection library WURFL) talks about problems in mobile User-Agent strings and how they could be more useful for device detection.

Syndicated 2010-11-19 15:15:00 from Matt Brubeck

What's different about Firefox for Android

I've been working for the last six months on Firefox for Android (also known as "Fennec"). Here are some thoughts about the challenges in building a mobile browser, and the particular choices we've made.

Along the way, I'll try to answer some frequently-asked questions, like "Why is Firefox so huge on Android?" and "Why should I care?"

Why

People often ask us why Android needs another web browser. These are a few things Firefox does that other Android browsers don't:

  • Syncs bookmarks, tabs, history, passwords, and form data to and from your phone. Firefox Sync and the Firefox Awesomebar help you enter URLs and passwords with less typing, and move seamlessly between your desktop and your mobile phone.

  • Allows extensions to customize every part of the user interface. Adblock Plus and NoScript are two mobile Firefox add-ons that take advantage of this deep extensibility. (Note: both are compatible with the last stable release of Firefox for Nokia Maemo; they'll need to be updated to support the pre-release Android versions.)

  • Uses the Jaegermonkey JIT, which is getting faster all the time. It runs JavaScript much faster than the Android 2.1 browser, and is starting to overtake the Android 2.2 browser on the benchmarks in SunSpider and similar suites.

  • Supports web technologies like SVG, ECMAScript 5, WebM, and HTTP Strict Transport Security. Firefox for Android currently scores 217 points plus 9 bonus points on html5test.com. (Warning: Those tests can be deceptive; use them as a starting point for comparison only.)

Another difference is that Firefox is built by Mozilla, a non-profit organization with a mission to promote openness, innovation, and opportunity on the web. We want our work on the mobile web to benefit everyone, not just Firefox users - just as Firefox on the desktop helped create a new era of innovation and standards for users of all web browsers.

Competition and choice

There are many other browsers for Android, but all of them use the built-in WebKit rendering engine (except Opera Mini, which uses a proxy server for rendering). The same is true for Apple iOS, which is also based on WebKit – as are the latest versions of BlackBerry, Symbian, and Palm webOS.

There's nothing wrong with WebKit. It's a great project. But a growing number of mobile sites work only on WebKit (or even just on iOS or Android). This is dangerously similar to the web ten years ago, when Internet Explorer had an overwhelming market share and many sites used IE-specific markup. This made it very hard for other browsers to compete, which killed the incentive for the dominant browser to keep improving.

Upcoming platforms like MeeGo and Windows Phone may give WebKit some real mobile competition - but many users still won't be able to choose new browser technology without buying new hardware (and often new service contracts). We think people should have a meaningful choice of browsers on their existing phones, just like they do on their computers.

Reusing vs. extending

Part of the point of Firefox is to provide an alternative to the built-in browser engine. Firefox for Android is built on the same Gecko engine as Firefox 4 for desktop. That's how it can add new capabilities like Sync, SVG, and ES5.

Many mobile platforms do not allow browsers to include low-level components like JIT compilers. On platforms like BlackBerry that support only "managed" languages like Java, this is true for technical reasons. On others like iOS, it is forbidden purely as a policy decision. Fortunately there are still platforms like Android, webOS, and Maemo that let apps bundle any libraries they want.

Although Android allows us to distribute our own rendering engine and JavaScript compiler, it really is not built with applications like Firefox in mind. Many Android phones were built with around 64 MB to 512 MB for apps. Users who think nothing of a 12 MB download to install Firefox or Chrome on a laptop will certainly think twice before installing it on one of these phones! Fortunately storage space is much larger on most new phones, but this is still an issue on existing hardware.

Android NDK packaging: Problems and solutions

Android's WebKit libraries are installed on the system partition, and are not part of any app. Firefox doesn't have that luxury; its must include the Gecko libraries in its APK file.

Due to a quirk of the Android NDK, apps' native libraries are saved in two places - compressed inside the APK, and extracted to a folder for loading. For apps like Firefox that are mostly native code, this more than doubles the installation size. Current pre-release versions of Firefox use 30 to 40 MB of storage. Other NDK apps like Google Earth pay the same double storage penalty.

To solve this problem, Mozilla's Michael Wu is writing a custom dynamic linker, so Firefox can load libraries directly from the APK without installing them to a folder. This cuts the installed size in half, but increases the startup time slightly. For newer phones with 1 GB or more of internal storage, we might choose to let Firefox take more space but start faster. On phones with less storage, we can use the custom linker to save space. We're also working on other ways to make startup faster.

System components have another advantage: They can be optimized for specific hardware. In contrast, apps usually come in a single flavor for all devices. Firefox for Android can use ARMv7 features like Thumb-2 and NEON to run as fast as possible on high-end Android phones - but when it's built with these optimizations it can't run at all on low-end hardware. To run optimally on all current hardware, we'd need different builds for different devices. For now, we are focusing on the current high-end phones, which will likely be next year's mainstream hardware.

Try it out

To check if your phone is compatible and download a test build, see the Firefox for Android web page. Our pre-beta nightly builds are already much faster than the alpha release from a few weeks ago. This is still pre-release software, and we aren't done stabilizing and optimizing it - but we are working hard. Let us know what you think!

If you don't want to mess with nightly builds, look for our first beta release very soon now. Beta 1 will include our first batch of speed and stability improvements. And beta 2 will include even more exciting changes like the new Android skin, reduced installation size, and OpenGL-accelerated compositing.

If Fennec doesn't work on your phone, you can also test it on other platforms. And we hope increased choice will encourage all browsers to innovate and learn from each other, so your mobile experience will improve no matter which browser you use.

Syndicated 2010-10-04 23:00:00 from Matt Brubeck

Changes for add-ons in Fennec alpha

Last week we released a new alpha version of Firefox for Android and Maemo (a.k.a. Fennec). This release brings some major changes and new features for add-on authors. Our Fennec add-on documentation now has the details you need to start updating your Fennec add-ons or creating new ones.

What's new for add-ons?

One very big change in this release is Electrolysis, the project to move content and chrome into separate processes. Any add-on code that interacts with web content through the DOM must now be in a separate script that runs in the content process. For details, see the Electrolysis guide for add-on authors.

Fennec 2.0a1 also features new APIs for extending the context menu and site menu. See the User Interface Guide for links to documentation and example code.

The upcoming beta releases will include even more changes. Add-ons that use Fennec's panning and zooming features will probably need significant changes for the new graphics code in Fennec 2.0b1. We will also include APIs for for add-ons to customize sharing and other new features. If you are working on an add-on that is affected by these changes, please let us know.

Get started

To start updating or creating your Fennec add-on, download our Fennec alpha for Android and Nokia N900 or download the emulator for Mac/Windows/Linux. When you're ready, update your addons.mozilla.org listing and set the maxVersion to 2.0a1. Or you can start getting ready for beta by setting your maxVersion to 2.0b1pre and keeping up-to-date with our pre-beta nightly builds.

Syndicated 2010-09-02 23:11:00 from Matt Brubeck

Fennec 2 update: The road to alpha

The Mozilla Mobile team has been quiet lately. We're making a lot of under-the-hood changes for the next version of Fennec (Firefox for mobile), and have been focused on getting basic functionality working again after some major platform changes.

Now things are starting to stabilize, and we are gearing up for the first Fennec 2.0 alpha release in just a few weeks. There are still noticeable bugs in our current builds, but it is possible to use them now for testing, add-on development, and regular web browsing (if you don't mind occasional crashes).

Under the hood

The biggest back-end change in Fennec 2 is Electrolysis (a.k.a "e10s"). By moving content rendering and JavaScript into a separate process, e10s allows the Fennec UI to stay responsive while pages are loading. This required us to rewrite large parts of the Fennec UI and platform code, a process that is finally approaching completion.

After the alpha release, the next big platform changes will be related to Layers. Fennec currently handles panning and zooming by dividing pages into "tiles" and rendering them on HTML canvas elements. This works, but it is complicated and not as fast as we'd like. The new layers system will let us replace Fennec's custom tile management with hardware-accelerated rendering and compositing built into the Firefox 4.0 platform.

Features

We have a bunch of new features planned for the Fennec UI. A few of these have already started to land, so you can try them in nightly builds or the upcoming alpha:

  • Firefox Sync is now built in – sync tabs, bookmarks, and history from your computer to your phone, no add-on required!

  • The new Find In Page command is available through the site menu (or by pressing Control+F on a hardware keyboard).

  • You can now share links through Twitter, Facebook, Google Reader, or email. (The final version of this feature will also let you send links using native Android or Maemo apps.)

  • Fennec 2 can use your phone's address book to make it easy to enter phone numbers and email adresses into web forms. (This works on Maemo now; support for Android will be added later.)

  • We're adding multi-touch gestures. Pinch zoom has landed for alpha; later releases will also include multi-touch swipe gestures to go to the top or bottom of the current page, or navigate between pages.

The design of these features is not yet final, so their look and feel may change significantly before the final release.

Android

Fennec 1.0 and 1.1 were for available only for Nokia's Maemo operating system. Fennec 2 will run on the Google Android platform, as well as Maemo and its successor MeeGo.

Fennec for Android is brand new, but it is progressing fast. Most of the blocking bugs for alpha 1 have been fixed in the last few days, and the very latest nightly builds are usable for regular browsing, though still rough in places.

Some of our most visible Android bugs were related to keyboard and input method support. Jim Chen's IME rewrite fixed a lot of these bugs, including a crash on startup with the popular Swype keyboard. There are still a few keyboard bugs left to fix before alpha 1.

Other Android changes, like alert-bar notifications and a new visual theme, will appear in our beta releases this fall.

Add-ons

For Fennec add-ons, the biggest change coming is Electrolysis. Any add-on code that interacts with web content through the DOM must now be in a separate script that runs in the content process. Mark Finkle has written a very useful Electrolysis guide for add-on authors.

In Fennec 1.1 we added the site menu and context menu. Fennec 2 will have improved APIs for add-on authors to add new items to either of those menus. Documentation of the new APIs is coming soon.

(Note: Add-on installation from web pages is broken in today's nightly build. This will be fixed before the 2.0a1 release.)

Nightly builds

Fennec 2.0 alpha 1 will go into code freeze as soon as the remaining a1 blocker bugs are fixed. If you want to start testing or developing for Fennec 2 even sooner, you can download a nightly build today. Just remember this is still pre-alpha software, and you should expect bugs.

  • Maemo users can use the trunk repo to stay up to date with the latest nightly build.

  • For Android users, the Fennec for Android wiki page has pointers to the latest nightly build, plus a list of known bugs and compatible hardware. (A number of Android blogs have linked recently to random TryServer builds and out-of-date blog posts. Please go to the wiki page instead to get the latest information.)

  • If you don't have a compatible Maemo or Android device, you can always download nightly Fennec builds for Mac/Windows/Linux and try out Fennec on your desktop or laptop.

If you have questions, feedback, or bug reports, file them under Fennec in Bugzilla, or come to the #mobile channel on irc.mozilla.org to chat with us!

Syndicated 2010-08-12 23:23:00 from Matt Brubeck

Implementing the viewport meta tag in Mozilla Fennec

The upcoming release of Mobile Firefox (Fennec) 1.1 features improved support for the <meta name="viewport"> tag. Previous version of Fennec supported the width, height, and initial-scale viewport properties, but had problems with some sites designed for iPhone and Android browsers. We now support the same properties Safari does, and we changed Fennec to render mobile sites more consistently on screens of different sizes and resolutions.

touch.facebook.com before:

touch.facebook.com after:

You can see these changes for yourself in the latest 1.1 or trunk nightlies.

Background

Mobile browers like Fennec render pages in a virtual "window" (the viewport), usually wider than the screen, so they don't need to mangle existing layouts by squeezing them into a tiny window. Users can pan and zoom to display different areas of the viewport.

Mobile Safari introduced the "viewport meta tag" to let web developers control the viewport's size and scale. Many other mobile browsers now support this tag, although it is not part of any web standard. Apple's documentation does a great job explaining how it works for web developers, but it leaves out some information that would be useful to browser vendors. For example, it says the content attribute is a comma-separated list, but existing browsers and web pages use a mix of commas, semicolons, and spaces as separators.

A pixel is not a pixel

The iPhone and many popular Android phones have 3- to 4-inch screens with 320×480 pixels (~160 dpi). Fennec's target devices have the same physical size but 480×800 pixels (~240 dpi). Because of this, the last version of Fennec displayed many pages about one third smaller (in physical units) than iPhone or Android. This caused usability and readability problems on many touch-optimized web sites. Peter-Paul Koch wrote about this problem in A pixel is not a pixel is not a pixel.

Fennec 1.1 for Maemo will use 1.5 hardware pixels for each CSS "pixel," following the lead of the Android browser. This means a site with "initial-scale=1" will render at the same physical size in Fennec for Maemo, Mobile Safari for iPhone, and the Android Browser on both HDPI and MDPI phones. It's also consistent with the CSS 2.1 specification, which says:

If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length.

This change only affects web pages that explicitly set the viewport size or scale. The pixel ratio is 1.5 applies only if the viewport scale is set to 1. The size of a "pixel" on any page changes with the zoom level, and the default zoom level for most pages in Fennec has not changed.

On 240-dpi screens, pages with initial-scale=1 will effectively be zoomed to 150% by both Fennec and Android WebKit. Their text will be smooth and crisp, but their bitmap images will probably not take advantage of the full screen resolution. To get sharper images on these screens, mobile web developers can create images at 150% of their final size (or 200%, to support the rumored 320-dpi iPhone) and then scale them down using HTML/CSS.

WebKit on Android also supports an additional undocumented target-densityDpi to let web developers override the CSS-to-device pixel ratio. Fennec doesn't support this property now, but if we see a compelling need for it (or if it becomes part of a documented standard) then we might implement it too.

Right now Fennec uses the same default ratio of 1.5 on all devices. (This is a hidden preference that can be changed in about:config or by an add-on.) Later we'll need to change this – as well as many other parts of Fennec's user interface – to choose the correct size automatically, depending on the screen density.

Viewport width and screen width

Many sites set their viewport to "width=320, initial-scale=1" to fit precisely onto the iPhone display in portrait mode. As mentioned above, this caused problems when Fennec 1.0 rendered these sites, especially in landscape mode. To fix this, Fennec 1.1 will expand the viewport width if necessary to fill the screen at the requested scale. This matches the behavior of Android and Mobile Safari, and is especially useful on large-screen devices like the iPad. (Allen Pike's Choosing a viewport for iPad sites has a good explanation for web developers.)

We also added support for minimum-scale, maximum-scale, and user-scalable, with defaults and limits similar to Safari's. These properties affect the initial scale and width as well as limiting zooming after the page is loaded.

Standards

Viewport metadata has proved to be a useful extension to HTML, and I think it is worth standardizing. According to the HTML5 spec, new names for the meta element should first be registered on the WHATWG wiki and then be ratified through the W3C standards process. If anyone at Mozilla or elsewhere is working on a standard specification for viewport metadata, please let me know.

Syndicated 2010-05-10 22:36:00 from Matt Brubeck

121 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!