IEBlog — CORS for XHR in IE10

The fourth platform of IE10 simplifies building cross-site scenarios that work consistently across browsers by supporting Cross-Origin Resource Sharing (CORS) for XMLHttpRequest (XHR). CORS for XHR makes sharing data across sites simple and flexible. In the most basic scenario CORS enables creating data sources accessible from any site, and with a few small tweaks you can choose to constrain allowed sites, support data modification, and even allow authentication. Most importantly CORS keeps existing sites secure by requiring server participation.

Simple Cross-Origin XHR

Let’s look at how a cross-origin XHR request compares to a same-origin request. From script, the only difference is the URL passed to the open method. For example, say we’re working on a script that fetches a list of photo albums.

Traditional XHR

// Script running on http://photos.contoso.com

var xhr = new XMLHttpRequest();

xhr.onerror = _handleError;

xhr.onload = _handleLoad;

xhr.open("GET", "/albums", true);

xhr.send();

Now we want to access the list of albums from another origin. The other origin can be a completely different domain or a different host with the same base domain. Either way, just pointing at the full URL from another site is enough to get the browser to automatically send a CORS request.

CORS-Enabled XHR

// Script running on http://www.contoso.com

var xhr = new XMLHttpRequest();

xhr.onerror = _handleError;

xhr.onload = _handleLoad;

xhr.open("GET", "http://photos.contoso.com/albums", true);

xhr.send();

Sites can provide fallback for older browsers by wrapping this in feature detection. Checking for “withCredentials” is the best approach since it directly relates to CORS support for XHR.

CORS-Enabled XHR with Feature Detection

// Script running on http://www.contoso.com

var xhr = new XMLHttpRequest();

if ("withCredentials" in xhr) {

xhr.onerror = _handleError;

xhr.onload = _handleLoad;

xhr.open("GET", "http://photos.contoso.com/albums", true);

xhr.send();

} else {

// Fallback behavior for browsers without CORS for XHR

}

At this point our client code makes a CORS request directly to "http://photos.contoso.com", but the request fails to return any data. The failure occurs because the server isn’t participating yet. Taking a quick look at the developer tools gives us an idea what went wrong.

Screenshot showing the F12 tools indicating no 'Access-Control-Allow-Origin' header was found.

Here we can see the server needs to send an “Access-Control-Allow-Origin” header in the response. In our scenario we’re not opening up our albums for any site to access, but want to enable access solely from “http://www.contoso.com”. Doing this requires allowing the server to identify where the request originated. Examining our outgoing request reveals a new header containing precisely this information, “Origin”.

Simple CORS Request Headers

GET http://photos.contoso.com/albums HTTP/1.1

Origin: http://www.contoso.com

...

Using this information the server can choose to limit access to any set of sites. If the server always adds an “Access-Control-Allow-Origin” header with a value of '*' then all sites will have access. For our scenario, we’ll have the server verify the origin and then set “Access-Control-Allow-Origin” to allow only “http://www.contoso.com”.

Simple CORS Response Headers

HTTP/1.1 200 OK

Access-Control-Allow-Origin: http://www.contoso.com

...

With the above updates in place, our “http://www.contoso.com” client can now access album lists from the server at “http://photos.contoso.com”.

Cross-Origin XHR with Preflight

The “simple” CORS requests discussed so far are great for basic, read-only scenarios, like downloading a photo album. Taking the next step by modifying data across sites requires a bit more work on the server. For example, say we’re adding code in the client to create a new album.

var xhr = new XMLHttpRequest();

xhr.onerror = _handleError;

xhr.onload = _handleLoad;

xhr.open("PUT", "http://photos.contoso.com/albums", true);

xhr.send(JSON.stringify({ name: "New Album" }));

Running this as-is doesn’t work. Examining the network traffic reveals a request is sent, but not the one we expected.

Screenshot of the F12 tools showing an OPTIONS preflight request.

What the browser actually sent is known as a preflight request. Preflight requests are sent before requests that may result in data modification on the server. Such requests are identified by the presence of non-simple properties as defined in the CORS specification. These properties range from certain HTTP methods like “PUT” to custom HTTP headers. Browsers send preflight requests to ask the server for permission to send the actual request. In our example the browser is verifying a “PUT” request is allowed.

Preflight Request

OPTIONS http://photos.contoso.com/albums HTTP/1.1

Origin: http://www.contoso.com

Access-Control-Request-Method: PUT

...

Getting the browser to send the actual request requires some changes on the server. Once again we can take a look at the developer tools for more information.

Screenshot showing the F12 tools indicating no 'Access-Control-Allow-Methods' list was found.

The first step is to make the server recognize the “OPTIONS” preflight request as distinct from other requests for the same URL. After the server verifies the preflight request by ensuring “Access-Control-Request-Method” is asking for “PUT” from an allowed origin, it sends the appropriate approval via the “Access-Control-Allow-Methods” header.

Preflight Response

HTTP/1.1 200 OK

Access-Control-Allow-Origin: http://www.contoso.com

Access-Control-Allow-Methods: PUT

...

Once preflight is out of the way and approved the actual request takes place.

Actual Request

PUT http://photos.contoso.com/albums HTTP/1.1

Origin: http://www.contoso.com

...

Adding the album is technically complete at this point, but our client code won’t know that unless the server responds correctly. Specifically the server must still include “Access-Control-Allow-Origin” in the response.

Actual Response

HTTP/1.1 200 OK

Access-Control-Allow-Origin: http://www.contoso.com

...

With that the client can add a new album cross-origin and recognize whether or not the action completed successfully.

Next Steps

Pairing CORS with other new platform features enables interesting scenarios. One example is the Cross-Site Upload Test Drive which tracks cross-origin file uploads using CORS, XHR, FileAPI, and progress events.

—Tony Ross, Program Manager, Internet Explorer

Bruce Lawson — On the vendor prefixes problem

People have asked me to explain the vendor prefix problem. This is me (Bruce) explaining what I believe to be true (a couple of details are fuzzy to me, so forgive any errors – I’m trying to explain the concept). This is NOT a statement of Opera’s position or intents, so don’t be a dick and blame them for my opinions or mistakes.

Right.

On Monday at the CSS Working Group, Microsoft, Mozilla and Opera announced that each are considering supporting some -webkit prefixed CSS properties. (Search the minutes for “Vendor Prefixes”. Florian is from Opera, Tantek represents Mozilla, Sylvaing is Microsoft’s glamorous rep, and Tab is from Google. Glazou is Daniel Glazman and Plinss is Peter Linss, the two co-chairs of the Working Group.)

Lots of developers, despite evidence to the contrary, have assumed that mobile Web = WebKit browsers, because that’s the rendering engine in Android and iThings.

Suppose a developer made site a while ago and used the experimental, pre-standardised code -webkit-border-radius and didn’t use the cross-browser future-proof method.

The real CSS property border-radius has been long been standardised and supported without prefixes in all the major browsers. But the -webkit- prefixed version still lingers on in Safari and Chrome, so that legacy code looks fine in the webkit browsers, but broken in Opera, Firefox and Internet Explorer.

The webkit team have said that they won’t remove such legacy properties for compatibility reasons, and I haven’t heard howls of indignation about this. So the recent proposal is that non-webkit browsers will support -webkit-border-radius as if it were border-radius and thus won’t look “broken”.

I imagine that sites that only use -webkit-transition and -webkit-text-size-adjust etc will be similarly supported.

This is an approach suggested by Daniel Glazman, co-chair of the CSS Working Group:

The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set.

Exactly which prefixes would be supported in this way and whether they would be the same in Opera, Microsoft and Firefox, I don’t know.

Personally – PERSONALLY – I’m pretty depressed about all this. I’ve spent 10 years – pretty much since IE6 came out – evangelising cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.

Daniel has put out a call to action for developers to fix their sites and mend their ways: CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*. Chris Heilmann of Mozilla has launched a community action called Pre-fix the web!. Read them. Join in. I truly hope they work (although fear it’s too late).

Comment if you like, but I won’t be able to moderate them for a few days, so better to write your own blog posts!

(added 18:45)

I should add (because it’s not clear) that we will still need responsible developers using vendor prefixes right – this is not the end of vendor prefixes. We still need better, responsible evangelism and demos from those who teach.

The proposal is to support a subset of -webkit- prefixes, especially the archaic stuff like -webkit-gradient, so that those sites don’t look dreadful in non-webkit browsers. The plan is not to support everything that the webkit devs pull out of their hats, every time they get the urge to extend CSS.

So, we still need to use cross-browser future-proof vendor prefixes if we decide to let experimental, pre-standardised code out on production sites.

Planet Mozilla — CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*

The CSS Working Group, the W3C, the browser vendors and the Open Web need you, and I really mean you ALL. The following article is written by Daniel Glazman, co-chairman of the CSS Working Group; the part until "This must not happen" represents an official discussion of the CSS Working Group. Members of the Group behind that discussion include Adobe, Apple, Disruptive Innovations, Google, HP, Microsoft, Mozilla, Opera and the World Wide Web Consortium (W3C). The second part of the article is strictly mine.

Not so long ago, IE6 was the over-dominant browser on the Web. Technically, the Web was full of works-only-in-IE6 web sites and the other browsers, the users were crying. IE6 is dead, this time is gone, and all browsers vendors including Microsoft itself rejoice. Gone? Not entirely... IE6 is gone, the problem is back.

WebKit, the rendering engine at the heart of Safari and Chrome, living in iPhones, iPads and Android devices, is now the over-dominant browser on the mobile Web and technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying. Many sites are sniffing the browser's User-Agent string and filtering out non-WebKit browsers. As in the past with IE6, it's not a question of innovation but a question of hardware market dominance and software bundled with hardware. But there is an aspect of the problem we did not have during the IE6 era: these web sites are also WebKit-specific because they use only "experimental" CSS properties prefixed with -webkit-* and not their Mozilla, Microsoft or Opera counterparts. So even if the browser sniffing goes away, web sites will remain broken for non-WebKit browsers...

