Mobile compatibility tables

This series of compatibility tests is sponsored by Vodafone.

On this page I give a quick overview of the mobile browser compatibility tests I’ve done so far.

If you want the latest inside scoops on my mobile tests, follow me on Twitter.

See also the CSS table.

Disclaimer

These tests are in no way complete. Essentially, you’re looking over my shoulder while I work. That’s fine, but don’t use these tables for serious decisions about the compatibility of your mobile apps yet.

There’s a lot of incompleteness here; from the tests themselves down to the table grid. Right now I’m not even sure if I should order the entries by browser or by phone vendor.

Not all tests are done on the same phones and/or with the same browsers. Unexpected problems such as network outages, problems with wifi connections, or Vodafone’s feared “content adaptation” play havoc with my attempts to conduct tests in a uniform way. That’s not going to change any time soon.

Anyway, you see the problem: I just don’t quite know what a proper mobile test is, how to write it, or how to interpret the test results.

Click event

Event Opera Mobile Opera Mini 4.2 S60 WebKit Apple WebKit Other WebKit NetFront Blackberry IE Mobile Skyfire (VF WM) Nokia E66 (9.5) HTC Touch Diamond (8.65) SE P1i (8.00) Motorola V3xx Nokia E71 Nokia E66 Nokia E71 Nokia N95 Samsung i560 iPhone Android Bolt (E71) Iris (HTC) Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 HTC Touch Diamond Nokia E71 On document Yes Sort of Yes No Yes No Yes Yes To be tested Yes On link Yes Sort of Yes No Yes No Yes Yes To be tested Yes Opera Mini supports click events, but it’s not always clear when it fires them. It doesn’t react directly on clicks on the form field or link, but once you click on the button the clicks on form field and link show up. On form field Yes No Sort of Yes No Yes No Yes Yes To be tested Yes On paragraph Yes No Yes No Yes No Yes Yes To be tested Yes Event bubbling Yes Yes Untest able Yes Untest able Yes Yes To be tested Yes

DOM & Ajax

Event Opera Mobile Opera Mini 4.2 S60 WebKit Apple WebKit Other WebKit NetFront Blackberry IE Mobile Skyfire (VF WM) Nokia E66 (9.5) HTC Touch Diamond (8.65) SE P1i (8.00) Motorola V3xx Nokia E71 Nokia E66 Nokia E71 Nokia N95 Samsung i560 iPhone Android Bolt (E71) Iris (HTC) Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 HTC Touch Diamond Nokia E71 Basic DOM getElementById, createElement, createTextNode, appendChild Yes Yes Yes Yes Yes No Yes IE doesn’t support createTextNode . Basic innerHTML getElementById, innerHTML Yes Yes Yes Yes Yes Yes Yes Basic Ajax new XMLHttpRequest(), onload Yes Yes Yes Yes No Incom plete Incom plete No Yes Blackberry and NetFront/SEC510 need readystatechange event

IE needs readystatechange event and new ActiveXObject("Microsoft.XMLHTTP") Medium-complex DOM test Does the browser handle the sortable table? Yes Almost Yes Yes Yes Buggy No Static Almost No Yes Opera has some problems. In the end it handles the re-sort, but the re-sorted table is slow to appear, and the TDs I hide flicker in and out of existence a few times. Some tweaking is clearly in order.

Oddly, the Opera 8.00 on Motorola works just fine; no problems.

Oddly, the Opera 8.00 on Motorola works just fine; no problems. Blackberry is very slow, too.

NetFront SE 510 doesn’t want to re-sort the table, although it handles the initial sort well. Might be caused by href="#" , when NF loads the same page as a new page. Nonetheless, I properly return false .

, when NF loads the same page as a new page. Nonetheless, I properly . NetFront Samsung F700 doesn’t support the dynamic colspanning of table cells, which gives a weird effect. It shows and sorts the table correctly, though. Medium-complex DOM test Does the browser handle the Edit Text script? Yes No Yes No Yes No Yes No Yes Yes No Yes Remember that a browser may fail this test because it doesn’t allow you to click on a random element. Medium-complex DOM test Does the browser handle the getElements ByTagNames script? Yes Incor rect Yes Incom plete Yes Yes Incom plete Incom plete No Yes Incomplete: browser supports neither compareDocumentPosition nor sourceIndex