In many if not most cases, the -webkit-* properties WebKit-specific web sites are using do have -moz-*, -ms-*, -o-* equivalents. Gradients, Transforms, Transitions, Animations, border-radius, all interoperable enough to be browser-agnostic. Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.

Without your help, without a strong reaction, this can lead to one thing only and we're dangerously not far from there: other browsers will start supporting/implementing themselves the -webkit-* prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That's not a question of if, that's a question of when.

Let me be very clear: this is NOT hypothetical and I'm not discussing here something that could happen. All browser vendors let us officially know it WILL happen, and rather sooner than later because they have, I quote,  "no other option". Let me also state very clearly that is NOT a lack of innovation on these browser vendors' side, in particular when they DO support a feature but with their own prefix, following here the Working Group's rules.

THIS MUST NOT HAPPEN.

This situation happened in the past with IE6, when browsers were desktop-only, and it took ten long years to recover. With billions of mobile browsers today, the Web may not recover at all.

Vendor prefixes have not failed. They are a bit suboptimal but they also very clearly preserved Web Authors from chaos. We can certainly make vendor prefixes work better but we can only do that if vendor prefixes remain VENDOR prefixes.

I am asking all the Web Authors community to stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.

I am asking all the Web Authors community to remove immediately and stop implementing WebKit-based browser sniffing in web sites. You own such a web site? Show your support for the Open Web and remove that browser sniffing immediately after you finish reading this call for action.

I am asking the Web Design and Web Users community to stop recommending web sites that require one single browser while they could be open to multiple ones. Don't link them, mention them only to let the community know they fail serving the Open Web. Don't feed the trolls; blacklist them, whatever is the coolness of the service they provide.

I am asking the Web Authors community to update their online services to support the other browsers if these other browsers offer a level of CSS support they did not offer in the past. Do that NOW! Very little effort, big effect.

I am asking the whole Web community, all Users, to ping Web Authors and complain if their web sites work only for one rendering engine while it could work for many. Help us evangelize these Web sites to make sure the Architecture of the Web remains safe for all, remains based on consensual and open Web Standards, because browser vendors implementing the prefix(es) of other browser vendor(s) can only lead to a chaos of the IE6 magnitude. We did it in the past for works-only-in-IE6 web sites and we did it well, now is the time to do it again for works-only-in-WebKit web sites.

I am also asking the browser vendors behind WebKit, namely Apple and Google, to submit as soon as possible to the CSS Working Group complete technical proposals for the proprietary CSS-like properties they have let the whole world use in iOS and Android devices, harming the Open Web. An example of such a property is -webkit-text-size-adjust. Please note the Apple representative to the CSS WG said he'll look at the possibility to have proposals submitted for a list of such properties. If these properties are so well implemented and so useful to the mobile Web, they became de facto standards ; let's turn them as soon as possible into de jure standards through W3C standardization. I am also calling Apple and Google to remove support for the "experimental" versions of a property when the final one is implemented and shipped. We, and that we represents the whole Web Industry, cannot let the architecture of the Web become unsafe and unreliable keeping forever vendor prefixes that should be gone. That is harmful and this is your responsibility, because you could provide mandatory software updates to your users. The Open Web does not have to suffer of such a decision.

So please all express your opinion, help the Open Web and tweet or blog that you don't want to see this happen. Some of you already started, after reading the minutes of the CSS Working Group face-to-face meeting in Paris. Let Microsoft, Mozilla and Opera know this is the wrong way to go even if we understand perfectly both the diagnosis and their proposed solution. If browser vendors standardize the Web, it's really owned by Users and Authors and now is the time to let browser vendors remember it better. YOUR VOICE DOES MATTER.

I am finally asking you to relay that call for help. For that reason, comments are closed on this article. Use your blog, your twitter account, Facebook, Google+, whatever. But do it.

Jeffrey, Eric, Molly, Lea and all our friends of the Web Designers' community and/or Web Standards' community: please help us. Now.

If you're a journalist, I'm immediately open to interviews on this topic (please note I'm based in Europe).

Thank you.

Updates:

Planet Mozilla — Mobile Meeting Minutes: 2012-02-08

Mobile/Notes/08-Feb-2012

Contents

Details

  • Wednesdays – 9:30am Pacific, 12:30pm Eastern, 16:30 UTC

  • Dial-in: conference# 95312
    • US/International: +1 650 903 0800 x92 Conf# 95312

    • US toll free: +1 800 707 2533 (pin 369) Conf# 95312
    • Canada: +1 416 848 3114 x92 Conf# 95312
  • irc.mozilla.org #mobile for backchannel
  • Warp Core Vidyo Room

Schedule

TDB – See Major Topics

Major Topics for This Week

Beta Status
We are not releasing a beta this week. We made the decision that rendering performance (panning and checkerboarding) was not good enough for a beta release. Patrick and BenWa started work on using GL-layers in Gecko/Android to improve rendering performance. Work has also started on off-main thread compositing (OMTC) to make panning more responsive. Erin and Alex are working on schedule impact and planning.
  • We don’t know if this means Fx11 is not the release for Native. We are working to answer that today or tomorrow. <== we need the OMTC work to land in m-c before a new schedule can truly be set.

  • Work continues to drive down crashes, improve stability and improve UI responsiveness.
GL-Layers and OMTC
Work to convert mobile to use GL backed layers is happening at breakneck speed. We should have a demo of the GL-layers work at today’s Mobile Demo meeting.
  • We will use the Maple branch to continue the GL work

  • Builds are available and Fennec is demoable.
  • Working to get estimates on timelines and collateral breakage
ARMv6 Status
Ted and Mike have got armv6 starting up. See Ted’s tweet.
  • We need to stamp out any other ARMv6-related crashes

  • We need to look at performance characteristics
Chrome for Android
ICS-only and no Flash, but a pretty solid release otherwise. How do we match up?

Stand ups

Suggested format:

  • What did you do last week?

  • What are working on this week?
  • Anything blocking you?

Please keep your update to under 2 minutes!

James W. (snorp)
Kats
  • Last week

    • fixed bug 718684 (positioning problems with form input inside iframes)

    • investigated bug 719033, dupe of 717085
    • fixed bug 723545 (futzing around with robocop makefile)
    • fixed bug 723619 (allow grabbing painted surface afer animtions in robocop)
    • fixed bug 720538 (double-tap could allow ending up with bad zoom/overflow + regression test)
    • investigated bugs 720902 and 716096, dupes of 720538
    • perused through unassigned bug list for some brain-dead things, duped/wfm’d some bugs
    • fixed bug 724949 (add more regression tests)
  • Next week

    • Do some perf measurements of cairo vs skia

    • help as needed for the new GL layers code
    • Land some gfx patches on beta that haven’t gotten there yet
    • bug 723295 (startup crash on API >= 8 with no sdcard) – I had a fix but it was backed out; needs more code rewrite
  • Blockers

    • Not get useful traces out of gdb (this used to work before on a linux build) which is making it slower to get gw280′s skia work up and running
GBrown

Last week:

  • Bug 720930 Robocop: testBookmark fails if there are no bookmarks

  • Bug 717023 convert robotium Log.* calls to dumpMessage calls
  • Bug 718827 Robocop: testBookmark uses key events
  • Bug 696095 Create Fennec startupCache at build time

Next week:

  • Finalize startup cache discussion?

  • More robocop and devicemanager work
AlexP

Last week

  • Worked on input issues in designMode document (Etherpad): bug 719121, bug 721393

    • While investigating these found bug 723810, which affects the editing in designMode documents

    • Discussed the issue with Masayuki, got some useful information
    • Compared the implementation in XUL and Native
    • Implemented a fix, which seems to work, but needs more testing

This week

  • Finish designMode document fixes

  • Work on the assigned bugs
Chris Lord (cwiiis)
    • Last week
  • bug 720613 – java.lang.RuntimeException: Screen size of (480,800) larger than maximum texture size of 0
  • bug 722068 – Sub-tile invalidation isn’t working properly on pages with animations (fall out from bug 717283)
  • bug 722325 – Repeated areas of the page, or blank areas displayed momentarily after panning (layout regression from bug 720987)
  • bug 717349 – Telemetry to measure checkerboarding
  • bug 724230 – On-demand tile patches are risky and unnecessary without further patches/testing
  • Gave talk at FOSDEM about the state of Firefox Mobile with lucasr
  • Reviews
    • This week
  • bug 725255 – Improve checkerboarding telemetry
  • bug 724928 – We could tell Gecko to draw less to improve checkerboarding
  • Help out with OMTC
  • Reviews
Chris Peterson
  • Last Week

    • bug 715251 – Reduce overscroll distance and janky scrolling — IMPLEMENTING REVIEW FEEDBACK

    • bug 708167 – Testing about:home without Placeholder initialization. — ON HOLD, WAITING FOR bug 723251
  • This Week

    • bug 681192 – Investigating romaxa’s patches to avoid layer invalidation when scrolling — IN PROGRESS

    • bug 706891 – Making axis scroll lock unbreakble (regression from XUL Fennec) — WAITING FOR REVIEW
  • Blockers

    • Waiting for bug 723251 to fix placeholder screenshots before I can commit bug 708167 to sidestep displaying screenshot. :)
GCP
  • Last week

    • Re-landed safebrowsing changes.

    • Blogged about the safebrowsing changes.
    • Added WIP patch to Sync preference migration (bug 715550)
  • This week
    • Continue Sync preference migration.

    • In process of moving the profile migration to use the ContentProvider instead of BrowserDB
  • Blockers
    • Require working Password Manager (wesj? bug 704682 etc)