Opera HTC leaves out everything beyond the third element, it seems. Medium-complex DOM test Does the browser handle the Usable Forms script? Yes No Yes Yes Yes No Yes Almost No Yes Blackberry doesn’t do the select test. Maybe problems with change event? Event (VF WM) Nokia E66 (9.5) HTC Touch Diamond (8.65) SE P1i (8.00) Motorola V3xx Nokia E71 Nokia E66 Nokia E71 Nokia N95 Samsung i560 iPhone Android Bolt (E71) Iris (HTC) Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 HTC Touch Diamond Nokia E71 Opera Mobile Opera Mini 4.2 S60 WebKit Apple WebKit Other WebKit NetFront Blackberry IE Mobile Skyfire

Basic font CSS

Retest to make sure that there’s a difference between text-transform: uppercase and font-variant: small-caps .

Event Opera Mobile mobile mode Opera Mobile desktop mode Opera Mini 4.2 S60 WebKit Apple WebKit Other WebKit NetFront Blackberry IE Skyfire Nokia E66 HTC Touch Diamond SE P1i (Op 8.65) Motorola V3xx Nokia E66 HTC Touch Diamond SE P1i (Op 8.65) Motorola V3xx Nokia E71 Nokia E66 Nokia E71 Nokia N95 Samsung i560 iPhone Android Bolt (E71) Iris (HTC) Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 HTC Touch Diamond Nokia E71 font-weight: 700 Yes Yes No No Yes N/A Yes Yes No Yes Yes Yes Yes Yes font-style: italic Yes Yes No Yes N/A No Yes No Yes Yes Yes Yes Yes text-decoration: underline Yes Yes No Yes N/A Yes Yes Yes Yes Yes Yes Yes font-variant: small-caps Yes No Yes N/A Yes Incor rect Yes No Yes No Yes Yes Yes Incorrect: browser treats small-caps as uppercase. color: blue Yes Yes N/A Yes Yes Yes Yes Yes Yes Yes letter-spacing: 0.3em Yes No Yes N/A No No Yes No Yes No Yes No Yes No Yes word-spacing: 1em Yes No Yes N/A Yes No Yes No Yes No Yes No Yes text-transform: uppercase Yes Yes No Yes N/A Yes Yes Yes No Yes Yes Yes font-size: 150% Yes No Yes N/A Yes Yes No Yes Yes Yes Yes No

Focus, blur, scroll

Nokia fires blur when cursor moves out of area of currently focused element. Not entirely compatible with desktop.

Event Opera Mobile Opera Mini 4.2 S60 WebKit Apple WebKit Other WebKit NetFront Blackberry IE Mobile Skyfire (VF WM) Nokia E66 (9.5) HTC Touch Diamond (8.65) SE P1i (8.00) Motorola V3xx Nokia E71 Nokia E66 Nokia E71 Nokia N95 Samsung i560 iPhone Android Bolt (E71) Iris (HTC) Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 HTC Touch Diamond Nokia E71 focus and blur on links Alter native Yes No Yes No Yes No Yes Buggy No Yes No Yes to be tested Buggy Opera Widget Manager interprets a mouseover as a focus and a mouseout as a blur.

Bolt only executes the first focus test you do; afterwards it doesn’t do the tests, doesn’t allow you to fill in text in the form field, and a Back hangs at 20% loaded.

Bubbles in Skyfire focus and blur on form fields Alter native Yes No Yes Incom plete Yes Buggy Incom plete Yes Incom plete Yes to be tested Buggy Blackberry, iPhone, Iris only text fields.

Bubbles in Skyfire, except on text fields. focus and blur on other focusable elements Alter native No No No Yes No No Yes to be tested Buggy Bubbles in Skyfire scroll Yes No Yes No No Yes No Yes No No Yes to be tested Yes

Touch action

This series of tests checks the availability and firing order of the mouseover, mouseout, mousemove, mousedown, mouseup, and click events, as well as CSS :hover . Not all mouse events mean anything in a mobile context, so it’s interesting to see when the various mobile browser vendors have decided to fire these events.

We have to distinguish here between touch phones, cursor phones, and four-way navigation phones. Cursor phones are mostly S60 ones, while touch phones can be subdivided in Blackberry on the one hand, where the user can click the screen in addition to touching it, and all other touch phones, where a touch equals a click.

First we’ll take a look at whether the events are supported at all, while the last few rows of this table show when and in which order the browsers fire the events.

Test page.

Event Opera Mobile Opera Mini 4.2 S60 WebKit Apple WebKit Other WebKit NetFront Blackberry IE Mobile Skyfire (VF WM) Nokia E66 (9.5) HTC Touch Diamond (8.65) SE P1i (8.00) Motorola V3xx Nokia E71 Nokia E66 Nokia E71 Nokia N95 Samsung i560 iPhone Android Bolt (E71) Iris (HTC) Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 HTC Touch Diamond Nokia E71 mouseover Too many Yes Incor rect Yes Too many Yes No Yes No Yes No Untest able Incor rect Does the browser support the event at all? mouseout Too many Yes No Yes Minimal Yes Too many Yes No Incom plete No Yes No Untest able Incor rect Does the browser support the event at all? mousemove Yes Incor rect Yes Yes No Yes No Yes No Untest able Incor rect Does the browser support the event at all? mousedown Yes No Incor rect Yes Yes No Yes Yes No Yes Yes Untest able Yes Does the browser support the event at all? mouseup Yes No Incor rect Yes Yes No Yes Yes No Yes Yes Untest able Yes Does the browser support the event at all? click Yes Incor rect Yes Yes No Yes No Yes Yes Untest able Yes Does the browser support the event at all? :hover Incom plete Yes No Yes Yes Yes No Yes No Yes Untest able Incor rect Does the browser support the event at all? Event Opera Mobile Opera Mini 4.2 S60 WebKit Apple WebKit Other WebKit NetFront Blackberry IE Mobile Skyfire (VF WM) Nokia E66 (9.5) HTC Touch Diamond (8.65) SE P1i (8.00) Motorola V3xx Nokia E71 Nokia E66 Nokia E71 Nokia N95 Samsung i560 iPhone Android Bolt (E71) Iris (HTC) Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 HTC Touch Diamond Nokia E71

iPhone

The iPhone fires a mouseover and :hover when the user first touches the element. It fires a mouseout and removes the :hover when the user touches another element. Essentially, the element retains the focus until another element is touched, and mouseover/out and :hover are tied to this focus exclusively.

On every touch touchstart, touchend, mousemove, mousedown, mouseup, and click fire.

If you touch the element and keep your finger there, only touchstart fires.

If the user drags his finger across the element, only the touch events fire.

Opera Mobile HTC (touch)

Opera Mobile on HTC does the same as the iPhone, except that

it doesn’t support the touch events

mousemove is fired before mouseover

Android

Android does the same as the iPhone, though it also fires focus and blur events before and after the mousemove.

Opera Mobile Motorola (4-way)