Brian N
  • Done

    • bug 721776 – Bookmark is removed from bookmark list only after Fennec restart

    • bug 722413 – Bookmark menu item not updated when deleting bookmark in AwesomeBar
    • bug 724152 – Honor URL_SAFE flag for base64 encoding/decoding
    • bug 722184 – Add keyword support to AwesomeBar searches
    • bug 724194 – Allow editing bookmarks in AwesomeScreen
    • bug 725213 – Add search engines from text input fields
  • Next
    • Test cases

    • More bugs
Sriram
  • Last week:

    • Landed ICS specific landscape mode (bug 712687)

    • Investigated Tabs-tray loaded and provided optimization options (bug 706819)
    • Removed web apps shortcut in widgets
    • Restricting the height of autocomplete popup (bug 711185)
  • This week:
    • Newer replacements for default thumbnails (bug 721847)

    • Fixing black portion shown on thumbnails (bug 721841) – backed out due to failures
    • Avoiding tab indicator animations on rotation
    • UI fix on URL bar to show default text
    • Avoiding empty space on closing a tab (bug 722278)
    • Avoiding jumping to top after tab close (bug 718268) – WIP
    • Working on content branded about:home
      • Cleaning up about:home for faster startup is in progress
  • Blockers:
    • None
WesJ

Last Week:

  • Bug 723200 – Enable multitouch by default on Android

  • Crash fixes

This Week:

  • Touch events cleanup

  • Password provider – got reviews yesterday. fixing today
  • Form history provider

Blockers

  • None
LucasR

Last week

  • Talk at FOSDEM

  • bug 723103 – Properly update about:home when history is cleared
  • bug 723841 – Bookmarks database consistency constraints
  • bug 719434 – ‘Tabs From Last Time’ not wiped on Clear History

Next week

  • More P1/P2 bug fixing (focused on DB and perf bits)

Blockers

  • None
MBrubeck

Forgot to do an update last week; this covers two weeks.

Done:

  • bug 723977 – Disabling Full Screen add-on does not disable full screen mode

  • bug 723917 – NullPointerException when removing a menu item
  • bug 720985 – Temporarily whitelist properties leaked by Fennec tests
  • bug 723480 – Mouse events in XUL Fennec broken by bug 721484
  • bug 723772 – Mousemove events broken in XUL fennec
  • bug 723746 – XUL Fennec uses non-tablet layout on ICS tablets
  • bug 720932 – Clean up default search engine code
  • bug 723084 – Remove observers when tabs are destroyed
  • bug 722808 – Back out c0ae127e29cd (bug 717522) because of nightly build failures
  • bug 719921 – Enable add-ons compatible by default for Fennec
  • bug 721459 – Enable WebSMS by default for B2G
  • bug 720400 – Crash in nsPluginInstanceOwner::RemovePluginView @ mozilla::AndroidBridge::EnsureJNIThread
  • bug 721301 – Disable font inflation by default in XUL fennec
  • bug 720614 – Disable WebSMS by default
  • bug 708774 – Always use fullscreen landscape keyboard in native fennec
  • bug 719557 – “Full Screen” add-on (window.fullScreen) has problems in native Fennec
  • bug 715275 – New default favicon images for different resolutions

Next:

  • Font inflation UI

  • Add-on preferences and other add-on manager bugs
  • Fixing some tests and other bugs
Margaret

Done:

  • Landed bug 719875 – Re-work tap-to-play plugins so that they work with back/forward navigation

  • Spent most of the week working with bookmarks
    • Talked a lot with rnewman to figure out/file problems caused by sync

    • Landed bug 724045 – createMobileBookmarksFolder doesn’t set title or parent
    • Landed bug 716918 – Basic bookmarks UI to display mobile and desktop bookmarks separately
    • Landed bug 725171 – Context menu is broken on bookmarks on the awesome screen
    • Investigated (then passed off to lucasr) bug 723841 – Bookmarks database consistency constraints

Next:

  • bug 722020 – Fennec Native doesn’t show bookmarks in folders, or in desktop sequence

  • bug 724756 – removeBookmark can remove an arbitrary number of bookmarks
  • UC Berkeley Career Fair next Wednesday afternoon (Feb. 15)
Scott (jwir3)

Last Week:

This Week:

BLassey
  • Prepared for split release

  • Fixed Eclair builds (just in time for GFX to break them)
DougT
  • code reviews

  • meetings
  • crash kill stuff
    • OMG:
    • Wes just pushed a fix to the current top crash

    • 3 more java crashes in the top 10.
    • making good progress
MFinkle
  • Handed off Add-on Manager bugs to Matt

  • Focused on some planning and some MWC
  • Uplifting to Aurora
  • Picking up small bugs
Madhava

on behalf of mobile UX, who are all traveling or sick:

  • following and responding to ux issues in *existing* bugs as they’re resolved

  • otherwise, we’ve moved on to tablet and next version
    • more on this soon and in bugs
Ian Barlow
Patryk Adamczyk
BenWa/AJuma

Work to convert mobile to use GL backed layers is happening at breakneck speed. We should have a demo of the GL-layers work at today’s Mobile Demo meeting.
Wiki page: https://wiki.mozilla.org/Platform/GFX/OffMainThreadCompositing

  • We will use the Maple branch to continue the GL work, waiting for the repo to be cleared, currently still working off the kiwifox user repo.

  • Builds are available and Fennec is demoable.
  • Work towards: Displayport, Adreno crash fix, Layer positions, Buffer Rotation, Performance measurements & improvements, Artifact-free rendering after orientation change and keyboard appearance/disappearance
  • Working to get estimates on timelines and collateral breakage

Round Table

SUMO
  • Updating and creating new articles to support nativeUI; https://wiki.mozilla.org/Support/Goals/NativeUIdocs

  • Question: Is there an opportunity to work on the menu? Having Settings & Add-ons under ‘More’ on gingerbread puts them further away than they were in XUL. Could they be moved back to the top?
QA
  • Filed all* the Java crashes that crash-stats knows about

  • waiting on the Beta plan will assist
Project Management
  • Just in case this wasn’t clear: We won’t have a schedule for beta and final until next week: we need to land the OMTC changes in m-c,before we widely circulate a new schedule. Landing is gated on the items being tracked in this bug and right now, we’re hoping to land to m-c in a week: bug 725095 OMTC: Land Android compositor

  • I will probably have a draft by the end of the week, but it will need to be approved and again, we need to see how the OMTC patch queue is looking before pick up where we left off; this will be testable on the Maple branch very soon.
Retrieved from “https://wiki.mozilla.org/Mobile/Notes/08-Feb-2012“

Planet Mozilla — Firefox/Gecko Delivery Meeting Minutes: 2012-02-08

Firefox/Planning/2012-02-08

« previous week | index | next week »

Planning Meeting Details

  • Wednesdays – 11:00am PDT, 18:00 UTC

  • Mountain View Offices: Warp Core Conference Room
  • Toronto Offices: Fin du Monde Conference Room
  • irc.mozilla.org #planning for backchannel
  • (the developer meeting takes place on Tuesdays)

Video/Teleconference Details – NEW

  • 650-903-0800 or 650-215-1282 x92 Conf# 95312 (US/INTL)

  • 1-800-707-2533 (pin 369) Conf# 95312 (US)
  • Vidyo Room: Warp Core
  • Vidyo Guest URL
REMEMBER

These notes are read by people who weren’t able to attend the meeting. Please make sure to include links and context so they can be understood.

Contents

Actions from Last Week

  • Cheng to follow up with kev on AVG bustage in FF10

Schedule & Progress on Upcoming Releases

Firefox Desktop
Release (3.6, 10)
  • We plan to ship 10.0.1 (both mainline and ESR) with the following changeset this Friday (2/10): 18ce5e304e97
Beta (11)
  • Barring unexpected issues, Firefox 11 Beta 2 will ship this Friday (2/10)
Aurora (12)
  • Aurora 12 desktop was out to testers as of 2/3

  • Aurora 12 mobile was out to testers as of 2/7
Nightly (13)
  • Safebrowsing move from SQLite to flat file landed (bug 673470)
  • If you’re seeing long hangs on Aurora 12 or Nightly 13, please comment in bug 725110
  • Safe Mode: Auto detect previous start-up failure and offer to start in safe mode bug 294260

  • [New Tab Page] Set to enabled by default on Nightly bug 716538
Firefox Mobile
  • No mobile beta this week

    • We are holding for performance issues

    • Schedule is being reworked
  • Hi, Chrome on Android
    • We will be adding Chrome to our competitive testing

    • Solid beta, but not intimidating
Firefox Sync
  • Sync now has a Product Marketing Manager. Welcome to Greg Jost!

  • Native Sync
    • did not go to Beta, along with native fennec

    • Please file bugs. Not sure how to file a good android sync bug? http://160.twinql.com/how-to-file-a-good-android-sync-bug
    • We have daily bug triage at 4pm
    • You can find us on irc, #androidsync
    • Old news that bears repeating
      • Data may be lost, reordered, or corrupted. Please do not use your good profiles

      • Migration from XUL to Native may cause your sync account to disappear
      • Please remember behavior is undefined if multiple instance of Native Fennec (nightly, aurora, etc) are on a single device
      • You still cannot create an account from a mobile device
  • Work has started on integrating BrowserID into Sync authentication
    • The two sync systems will not be backwards compatible or interoperable
  • Coming to a release near you
    • Firefox 10 has setup UI streamlining, mobile-to-mobile device pairing

    • Addons being sync’ed in Firefox 11, XUL/tablet Fennec 11 (aka Beta): Addon Sync
    • Native Sync has been enabled in Nightly & Aurora (but not Beta)
Add-on Builder
  • release today

  • shooting new tutorial today
  • all systems are still GO for launch next Wednesday February 15th
Add-on SDK

Release (1.4 -> Firefox 9, 10)

  • Found a nasty and released 1.4.3

    • Important for developers using simple-prefs, simple-storage, or passwords APIs to take a look at:

    • Blog post explaining issue and fix
    • We wrote a module to help anyone affected “recover”

Stabilization (1.5 -> Firefox 10, 11)

Development (1.6 -> Firefox 11, 12)

  • On track to merge to Stabilization on Feb 21, 2012

Add-on of the week!

Feedback Summary

Desktop

Firefox 10:

Mobile
  • FF10 Android market feedback is consistent with previous XUL releases (performance and flash are top issues). NativeUI will fix both of these problems.

SUMO Days update:

  • We started SUMO Days on Nov 3rd and we answered 58% of the questions asked that first day.

  • We’ve been working to grow the contributors to our support forum and improve the SUMO web content every two weeks since.
  • Last week, we answered 81% of the questions asked and we’ve made a big improvement in the overall average of questions answered. So, huge congrats to the SUMO contributors for their hard work to optimize the site content and get us on a path to answering every user question every day.

UX & User Research

Research

  • The Mobile Diary project is now in the hands of our users. The project will help us learn more about user attitudes, behaviors, and use cases. If you want to get an in-depth look at user needs, consider attending a participant interview, scheduled in the SF Bay area on Feb 15-16, 18-19, and 21st. Get in touch with Mary Trombley if you’re interested.

Design

  • Australis project:

  • Translation designs in progress
  • Metro UI (Win 8) design in progress
  • URL Autocomplete landed! Then disabled! Then hopefully enabled again! (might change to only complete for previously typed entries)
  • New download manager still awaiting landing
  • New tab refinements continuing, enabled by default, give us feedback!
  • Home tab in UX branch has launch targets for Bookmarks/History/Downloads, and Apps in the future

Market Insights

Desktop / Platform
Google
  • Google released a beta of Chrome for Android, based on a fork of the Chromium code (version 16.0.915.75). A major focus for the development team is to re-merge the trees; some of the work has been done. Because of the Java base of Android, a lot of work using Java Native Interfaces will have to be done, no doubt to improve device support.
  • Chrome for Android also has integrated support for a mobile remote debugger, allowing developers to debug or profile their mobile web pages and web apps using a desktop machine. Here’s a screencast demo. Developers are encouraged to ask questions on stackoverflow.com.
  • Google announced that Chrome would soon stop conducting SSL online revocation checks, using its existing software processes to distribute lists of revoked certificates.
  • The German government, in a general list of recommendations for computer security, recommended the Google Chrome browser, primarily because of its sandbox architecture.
  • Development versions of Chrome now feature a new Settings UI that is fluid and appears to make use of graphic acceleration; see the video at the link for a demo.
  • The Dev version also now has partial support for Web Intents — here’s a screenshot.
Microsoft
  • The Windows 8 Consumer Preview will be released on February 29 at Mobile World Congress.
  • The IE team’s blog posted a detailed summary of the upcoming support of CSS3 3D transforms, with some interesting demos.
  • In a related post, the team drew attention to the fact that IE10 embedded in Metro apps will have the same performance, unlike similar apps on iOS, which run more than three times as slow.
Opera
  • The W3C blog posted an interview with two members of the Opera team. They said among other things that Opera Mini’s proxy browsing / compression features make it so popular with users in developing regions that carriers use it in their advertising. There’s also an interesting summary of their vision for HTML5 on television sets.
Other
  • RIM has announced that all the code in their SDK for the upcoming Blackberry 10 platform will be open sourced. Code is available at http://blackberry.github.com and development of the HTML5 SDK is happening in the open there.
  • There’s a proposal at the W3C for the next version of HTML to support accessing image metadata in the DOM.
  • Strangeloop Networks released a “State of the Internet” report that indicates that while the average site is 10% faster than it was a year ago, top-ranked sites are getting bigger and slower, with the average home page containing 98 objects.

Mobile

This week we are talking about Chrome for Android beta. Summary below, detailed report in your inbox.

  • Yesterday Google launched Chrome for Android beta, as a first step towards making Chrome the standard browser for Android version 4 and above. The release supports Ice Cream Sandwich, ARMv7-based devices, which currently make 1% of the Android install base and account for a 3 million addressable base.
  • The browser is based on Chrome v16 and V8 v3.8 and has a multi-process architecture similar to the desktop version. It does not have plug-in support, and lack of Flash in particular has been the main negative reaction to its launch among a lot of positive ones. This is also the reason for most of its 1 to 2 star ratings in the Android Market. An Android Central poll asking “Is a lack of Flash support on the mobile browser a deal-breaker?” has 47% of Yes answers and 52% of No.
  • Its UA String is: Mozilla/5.0 (Linux; U; Android 4.0.2; en-US; Galaxy Nexus Build/ICL53F) AppleWebKit/535.7 (KHTML, like Gecko) CrMo/16.0.912.75 Mobile Safari/535.7)
  • Speed, simplicity and personal are its main user propositions, while tab management, user data sync, the Omnibox and its multi-process architecture are the main promoted features. For developers, Chrome comes with a remote debugging via USB feature and boasts Web standards compliance, extensive HTML5 support and hardware acceleration.
  • Its positioning speaks to speed, personalization and extension of the desktop. Branding is persistent in the product on the New Tab page. Messaging tone is similar to Chrome on the desktop: friendly, light, easy-going, simple and straight to the point. Tagline is “Your Chrome, away from home.”

Marketing, Press & Public Reaction

Desktop
  • Finishing 3.6 Upgrade Display Ads this week.

  • Finalizing plans for next Firefox release.
  • Finishing Up devices page and reworking content silos on mozilla.org/firefox and mozilla properties.
Mobile
  • Re-visiting positioning and marketing plan for Firefox for Android

  • Preparing for MWC
  • Video for Firefox 11 launch
Press

Questions, Comments, FYI

  • Do we have a plan for shipping Firefox 11 on patch Tuesday? If not, when/where will that be figured out? (bhearsum)

    • We will go manual only until we are comfortable unthrottling (late in the week of 3/11, or early in the week of 3/18)
  • Update on feedback: HTTPs problem seems to be “connection reset” errors when connecting to servers on non-standard ports (may be self-signed cert specific)
  • When should Push/BiPostal/Notifications appear as a product here? [ally]

Actions this week

  • ally to coordinate with greg jost on sync uptake metrics, and measuring the impact of the FF10 usability changes

  • laura to report on the state of persona/personas discussion
  • cheng to report back on connection reset issues with SSL
  • johnath to wrangle representation in this meeting for identity
Retrieved from “https://wiki.mozilla.org/Firefox/Planning/2012-02-08“

Planet Mozilla — Announcing the December Dev Derby Winners

IndexedDB lets web applications store structured data for fast online and offline use. Data can be stored using key-value pairs, and values do not need to be serialized (as they do with document-oriented databases) or coerced into a relational structure (as with relational databases).

Recently, creative developers from around the world demonstrated just how powerful IndexedDB can be in the December Dev Derby. Please join us in congratulating the top three demos as chosen by our judges.

1st Place: eLibri by mar.castelluccio
2nd Place: FileSystemDB by mar.castelluccio
3rd Place: IndexedDB Editor by twolfson

Runners up:
Vurkout Buddy by wcheung
Locate It IndexedDB by nestoralvaro

Congratulations to our winners and to everyone who submitted to the December Dev Derby.

Do you want to see your name here next month? We are now accepting demos related to Touch Events (February), CSS 3D Transforms (March), and HTML5 audio (April). Get an early start by submitting today!

Planet Mozilla — FOSDEM, Mozilla Antarctica, WebFWD and more…

about:mozilla is a weekly round-up of news and contribution opportunities. Here’s what’s happening this week.

FOSDEM 2012
Last weekend many Mozillians attended FOSDEM in a freezing cold Brussels. A huge thank you to Benoit Leseul and team for organizing our efforts there. Rob Hawkes talked about open Web apps and open Web games, whilst Tristan Nitot announced six grants to international non-profits who will strengthen the Web, free and open source software and user sovereignty.

Mozilla AntarcticaMozilla Antarctica
The Mozilla Antarctica Community Site recently launched which will provide news, interviews and other stuff from the coolest Mozilla community. Not only do we love the penguins but Antarctica is the only continent to have a majority Firefox market share. Must be all the intelligent scientists using it!

Become a WebFWD Affiliate
Do you want to spread some open source love? You do? Great! Because you can now become a WebFWD affiliate and increase awareness of Mozilla’s open innovation program. Signing up is super simple and in a few clicks you can display your love of WebFWD.

Bedrock ready to go!
The Web Development team have finished the new Bedrock platform which will power the mozilla.org website. Bedrock is a complete rewrite of the site, clearing up years of cruft and implementing cool new features.

Interview with Nikhil Suresh
Havi Hoffman interviews Nikhil Suresh about Bouncy and the Apple, his non-violent 2-person shooter game which won him the November MDN Developer Derby. She learns a little bit more about Nikhil and what inspires him.

Meet Some Mozillians
Bonjour Mozilla says bonjour to Serge Gautherie, Melek Jebnoun, Tim Taubert and Felipe Gomes and Sean Martell. A special hello to (quite possibly) the youngest Mozillian on the planet: William Joseph Markham. Read more about how these people are contributing to Mozilla.

Upcoming events
* February 10, Online – Firefox Beta for Android Test Day
* February 23, San Fransisco, USA – WebQA ‘Live’ Test Day
* See more on the Mozilla Community Calendar

Get Involved
These are just some of the available contribution opportunities. Learn more about other ways to get involved and find other Mozillians in our community who share your interests.

About about:mozilla
The newsletter is written by Mozilla’s contributor
engagement team and is published every Tuesday.

If you have anything you would like to include in our next issue,
please contact: about-mozilla[at]mozilla[dot]com or send us a status message on mozilla.status.net or a tweet @aboutmozilla .

You can also subscribe to the email version.

Have a good week folks and keep rocking the Web!