Opera Mobile 8.00 on Motorola V3xx behaves quite differently. This is predictable; the Motorola has a four-way navigation (i.e. you use the arrow keys to navigate, and no cursor is shown.

When you focus on the test element, the focus, mousemove and mouseover events fire.

When you click on the test element, the click event fires. Mousedown and mouseup are absent.

When you go to the other element, the blur and mouseout events fire on the test element.

Opera Mobile SonyEricsson

Touchscreen. When you click on the test element, mouseover, mousedown, mousemove, mouseup, click fire. Sometimes it inserts many more mousemoves between mouseover and mousedown, or between mousedown and mouseup. Mouseout is lacking completely.

I managed to focus on the test element once, but it was by accident and I don’t know how to repeat that test.

Dragging your finger across the element gives a mouseover and one or more mousemove events. Again, mouseout is lacking.

Opera Mobile Widget Manager

If the cursor goes over the element, everything works correctly.

On a click, however, the test element loses its focus and the :hover styles. Mousedown, mouseup and click fire correctly.

When you click for the second time, the element regains focus for a moment, and the mouseover and mousemove events fire before the mousedown, mouseup and click. However, the expected mouseout event does not fire.

S60 WebKit non-touchscreen

S60 WebKit on non-touchscreen phones supports all events exactly as a desktop computer does. It has a cursor, after all.

The only slight oddity is that it also fires mouseover and -out events when you move the cursor over the text. This probably has to do with the ancient WebKit bug that makes the target of the event the text node, and not the element node. This behaviour does NOT occur on the Nokia E66.

S60 WebKit touchscreen

Tested on Nokia 5800, the S60 WebKit touchscreen is weird. The first touch on the element causes mouseover and mousemove, and applies the :hover styles. The second touch causes mousemove, mousedown, mouseup and click. That means you have to touch an element twice in order to fire a click event.

Touching the other element correctly fires a mouseout and removes the :hover styles.

NetFront

NetFront (on SE C510, which has a cursor) behaves exactly as a desktop computer does, except that it does not apply the :hover styles.

NetFront 3.3 on SE K770i, which has 4-way navigation, does not do anything at all.

NetFront 3.4 on Samsung F700 (touch screen) supports only mousedown and mouseup.

Blackberry

The Blackberry applies :hover when you touch the element.

When you click on the element by depressing the screen, mousedown, mouseup and click are fired.

Opera Mini

Opera Mini Nokia E71 does not have a cursor.

On the first click Opera Mini only applies the :hover styles.

On the second click Opera Mini fires the mousemove, mouseover, mousedown, mouseup and click events.

On the third and subsequent clicks Opera Mini fires only the mousedown, mouseup and click events.

On the first click on the other element Opera Mini removes the :hover styles and fires mousedown, mouseup and click.

On the second click on the other element Opera Mini fires mousemove, mouseover and mouseout on the first element. (The first element automatically gains the focus, so this is sort of defendable.)

Iris

When moving your finger over the element, the mouseover, mousemove and mouseout events fire.

When you touch the element, the :hover style is applied, and mouseover, mousedown, mousemove, mouseup and click fire. There’s no way of firing the mouseout event with only a touch action; it needs a move action.

Bolt

Bolt does nothing at all.

Skyfire

Skyfire does not react when you move the cursor over the element. To me this is a bug; if a cursor is available the browser should fire the correct events when the cursor hovers over the test element.

When you click, it applies the :hover styles and fires mouseover, mousemove, mousedown, mouseup and click. When you click it again, the same happens except for mouseover.

When, after the first click on the element, you move the mouse away, then back, and click the test element again, the :hover styles are removed, the mouseover event does not fire, but the mouseout event does (between mousedown and mouseup). I think this behaviour is a bug: Skyfire may think you click on another element and fire the correct events, then notices you click on the test element and fires those events. (But I’m guessing here.)

When you click on the other element, the :hover style is removed and the mouseout event fires.

orientationchange, screen width and height

Some devices don’t support orientationchange, obviously. Some browsers don’t support it while their device does (IE Mobile). “No” in the table below means: device supports orientation change, but browser doesn’t fire event.

Event Opera Mobile Opera Mini 4.2 S60 WebKit Apple WebKit Other WebKit NetFront Blackberry IE Mobile Skyfire (VF WM) Nokia E66 (9.5) HTC Touch Diamond (8.65) SE P1i (8.00) Motorola V3xx Nokia E71 Nokia E66 Nokia E71 Nokia N95 Samsung i560 iPhone Android Bolt (E71) Iris (HTC) Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 HTC Touch Diamond Nokia E71 orientation change No Untest able No Untest able No Yes No Untest able No No Untest able No Almost to be tested to be tested Blackberry fires the event on the document. resize Yes No Untest able Too many Untest able Too many Almost Yes Untest able Yes No Untest able No No to be tested to be tested Webkit/NokiaE66 and Samsung i560 fire many resize events instead of just the one.

iPhone fires a resize event just after the orientation change, as well as during.

Opera/Nokia fires resize on both window and document. screen.width and screen.height 240 x 320 240 x 228 240 x 320 240 x 239 314 x 196 320 x 240 320 x 396 480 x 320 800 x 800 640 x 480 see below 176 x 220 320 x 240 480 x 360 to be tested to be tested iPhone always reports width=320 height=396 regardless of orientation.

Opera/HTC dimensions are when the toolbars and stuff take up real estate. Haven’t been able to test resolution without toolbars yet.

Yes, Opera Mini reports a screen height of five thousand.

Samsung F700: 377 x 183 in landscape or 240 x 328 in portrait

Closure memory

I did one of Jake Archibald’s closure memory tests, the second one (“noExternalReference”). Results:

iPhone 2.2: Holds out well. Freezes for a few seconds when scrolling to the left or right edge of the screen; freezes for a few seconds when tapping the Tab button, but otherwise no problems.

Opera Mobile 9 on WinMob 6.5 and WinMob 6: Holds out well. Maybe a tad slower than normal, but still quite acceptable.

S60v3 on Nokia E71 and S60v5 on Nokia N97: Near-omplete hang. Opens window for user interaction only once every 10 seconds or so. (S60v5 even slower than S60v3.)

Android G2: Gets somewhat slower, but holds out well otherwise.

Ozone on Nokia E71: Same as S60.

Acid 3

Did the Acid 3 test in a few browsers:

Iris: 100

Opera 9.6: 98

Android G2: 93

Ozone: 93

iPhone 2.2: 74 (I’ve heard 3.0 makes it to about 97)

Opera Mobile 9.5 Win Mobile 6.5: 59

Opera Mobile 9.51 Win Mobile 6.1: 76

Blackberry: 14

IE 6.5 Windows Mobile: 5 (yes, five)

S60v3 WebKit on Nokia E71 and S60v5 WebKit on Nokie 5800: total fail; doesn’t execute test

Key events

I really should separate key events on the document and on a form field. Postponed.

Event Opera Mobile Opera Mini WebKit NetFront Blackberry Nokia E66 HTC Touch Diamond SE P1i (Op 8.65) Motorola V3xx Sony Ericsson K770i Motorola V3xx Nokia E66 Nokia E71 iPhone Android Samsung F700 Sony Ericsson K770i Sony Ericsson C510 Blackberry 9500 keydown to be tested Incom plete + special Yes No Yes Minimal Yes Minimal Incom plete In mobile mode, Opera on HTC Touch Diamond fires this event only on non-character keys. In desktop mode it always fires the event.

NetFront Minimal: only on special keys (and not even always in that case). keypress to be tested Yes No Yes No Yes Incom plete keyup to be tested Incom plete Yes No Yes Minimal Yes Minimal Yes Opera on HTC Touch Diamond fires this event only on non-character keys. keyCode to be tested Yes Minimal Untest able Minimal Yes Yes Minimal Yes Op/Mot gives special meaning to key presses. charCode to be tested No Untest able Minimal Yes press No Yes press Minimal No keyIdentifier to be tested No Untest able Minimal Yes down/up No Yes which to be tested Yes Minimal Untest able Minimal Yes Yes No Minimal No

Key codes - numerical keyboard

On all tested phones with numerical keyboards, the number keys 0 to 9 have keyCode 48 to 57. The backspace key has keyCode 8.

Unfortunately the * and # keys are more complicated. In notation */#:

onkeydown and onkeyup Nokia and Samsung report a keyCode of 56/51 and a charCode of 42/35.

of 56/51 and a of 42/35. onkeydown and onkeyup Sony Ericsson reports a keyCode of 83/72, and the charCode is not available.

of 83/72, and the is not available. onkeypress Nokia, Samsung and Sony Ericsson report both as 42/35.

Note that the first Nokia/Samsung values are equal to those of the 2 and 8 keys.

Key events/codes and form fields

Key events and codes are downright weird when you try to read them from a form field. Part of the reason is that many phones with numerical keyboards pop up a special dialogue screen where you can enter your text. This plays havoc with the events. (And part, I suspect, is just the old-fashioned let’s-make-things-complicated-for-web-developers mindset.)

In general I advise you not to use key events on form fields at all. Instead, read out the form field’s value.

Test ideas