Planet Mozilla — Come work with me for the Mozilla Foundation

At the moment I’m the only developer on my team at Mozilla, in fact I’m the only person in my team. I am “Team Ross”. Thankfully in March this will change, we’ve already hired a designer and we’re looking to add at least another developer to work on supporting the Mozilla Foundations work, events and communities.

If that’s already got you wanting to apply then please have a read of the job spec and get your application in – http://careers.mozilla.org/en-US/position/oIkXVfwE. If you’re looking for more information please read on…

What will I be working on?

Short answer – lots!

Detailed answer – just this week we’ve launched a the new Knight-Mozilla Open News partnership. The site right now is pretty basic and there are tons of improvements that need to be made. We want to do something around our events platform, including getting an events platform; you can read more about that through the thoughts of Ben Simon on the infrastructure of self-organising and Michelle Thorne on potential feature requests for web makers (trying to crowd source what things we might initially need). Mozilla are running a partnership with the National Science Foundation, Geni, Ignite and the White House called Mozilla Ignite so there is work to be done on that site as we build out the feature set there. Then there is the Mozilla Festival… So yeah, we’ll make sure you don’t get bored.

“Team Ross” as it currently stands (or sits) – come make it a proper team!

Of course all of your work will happen in the open – your code will be on github, our dev servers will have public access as will our bug tracking systems and wikis. I’ve found this a really exciting part of the job so far and it’s certainly not as scarey as you think it might be – people when commenting on your code are helping you make it better and there is a global knowledge base to tap into.

What technology will I be using?

Mozilla are a web company so everything will be based around HTML5. Server side we’ve got projects running on Django (using Mozilla Playdoh), nodejs and wordpress. We’re not tied to one technology and decide on a project by project basis what is the best fit in terms of what’s most useful for the client and can produce the best experience for our end users.

Where can I work from?

Mozilla have, or soon will have offices in 9 locations worldwide but also are very open to remote working. So where ever you are reading this from if you think you’re a good fit then please apply!. London will have it’s office opening in the next month or so, I’ve been in, it’s looking great and has a good location in Covent Garden; it will also come with it’s own bar!

So where do I apply?

As mentioned above you can apply (don’t forget to include a github/bitbucket/googlecode URL) at http://careers.mozilla.org/en-US/position/oIkXVfwE

Any further questions then please ask in the comments.

Bruce Lawson — Reading List: mobile development approaches

Just three links for this reading list, because they show a profound schism in the way people are thinking about building applications that have previously been desktop only and take them to mobile.

The schism is the same as we’ve long had on desktop. It’s simply: do you make your target audience as wide as possible, or do you only design for people who use the same technology as you do?

The nations’s favourite social-media based conference organiser thingy, Lanyrd, launched its mobile version two days ago. I don’t own an iThing, but I assume it’s great there, and it looks and works excellently on Opera Mini and Opera Mobile on Android.

Jake Archibald, JavaScript developer at Lanyrd, said

“Although we’re employing some ‘new and shiny’ browser features, we’ve taken the righteous path of progressive enhancement and been liberal with our testing and support. While most mobile offerings are targeted at particular devices or WebKit, our support includes quirky devices like the old Blackberry 9000 (yes, it still haunts people’s pockets), the Kindle, and even basic feature-phones if they can run Opera Mini. The site works as expected without JavaScript.

Compare this with the 37Signals’ blogpost yesterday, provocatively entitled Developing for old browsers is (almost) a thing of the past:

It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.

What is this fabulous remedy that 37signals have found? Simply, ignoring users of browsers that you don’t want to support. “Supporting your browser is hard – let’s go shopping”, as Barbie says, or Regressive Ken-hancement in strict Computer Science terminology.

Compare this with Jake Archibald’s comment:

All it took was *not* doing everything wildly different to how you should develop a standard website.

Summarising this dichotomy is an excellent article Did we lose track of the big picture?:

It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) – from targeting users, to focusing on devices and modern browsers.

We write about new techniques without considering fall back mechanisms, we use ARIA “hacks” that look like anti-patterns and we use frameworks that have chosen to ignore oldIE.

If you read no other high-level articles this month, read that one.

Planet Mozilla — Firefox 11 for AT developers

Here's an update what's new in Firefox 11 (beta, release on March 13) for assistive technology developers.

HTML

CSS generated tables (CSS display:table style) are exposed as layout tables. Originally this piece of work was targeted to Firefox 10 but we weren't in time to make this happen.

HTML table cells (HTML th and td elements) gained new not standard axis and abbr object attributes.

The axis object attribute is direct mapping of HTML @axis attribute. This object attribute is supposed to help AT to extract semantic of rich HTML tables in the web. Granted, this HTML attribute is not wide used on the web but we wanted to break the chicken-egg problem: browsers/AT don't support it iff web authors don't use it.

The abbr object attribute is less academic than previous one and useful to pick up short accessible name for header cells, for example, it makes sense when the user traverses through table cells and screen reader announces related heading information for each cell. The user doesn't want to hear long header cell names on and on: that's what abbr object attribute is supposed to help to. This object attribute is exposed in two cases:
  • HTML abbr element is inside the table cell
  • @abbr attribute is used on table cell
Examples: 
  <th id="th1"><abbr title="Social Security Number">SS#</abbr></th>
  <th id="th2" abbr="SS#">Social Security Number</th>

HTML acronym and abbr elements allow @title attribute for accessible name computation. This can be illustrated by following example:
  <input id="input">
  <label for="input"><acronym title="O A T F">OATF</acronym></label>
Accessible name of input accessible is "O A T F" now.

HMTL5

HTML5 figure and figcaption elements are now accessible.  The figure element is exposed with generic MSAA ROLE_SYSTEM_GROUPING and ATK ATK_ROLE_PANEL roles because neither IAccessible2 nor ATK provide more suitable roles. AT can rely on xml-roles:figure object attribute to detect figure element. HTML figure element picks up accessible name from figcaption element which is exposed with IA2_ROLE_CAPTION / ATK_ROLE_CAPTION role. The figure and figcaption accessible objects are linked by LABELLED_BY / LABEL_FOR relations.

The content of HTML5 canvas element is not accessible still but Firefox 11 started to expose an accessible object having IA2_ROLE_CANVAS/ATK_ROLE_CANVAS role for canvas element itself. Not big deal but it's a good first step on canvas accessibility.

ARIA

ARIA attributes used on HTML file element (input@type="file") are propagated to underlying text field and "Browse" button, i.e. accessible states defined by these attributes are inherited.

ARIA combobox (@role="combobox") fires MSAA EVENT_OBJECT_VALUECHANGE event and ATK accessible-value signal when option is changed. Here's an example of ARIA combobox widget.

Correctness

IA2_STATE_ACTIVE/ATK_STATE_ACTIVE state is exposed on active item for standard composite widgets like HTML select elements. The state can be used for example to detect the current item of the widget when the widget isn't focused. We make our implementation closer to ARIA widgets where aria-activedescendant technique is used. Another side of this code unification is IAccessible::accSelect called with SELFLAG_TAKEFOCUS flag can be used on widget items now.

Small fix for IAccessible::get_accName that returns S_FALSE when the accessible object doesn't have accessible name. Not big deal. Done for consistence and meet MSAA spec.


Planet Mozilla — Mozilla Platform Meeting Minutes: 2012-02-07

Platform/2012-02-07

« previous week | index | next week »

Platform Meeting Details

  • Tuesdays – 11:00 am Pacific

  • Dial-in: conference# 95312
    • US/International: +1 650 903 0800 x92 Conf# 95312

    • US toll free: +1 800 707 2533 (pin 369) Conf# 95312
    • Canada: +1 416 848 3114 x92 Conf# 95312
  • Warp Core Vidyo Room
  • join irc.mozilla.org #planning for back channel

Contents

Notices / Schedule

Firefox Development

  • As mentioned last week, New Tab is now on by default. Tim Taubert is on a tear fixing followup issues, improving performance of the thumbnail service, and making styling tweaks.

  • Inline autocomplete has been disabled on trunk while we fix some additional issues that popped up (bug 720792). Marco is on the case, and we’ll get that re-enabled shortly.
  • Chemspill candidates for FF10 are being discussed at today’s channel meeting (2PM PT in Warp Core)

Firefox Developer Tools

  • Initial Debugger Has Landed

    • Preffed off: to enable, set devtools.debugger.enable to true.

Performance

GFX

JS

Layout

  • Edwin Flores (intern) making good progress on “embedded SVG glyphs in OpenType fonts” (aka “SVG Fonts Done Right”) bug 719286. We should have something shippable-but-preffed-off-by-default soon.

  • Other notable patches:
    • bug 721068 Graphite font shaping update from SIL

    • bug 722322 Have the “1″ and “2″ keys switch between images in reftest-analyzer.xhtml
    • bug 722071 Implement array style indexing for SVGStringList
    • bug 714839 nsCSSFrameConstructor now inherits nsFrameManager

Video

  • libcubeb landed for Windows, but was disabled due to some random test failures

    • Matthew working on reenabling that, plus tracking down failures in Mac and ALSA backends
  • WebRTC:
    • alder repo now builds on Win32 (thanks Ted!).

    • Win32, Linux and Mac can capture images from video with fabrice’s bug 629955 patches
    • Chrome is now shipping Canary Chromium builds with a very early version of WebRTC enable-able. A number of 3rd-parties have built early demos based on it; several were shown at IETF Interim last week.
    • Data channel API/protocols firming up; will evangelize at HTML5 Gaming work week in Toronto (great for games!) and look to implement ASAP

DOM

WebAPI

  • Started work on WebNFC

  • Mounir is editor for Network Information API and Screen Orientation APIs at W3C

Network

Identity

Plugins

Mobile

Accessibility

Tree Management

Security

  • No security reviews this week due to security work week in Santa Cruz.

  • Please work with Curtis to schedule reviews and
  • Update feature pages so we have accurate information

Stability Report

Socorro
Desktop
Firefox 10 Top Issues
  • Noticed increase in cycle collector crashes – GCGraphBuilder::NoteXPCOMChild(nsISupports*) – #2 crash

    • bug 724129 – startup crash nsXBLDocumentInfo::cycleCollection::Traverse

    • bug 724284 – Security bug we believe is causing the above regression.
    • bug 718284 – Bug in FF11 that is also causing an increase of these crashes.
  • Startup crash @ PR_EnumerateAddrInfo | nsDNSRecord::GetNextAddr – #3 crash
    • bug 718389 – Spike we saw in FF10b4

    • No clear next steps for investigation. Correlation reports have been inconclusive.
  • bug 725009 – crash je_free | mozutils.dll. May be related to Flash.
Firefox 11 Top Issues
  • Increase in hangs – bug 722394

    • bug 709209 – This is complicating our investigation.

    • Marcia logging some plugin side reports that might help uncover the issue – bug 724617
    • Top concern, not making much headway – need some developer help with the analysis.
  • bug 715401 – new on 11a2 but rising in b1 – trying to isolate the regression range.
  • bug 718284 – Separate issue causing increase in cycle collector issues.
Firefox 12 Top Issues
  • Nothing new and notable on Aurora yet.
Trunk Top Issues
Mobile
  • Socorro fixes to separate out Java signatures – fix went out last week.

    • bug 719943- new field in json metadata needs exposure in the UI
  • Crash volume going down after a bunch of fixes landed last week.
Trunk Top Issues
  • Still lots of new stuff landing. Focus on logging all the new Java signatures…

  • top crash fixed – bug 723550 – Lots of base64 decode errors in logcat
  • bug 724215 – java.lang.NullPointerException: at org.mozilla.gecko.GeckoEvent.addMotionPoint(GeckoEvent.java)
  • bug 723495 – java.lang.IllegalArgumentException: View not attached to window manager at android.view.WindowManagerImpl.findViewLocked(WindowManagerImpl.java) – (affects 13, 12, 11)
Aurora Top Issues
  • bug 711852 – Crash in neon_composite_over_8888_8888 or neon_composite_over_n_8_0565 or fast_composite_over_8888_0565 or arm_neon_fill @ libxul.so@0xa – (affects 12, 11)
Beta
  • Not enough data yet – top issue is just 4 crashes

  • bug 719741 – Crash @ __libc_android_abort | dlfree | free | fclose

Roundtable

Retrieved from “https://wiki.mozilla.org/Platform/2012-02-07“

IEBlog — High performance HTML5 content in Metro-style Apps

Metro style apps in Windows 8 have all the performance benefits of IE10 when showing Web content. In Metro style apps, Web content is always JIT compiled and hardware-accelerated. Other platforms do not provide the same level of performance in apps. For example, Cocoa apps on iOS offer significantly worse JavaScript performance (via the UIWebView control) than the same content running in Safari. These Cocoa apps do not enjoy JIT compilation, and these apps cannot show and use Web content the same way the browser on the system can:

Chart showing that Web content in an Apple iOS app is over 3 times slower than the same content in Apple Safari on the same device.
Testing configuration: http://www.webkit.org/perf/sunspider/sunspider.html.
iPad: 1st Gen, iOS 5.0.1.
Windows 8: Developer Preview, Dell Optiplex 745, 64-bit OS.
Kindle Fire v1.

Why is this important?

Many applications embed HTML to provide a richer and always up to date experience for consumers. For example, the developer of a restaurant guide app might want to include a live map showing the locations of the list of restaurants the user is choosing from. If you write an app on iOS, common actions like panning and zooming the map will run twice as slow in an app compared with Safari.

Anyone writing a Metro style app for Windows 8 can easily include Web content in their app. In an HTML or XAML app, just include an <iframe> element or a WebView control to get the full benefit of IE 10 performance. To see a sample HTML app that demonstrates this, check out the “Building Your First Metro Style App Using Javascript” hands-on lab at http://www.buildwindows.com/Labs.

Screen shot of HTML Content from Bing Maps in an HTML Metro style app
Figure 1: HTML Content from Bing Maps in an HTML Metro Style App

With Metro style apps, it’s easy to integrate many existing Web services seamlessly into your app. It’s also possible to build new services for your app that let you deliver dynamic HTML content without having to update your application.

When you include Web content in your Metro style app, your app gets all the performance benefits of IE10 automatically without any additional or special work. JavaScript code continues to run fast with JIT compilation, and your app will automatically use GPU to accelerate HTML graphics.

—Andy Zeigler, Senior Program Manager, Internet Explorer

Planet Mozilla — Vendor interactions with the CSS working group and product secrecy

The minutes from yesterday's CSSWG face-to-face meeting are a very interesting read in all sorts of ways. I was somewhat struck by this part:

  tantek: I think if you're working on open standards, you should propose
          your features before you implement them and discuss that here.
  smfr: We can't do that.
  sylvaing: We can't do that either.

Those are the Apple and Microsoft representatives replying to Tantek.

Now I won't claim that Mozilla always does this, or that it's even always desirable; it's often better to have a prototype and then discuss the standard than discuss standardization in a completely theoretical way. But this is not about prototypes; this is about not being able to talk about a feature until there's a more or less complete implementation, which is when Microsoft and Apple tend to announce new features. I knew that both Microsoft and Apple had longstanding policies of refusing to discuss future plans, but hadn't really thought about the negative effect this blanket policy has on standardization efforts...

Peter Beverloo — Bringing Google Chrome to Android

Finally we’re able to provide an answer to the many rumors which have been going around in the past few months: Google Chrome is now available for Android devices running Ice Cream Sandwich. On my Galaxy Nexus, the browser scores 343 points on html5test.com, runs the SunSpider test in 1880ms and scores 1308 points on the v8 test.

Support for the Web Platform
The first beta uses the same basis as Google Chrome 16, meaning it has most Chromium and WebKit changes up to mid October 2011. I’ve already iterated through many of the changes which were included in that release, most of which will apply for the Android version as well.

To name some highlights, Chrome for Android supports pretty much all of the Web Platform’s exciting features, including CSS 3D Transforms, GPU accelerated canvas, CSS Animations, SVG, WebSockets (including binary messages!) and Dedicated Workers. It supports IndexedDB, Application Cache and the File APIs, date and time pickers, parts of the Media Capture API and mobile oriented features such as Device Orientation and Geolocation. Fixed positioned elements are also working and even look smooth while scrolling!

What the Android-based Chrome does not support is Flash, following Adobe’s announcement in November. Other unsupported features in the beta release are Extensions/Apps, WebGL, Shared Web Workers and the Web Audio API.

An issue that often pops up for mobile browsers is that text on the website may be too small to read properly. Where the Android Browser employs a text reflow algorithm to clarify the situation, Chrome for Android features a technique which we’ve called Font Boosting. It uses an algorithm to increase font sizes when necessary, aiming to make the text readable regardless of the zoom level.

And for the Web Developers among you, it’s also possible to utilize Web Inspector’s Remote Debugging feature to inspect and modify pages while viewing it on the device itself.

Google Chrome 16 and mobile limitations
Of course, bringing a browser to a different -much more limited- platform goes further than simply re-using code. Mobile devices have a lot of limitations compared to desktop and laptop machines. Besides the lower amount of available memory and CPU power, other constraints lie in less memory bandwidth and VRAM on the device’s GPU. Google Chrome has a complicated architecture which imposed some interesting challenges here: separating the browser from the renderers through its multiple process architecture, to name an example. Decreased rendering and scrolling performance were also an issue, to which Chrome’s GPU team provided an excellent answer in the form of a threaded compositor.

Another characteristic of the Android platform is that the APIs for most significant features are exposed through the Android SDK, making them available to Java code. To this end, part of the browser layer has actually been implemented in Java, communicating with the rest of the Chromium and WebKit code through Java Native Bindings.

Becoming part of the Chromium project: upstreaming our code
Chrome for Android has been developed in a separate repository as a fork, which means that most of the code will have to be upstreamed. To date, about 150 commits have landed in Chromium making many preparations, including the build environment and bots for Chromium and WebKit, not to mention WebKit’s umbrella bug and the two announcements.

As having a fork is far from ideal, one of the current top priorities will be to upstream most new and modified code to Chromium and WebKit, while the build and testing infrastructure on Chromium’s waterfalls is expected to evolve significantly. A snapshot of the current source-code of Chrome for Android can be downloaded as a tarball.

Of course, keep in mind that today’s release is just a beta; much more work, features and stability will be needed to actually be able to release the first stable version. Personally, I’m very glad that the project has been announced, and definitely am looking forward to continuing development in the open!

Planet WebKit — A deeper look at Chrome for Android

Today, we introduced Chrome for Android Beta, which brings Chrome’s capabilities to phones and tablets running Android 4.0, Ice Cream Sandwich. This is made possible by a range of innovative features and by building a mobile browser from the ground up that makes full use of the underlying architecture built into Android 4.0.



Chrome for Android brings support for many of the latest HTML5 features to the Android platform. With hardware-accelerated canvas, overflow scroll support, strong HTML5 video support, and new capabilities such as Indexed DB, WebWorkers and Web Sockets, Chrome for Android is a solid platform for developing web content on mobile devices.

In addition to support for the latest web technologies, we hope to make interactive web content super easy to develop. Chrome for Android introduces remote debugging through Chrome Developer Tools to make it simple for developers to debug web sites running live on their mobile devices.

Much of the code for Chrome for Android is already shared with Chromium and over the coming weeks, the Chromium team will be upstreaming many new components developed for Chrome for Android to Chromium, WebKit and other projects.

We’ve got a lot more planned to make Chrome as feature-rich on mobile devices as it is on the desktop. We encourage you to follow any of the ongoing development via the issue tracker or join in on chromium-dev@chromium.org.

Posted by Arnaud Weber, Engineering Manager, Chrome

HTML5 Doctor — It’s Curtains for Marital Strife Thanks to getUserMedia

True story: I was tasked by the lovely Mrs Lawson to buy some curtains that match our carpet during the January sales. I dutifully did so — and had to return to the shop straight away because they didn’t match at all. Mrs Lawson accompanied me, and with a withering glance at her incompetent mate, immediately found some correctly hued fabric, and all was well.

But what’s a middle-aged colour-blind bloke to do? I had early in the curtain procurement process decided against cutting a hole in the carpet in order that I may take a sample with me. (All other mistakes aside, this was a correct decision.)

So, in order to ensure that I would never again repeat the mistake, I set out to make an app that would allow me to capture the colour of an image straight from my camera. Of course, it had to be a web app rather than a native app, because we’re web angels, not proprietary devils.

<section id="intro">

getUserMedia

getUserMedia is an API that gives a web page access to a user’s camera and microphone via JavaScript. It’s supported in Opera Labs (latest Android build, latest desktop builds) and WebKit in Chrome Canary builds (instructions).

Like many other APIs, it’s not part of the “real” HTML5 spec. It started life as the HTML5 <device> element, then got moved into the W3C as part of the webRTC specifications. But let’s not taxonomise when we could be having fun.

The first thing we need to do when using super-cool new UIs is detect whether it’s supported:

<figure> 
 if (navigator.getUserMedia) {
  // do something cool
} else {
  // fallback code
}
<figcaption>Basic usage of getUserMedia</figcaption> </figure>

For this article, our “do something cool” will be to grab the dominant colour of the current input stream from the camera. As a fallback, we have several options.

One option, if we’re using the default Android browser, is to show a form that automatically starts the camera when focussed:

<figure> 
<form enctype="multipart/form-data" method="post">
  <input type="file" accept="video/*;capture=camera" />
</form>
<figcaption>Fallback code for Android</figcaption> </figure>

There’s also the capture attribute, a proposed extension from the W3C Device API Media Capture API that tells a user agent where to get the input data. Android extends the accept attribute. See more in David Calhoun’s Device API article. Alternative capture arguments are camcorder (for video), microphone, and filesystem.

Browsers that don’t understand the still-draft Media Capture API will simply ignore the capture attrbute and prompt the user to browse to a file on their file system for uploading.

Users on iOS are out of luck, as their devices don’t allow access to the file system.

<section id="differences-from-media-capture">

Differences Between the Media Capture API and getUserMedia

Robin Berjon, co-chair of the Device API (DAP) Working Group explains: The markup-only Media Capture API is a simpler, low-hanging-fruit version that can work easily for a lot of use cases. It also has a very simple security model (just a file upload).

In fact, it works exactly like <input type=file>, except that it knows to allow the user to grab a pic from the camera by default instead of hitting the filesystem. But just like with <input type=file>, once a picture has been taken (i.e., a file selected), you can access it and read from it using the File API, which means you can stuff it in an <img> or a <canvas> and do nasty things to it without annoying any faraway server.

But of course, if it’s part of a form and you submit it, it gets submitted just like a regular file upload.

The thing is, though, it’s always a snapshot. Even if you use it to take a video (which you can), the page only gets it after you’ve finished shooting. With getUserMedia (gUM), you get the live stream, which you can modify, record, or stream elsewhere. The gUM approach is more powerful but more complex, and it has more severe security issues.

</section> </section> <section id="api">

getUserMedia API

Let’s assume (because we’re optimists) that your user has a getUserMedia-enabled device. The API is nice and simple, as all Web APIs should be.

navigator.getUserMedia accepts two required arguments and an optional third.

The first argument tells the device which media you require access to, and it’s passed as a JavaScript object. So, if you only require access to the microphone, the first argument would be {audio: true}; for video-chatting, you would use {audio: true, video: true}.

The device decides which camera to use: User agents are encouraged to default to using the user’s primary or system default camera and/or microphone (as appropriate) to generate the media stream.

A previous version of the specification allowed hints to user agents about which camera to use. The API could specify “user” (the front camera on a phone) or “environment” (the rear camera on a phone). Debate continues about whether to reinstate this (read the ongoing conversation). One argument against is that letting sites know what cameras a device has could help Dr Malice of Evil Corp. fingerprint users after luring them to his site (which I find to be overly-cautious). Harald Alvestrand poses a conundrum: conferencing units may have a room camera, a document camera and a lectern camera, neither of which is attached to the physical box; which one of these is front?

But let’s not worry at the moment. Devices with more than one camera generally have a mechanism that allow the user to choose which one is used, so this gives the user control. Note also that the spec says User agents may allow users to use any media source, including pre-recorded media files.

The second argument is the success callback, the function to be executed on success, assuming that the user allows access and the device supports your request.

There is an optional third argument. This is the failure callback, the function to be executed if something went wrong. It’s optional, but only optional in the sense that washing your hands before you eat is optional: if you don’t do it, you leave yourself open to all sorts of bugs and your mum will shout at you.

Of course, it’s important to do feature detection before making an API call to ensure that the browser and device are capable, but even if feature detection succeeds, there is still much that can cause failure. For example, the user could deny permission or turn off the camera via a hardware switch, or the device itself could disable the camera.

So here’s how we recommend you use the API:

<figure> 
navigator.getUserMedia({audio: true, video: true}, success, error);

function success(stream) { 
  // ... use 'stream' ... 
} 

function error(){ 
  // display fallback content 
}
<figcaption>Using the gUM API</figcaption> </figure>

To check whether it’s working correctly, we can attach the output of the camera’s stream to the input of an HTML5 video on the page, like this:

<figure> 
<video autoplay></video>
<script>
if (navigator.getUserMedia) {
  navigator.getUserMedia({audio: true, video: true}, success, error);
  function success(stream)
  { 
    // ... use 'stream' ...
    var video = document.getElementsByTagName('video')[0];
    video.src = stream; 
  }
  // ...
</script>
<figcaption>Streaming captured video to an HTML5 <video> element</figcaption> </figure> <section id="differences-between-webkit-and-opera">

Differences Between Webkit and Opera

The two rendering engines that implement getUserMedia do so in two different ways. Hopefully, they’ll harmonise when the features reach the released browsers.

The differences:

  • WebKit uses a prefix — navigator.webkitGetUserMedia — while Opera doesn’t.
  • WebKit implements the options according to an old version of the spec, in which audio and video were passed as strings: 
    navigator.webkitGetUserMedia("video, audio", /* ... */)
    whereas Opera implements the most recent version of the specification which uses JavaScript objects: 
    navigator.getUserMedia({video: true, audio: true}, /* ... */)
  • WebKit attaches the resulting stream like this: 
    video.src = window.webkitURL.createObjectURL(stream);
    which is according to the current version of the spec. Opera uses: 
    video.src = stream;
    and has proposed simplifying the spec (but discussion continues).

But this fragmentation, even though it’s only in experimental browser releases is, like, a total drag, man.

</section> <section id="gUM-shield">

Introducing The gUM Shield

Fortunately, we’ve got your back. Two of the finest minds I know — actually, two of the finest Mikes, Doctor Mike Robinson and Opera’s Mike Taylor — have created a snippet of script that you can copy to shield you from these annoying differences. We’ve named this getUserMedia syntax normalisation script snippet The gUM Shield.

It assumes that there’s a variable called video to which you’ve assigned a reference to the <video> element you’ll stream to. Do this with some mechanism like:

video = document.getElementById('video');

Simply hit the ‘Hub, download it, plug it into your script, and check it out!

Note that it’s experimental. Who knows what’ll happen when Mozilla, Microsoft, and Apple implement it, but please, have a play. Fork it and improve it!

</section> </section> <sectino id="exciting">

Doing Exciting Things with the Video Stream

So far, we’re only echoing the video stream. But, as you’ll know from Tab Atkins’ guest article video + canvas = magic, if we copy the video into a canvas, we can manipulate it:

<figure> 
var video = document.querySelector('video');
var canvas = document.querySelector('canvas');
var ctx = canvas.getContext('2d');

ctx.drawImage(video, 0, 0, video.width, video.height,
  0, 0, canvas.width, canvas.height);
<figcaption>Canvas and video magic</figcaption> </figure>

A common mistake is assuming that this somehow establishes a “live connection” between the video stream and the canvas. It doesn’t. It only grabs the current frame. So you need to grab the current frame repeatedly in order to replicate a video. The magical number is 15 times a second (or every 67 milliseconds), but a slower frame rate would probably be okay for this demo:

<figure> 
setInterval(function () { 
  ctx.drawImage(video, 0, 0, video.width, video.height,
  0, 0, canvas.width, canvas.height);
}, 1000 / 67);
<figcaption>Live updating of <canvas> from a <video></figcaption> </figure>

See the working demo.

What I want to do now is to grab the dominant colour from the canvas. I’m stealing a demo by Shwetank Dixit (who borrowed from Lokesh Dhakar‘s Color Thief demo). We won’t look at how it determines the dominant colour (because that’s nothing to do with getUserMedia).

Try this in Opera Labs and Chrome Canary!

Unfortunately, this works splendidly in Opera but it occasionally fails in Chrome, and we’re not sure why. (We’ve emailed the Chrome team to ask them.) Apart from the rather anti-climactic end to an article, you shouldn’t be dismayed by this. getUserMedia is only available in experimental builds that have plenty of work to be done before they hit production.

Back to our demo. Once you’ve got the dominant colour, you could prompt the user for a name for that colour (“carpet”, for example) and store that in local storage using its name as a key. Then, when you find a pair of curtains in the shop, you can find their dominant colour and easily compare it with that stored against “carpet” from earlier.

And you can return home, confident of delighting the love of your life with your chromatically appropriate choice of soft furnishings. That’s HTML5: enriching marriages since 2004.

woman says 'hey daddy-o, the curtains really razz my berries, ya dig?'. Man replies 'Baby, I totally dig. Early night?'. A thought bubble shows him thinking 'Thank you, getUserMedia' </section> <section id="harshing-your-mellow">

Harshing Your Mellow

Things need refining before web apps with getUserMedia are on a par with native applications. At the moment, there is no way of controlling which camera is to be used (and no agreement that a developer should be able to). The camera’s flash mechanism isn’t programmatically controllable, which could harm the user experience. Most importantly are the privacy implications of web pages being able to access your camera. Opera has an experimental privacy UI, but Chrome has no UI yet.

</section> <section id="demos">

More Demos

See Paul Neave’s HTML5 Webcam Toy and the links at the foot of my Opera Labs article.

</section> <section id="thanks">

Thanks

Thank for help and code are due to Robin Berjon, Shwetank Dixit, Daniel Davis, Lokesh Dhakar, Mike Taylor, Mike Robinson, and Rich Tibbett.

</section>

It’s Curtains for Marital Strife Thanks to getUserMedia originally appeared on HTML5 Doctor on February 7, 2012.

WHATWG blog — WHATWG Weekly: translate attribute and other changes to HTML

Since the last WHATWG Weekly, almost a month ago now, over a hundred changes have been committed to the HTML standard. This is the WHATWG Weekly and it will cover those changes so you don’t have to. Also, remember kids, that fancy email regular expression is non-normative.

translate attribute

To aid translators and automated translation HTML sports a translate since revision 6971. By default everything can be translated. You can override that by setting the translate attribute to the "no" value. This can be used for names, computer code, expressions that only make sense in a given language, etc.

Selector and CSS related changes

In revision 6888 the :valid and :invalid pseudo-classes were made applicable to the form element. This way you can determine whether all controls in a given form are correctly filled in.

Revision 6898 made the wbr element less magical. Well, it defined the element fully in terms of CSS rather than using prose.

A new CSS feature was introduced in revision 6935. The @global at-rule allows for selectors to “escape” scoped stylesheets as it were, by letting them apply to the whole document. It will likely be moved out of HTML and into a CSS once a suitable location has been found.

APIs; teehee!

It turns out that clearTimeout() and clearInterval() can be used interchangeably. Revision 6949 makes sure that new implementors make it work that way too.

Per a request from Adrian Bateman revision 6957 added a fourth argument to the window.onerror callback, providing scripts with the script error column position.

Speaking of scripts, in revision 6964 script elements gained two new events. beforescriptexecute which is dispatched before the script executes and can be cancelled to prevent execution altogether. And afterscriptexecute for when script execution has completed.

Revision 6966 implemented a change that allows browsers to not execute alert(), showModalDialog(), and friends during pagehide, beforeunload, and unload events. This can improve the end user experience.

W3C Team blog — Open Web Platform Weekly Summary - 2012-01-30 - 2012-02-05

Time for your Open Web Platform weekly summary dose. A bit of HTML5, a bit of Web apps, a pinch of Web Architecture and HTTP and everything tied with a Web Education ribbon.

HTML5

Charles Pritchard (Jumis) is asking if the allow_popup attribute value is ready for prime time. IE has an implementation of it and Webkit has an ongoing patch. The goal of the attribute is to allow pop up in some circumstances where it is usually not possible, such as sandboxed iframes.

The abbr attribute on th elements will be added to HTML5 specification.

There is a proposal for the next version of HTML to have a DOM attribute to have access to the metadata contained in images.

There is a meta perma-thread revolving along longdesc attribute but also images map and accessibility. This discussion is not finished yet and let's hope people will reach a common understanding on the issue.

Web Apps

Robin Berjon proposed to add screen orientation lock to the rechartering of Web Apps WG. It is happening sometimes that an app will make sense only when the screen has a specific orientation. On the other hand, your body might have a position which is not the one perceived by the device. For example when you are reading news lying down on the side, and you screen suddenly rotates because of your position.

Should you be able to install Web Apps on your computer. Tim Berners-Lee (W3C) think so and argues for it.

Glen Shires (Google) proposes the creation of a Community Group for the Speech Javascript API.

The discussion on adding Image.toBlob() is still active. It is very similar to Canvas.toBlob(). Some people wondered if in fact it should not be more general and apply to any kind of binary streams.

Education

Chris Mills (Opera Software), who is actively involved in developing a neutral repository for Open Web documentation across platforms, has outlined how the group will move forward. You can join the Web Education Community Group.

HTTP

The discussion about the rechartering of HTTP WG is still going on for working on the new generation of HTTP. There is a lot of input on what are the good strategies for the future. Some people share their opinions about the SPDY experiment. Pretty sure that the IETF WG F2F in Paris (March 25-30, 2012) will be quite active. I will not be there unfortunately.

Web Architecture

Larry Masinter (Adobe) sent a proposal for working on MIME and the Web. The discussion addresses the issues around registries which come quite often. Basically how do we maintain the balance in between the flexibility of the open Web and a control set of values avoiding fragmentation.

Robin Berjon proposed a new draft about the work on API Minimization. He is looking for feedback.

This column is written by Karl Dubost, working in the Developer Relations team at Opera Software.

Planet Mozilla — Firefox Engineering Program Management 4Q 2011 Summary

The Firefox engineering program management team formed at the end of 3Q 2011. The team is currently comprised of Sheila Mooney (smooney – our fearless leader), Martin Best (mbest), Erin Lancaster (elancaster), and me (Lawrence Mandel – lmandel). Our first whole quarter as a team was 4Q 2011. Looking back over the last three months, I find it quite amazing how far the reach of the team has expanded in this time. Here’s a short summary of the efforts in which the team was involved in 4Q 2011. You can also track our team against our 4Q goals.

Mobile

Back in October it was decided to rewrite the Firefox mobile UI as a native Android application. This is no small feat. Erin stepped up as the project manager for this effort and has been doing an amazing job. If you haven’t seen the progress that this team has made in 3 months check out the latest Nightly or Aurora builds. I can’t wait to see this effort reach the first release of the new native Android application early in 2012.

Silent Update

Transforming the Firefox update experience into a silent update experience is another big task that requires changes to the way the browser handles update related prompting including restart, Windows user account control (UAC), and information pages, the update operation itself, and add-on compatibility. Lawrence has been managing this effort, which landed changes for the restart prompt, the what’s new page, and add-ons default to compatible in Q4. The remaining changes are slated to land in 1Q 2012 with all features being released in the 1H 2012.

Bugzilla Anthropology

In an effort to better understand our project’s use of bugzilla, Martin conducted a series of interviews with Mozilla contributors on various teams. The goal of this project is to understand how people use bugzilla. Martin put together a good blog post that provides details about this important project.

Crashkill

Sheila continued to run the ever important Crashkill program that monitors and acts on Firefox stability issues. Along with supporting Firefox desktop, the Crashkill program has been actively contributing crash reports to the new mobile native UI rewrite.

Telemetry

Lawrence picked up management of Telemetry with the immediate goals of improving the Telemetry adoption rate, improving the consumability of the Telemetry dashboard, and increasing adoption of the framework by the implementation of more probes. 4Q saw the release of v2 of the Telemetry dashboard and the initial efforts to improve adoption of this data collection framework among the users on the various Firefox channels. 1Q 2012 will see an improved Telemetry adoption rate, continued work on the dashboard, and even more probes.

Snappy

In October Firefox project leadership made a decision to put the electrolysis effort on hold to focus resources on short term responsiveness gains. The result of this is project Snappy, which kicked off late in 4Q. Lawrence is managing Snappy, which includes broad membership from various front-end and platform teams. In 1Q we plan to move from investigation to solutions. Look for changes to start landing as early as 1Q.

HTML5 Games

Martin kicked off a new effort late in the 4Q to make Firefox an awesome platform for HTML5 based game development. There is lots more coming in 1Q on this active effort. You can follow along on the HTML5 games wiki page.


Tagged: firefox, mozilla, program management

Steve Faulkner et al — Rough Guide: browsers, operating systems and screen reader support

When testing aspects of support for new HTML5,  WAI-ARIA features and HTML features in general, I often test browsers that do not have practical support for screen readers on a particular operating system. I find they have support for feature X, but lack support for feature Y that is required to enable practical support to web content for screen reader users. While it is useful to test and find successful implementations of discrete features, it needs to be viewed in the broader context of which browsers can be considered usable with popular OS level screen readers.

I found it difficult to get a complete understanding from the resources available on the web, but have put together a high level support table based on information I could glean. If you have any further information or find any inaccuracies please comment.

Practical support

Practical support for screen readers means that a browser can be successfully used to browse and interact with commonly encountered web content, using current versions of OS level screen readers such as, on Windows; JAWS, NVDA, Window Eyes. On Mac OSX and iOS; VoiceOver. On Linux; Orca and on Chrome OS; ChromeVox.

table legend

  • supported “supported” means that the browser is usable with a screen reader on the operating system (OS).
  • “partial support” lacks support for some important features. For example, Chrome on Windows supports browsing using JAWS, but does not support the select element or form control labelling using the label element.
  • not applicable “not applicable” means the browser does not run on the OS
  • not supported “not supported” means the browser does not have practical support for screen readers on the OS.

Note: The table refers to the current (06/02/2012) versions of browsers and current versions of operating systems.

Practical screen reader support by browser and OS (06/02/2012)
Chrome Firefox Internet Explorer Opera Safari
Windows partial support supported supported not supported not supported
OSX partial support not supported not applicable not supported supported
Linux not supported supported not applicable not supported not applicable
IOS not applicable not applicable not applicable not supported supported
Android not applicable not supported not applicable not supported supported(webkit)
Chrome OS supported not applicable not applicable not applicable not applicable

References:

Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>