Testing mobile browsers — more problems

Since my previous post about mobile browser testing I’ve had four days in Düsseldorf to play with mobile phones, and I’ve once again unearthed quite a few problems that mobile browser testers will encounter. So this post is mostly about how the situation is even more complicated than we thought.

You can look over my shoulder while I’m testing, as far as I’m concerned, as long as you remember that every bit of data is provisional and may change radically without warning.

If you’re interested in real-time raw test results, follow me on Twitter. I regularly post my findings there, and it’s already delivered me some excellent feedback.

In this entry we’ll look at first-line and second-line browsers, mobile support for basic CSS, Opera’s two modes, the failure of @media handheld, Vodafone “content adaptation,” the Nokia keyCode problem, and we’ll close off with a few fun browser facts.

The crucial question of the moment is: who asserts supreme control over the way a website looks on a mobile phone? Currently I’m arguing the author should, but Opera and Vodafone assert vendor control, with Opera also giving the user a modicum of control.

I’d like to thank Opera for its consistent openness and willingness to answer questions. In this entry I’ll criticise Opera Mobile for its two modes and its handling of @media handheld, which effectively reduce author control over websites.

However, one of the reasons I’ve been able to gather enough data to form these opinions is the very fact that Opera has been willing to answer my questions. Double-edged sword, anyone?

Currently I’m not in touch with any other mobile browser team, by the way — that’s on my To Do list. (If anyone from a mobile browser team reads this, please get in touch with me.)

Which browsers to test

Although Opera understandably wants a report on the latest versions of Mobile and Mini, I haven’t yet encountered them in the wild, and am testing mostly in older versions.

The point here is that these older versions are what people actually use.

Desktop Opera users are very good at upgrading their browser when a new version is released. Mobile Opera users, however, won’t do it.

Nobody is willing to download a huge amount of software (charges may apply; just ask your carrier) because a company they’ve never heard of released a new version of a product they can’t quite place.

Therefore I’m going to strictly base my tests on current phones and accept that they use older browser versions. There’s no point in testing stuff that isn’t yet out in the wild.

I will eventually choose a test phone and install several browsers on it — both to see how a mobile browser install works and to be able to test cutting edge and niche browsers. Nonetheless, these tests will be less important than the ones on default browsers.

First-line and second-line browsers

More in general, I want to start dividing the mobile browsers into first-line and second-line ones, and concentrate my tests on the first line.

First-line browsers are default browsers on any reasonably well-used device; second-line ones are the ones that must be downloaded by the user. Since few users will bother, second-line browsers will always remain something of a niche group.

New browser versions start their life as second-line browsers. They will only be upgraded to first-line once they are the default browser on some new phone types.

Basic support

One of my most shocking findings last week was that mobile testing should encompass the real basics of CSS such as font-style: italic.

When I did my Advanced [attr] selectors tests in Opera 8.00 on the Motorola, a quick glance at the page told me that it didn’t support them; which I thought odd, because Opera has been supporting this basic CSS3 stuff for ages.

It turned out that this Opera didn’t support font-style: italic, font-weight: bold, and text-decoration: underline. The test page uses them as test styles, but if a browser doesn’t support them the test-at-a-glance misfires horribly.

So I had to backtrack and write a simple basic font CSS test that tries to ascertain support for the above-mentioned declarations, as well as color: blue, text-transform: uppercase and a few other declarations.

It turned out that the only browsers to support basic font CSS fully were two out of four tested Operas (but only in desktop mode; see below), the iPhone, the Android, and the Blackberry. All other browsers didn’t support some of these basic styles, with Opera on Motorola scoring by far the worst: only color: blue supported.

The Opera modes

I discovered that Opera Mobile has two “modes:” desktop mode and mobile mode. The difference seems to be that in desktop mode a site is shown exactly as it would on a desktop computer, while in mobile mode the site is accomodated to the narrow screen of the average mobile phone.

Wow. If you think IE modes are bad, take a look at the differences between these Opera Mobile modes. (Not entirely a fair comparison, but still.)

I’m going to postpone a detailed treatment until I’ve done some more testing; for the moment it’s sufficient to say that Opera in mobile mode doesn’t support font-size, letter-spacing and word-spacing. I suspect width declarations may be overruled (the whole point of this mode is to squeeze a site into a tiny screen, after all), and other than that I have no data.

If you know of any documentation of the two modes, please leave a link in a comment.

I sure hope the mode differences don’t extend to JavaScript. They shouldn’t — disabling a few crucial CSS properties should be enough to get the desired effect — but I always become extremely nervous when browser vendors start switching stuff on essentially arbitrary grounds, and I know from experience that assuming the worst is by far the safest course.

Handheld stylesheets

@media handheld, which is supposed to allow you to define special style rules for mobile devices, is supported only in mobile mode; and not in desktop mode. As far as I’m concerned Opera has made a mistake here: the device is a mobile phone, therefore @media handheld should be supported in both modes.

In the current situation Opera denies web developers the opportunity of optimising their sites for mobile phones, and it also denies there’s any difference between wide, spacious computer screens and narrow, cramped phone displays. I feel it’s wrong on both counts.

More in general, the handheld media type is useless right now. Apart from the Opera problems WebKit and Blackberry don’t support it, and only one out of three tested NetFronts does.

IE supports it, but it supports @media screen simultaneously. Although IE has been much reviled for this support, I think that in practice it’s not so bad. You can still use handheld stylesheets as an overrule for normal stylesheets, and that may be enough to help your mobile users.

Detecting the mode

Still, the comparison to the IE modes is not entirely fair. Opera has a point with its mobile mode: some sites are just impossible to view on a tiny screen, and for some users mobile mode will be a blessing.

Nonetheless, the two Opera modes are worse than the three IE modes in one respect: a web developer cannot set an Opera mode. Instead, the device user decides which mode he wants to use. Thus you’ll have to make sure it works in both modes — you’ll never know which mode a certain user is in.

There is no JavaScript property that tells you which mode is active, and as far as I’m concerned there should be one. Right now I “detect” the Opera mode by some CSS sleight of hand:

@media screen {
	p.opera:after {
		content: ' desktop mode.';
	}
}

@media handheld {
	p.opera:after {
		content: ' mobile mode.';
	}
}

<p class="opera">This Opera is in</p>

In the long run this test is likely to be insufficient; that’s why we need a JavaScript property. Besides, it misfires in Opera 8.00 on Motorola, which is clearly locked in mobile mode yet reports desktop mode. I suspect it doesn’t support @media handheld.

Default mode

Opera informed me that the desktop mode is supposed to be the default mode; users will have to go through their preferences in order to change the mode. I think few users will bother to do this, mostly because they don’t know the option is available.

In theory that sounds good, but there’s a catch.

Both mobile phone vendors and carriers have the opportunity to change these default settings, and changing stuff just because you can is popular in the mobile space because it expresses your power over other parts of the mobile value chain. Thus it’s quite likely that some installs will default to mobile mode regardless of Opera’s plans.

Unfortunately I cannot test the default mode of any phone. The phones I use are for testing purposes, and their settings are changed on a regular basis. I myself did so quite a few times, and I’m afraid I can’t remember whether the phones were in desktop or mobile mode when I first tested them. I didn’t yet know this detail would be important. Besides, even if I did remember, chances are some other developer switched modes at some time in the past.

So even if you detect an Opera Mobile you will have no idea in which mode it runs and no opportunity to switch modes. That’s the kind of vagueness I loathe because it makes my job much more difficult.

Who’s in control?

Basically I’m arguing in favour of total author control over the way a mobile web site looks. In theory Opera gives the user some control (which in theory ought to be good), but it also asserts vendor control by setting the default and making it impossible for authors to switch modes or even figure out what’s going on.

For the moment I’ll stick to my full-author-control viewpoint and see where it leads. I might change my mind, though.

Content adaptation

Vodafone, too, asserts vendor control — with a vengeance.

In my last entry I wrote about Opera Mini 2, and how one of the two tested versions identified itself as NetFront on the server side, but as Opera on the client side. Besides, an Opera representative was surprised that there wasn’t a more modern version installed; Opera Mini 5 will be released within a few months (I think), and version 4 has been up and running for quite a while now.

Almost by accident I found the solution to this riddle when a Vodafone employee told me about the dreaded “content adaptation.” It turns out that Vodafone may decide in its infinite wisdom that your phone is crappy and you need some help.

If that happens it automatically relays your web traffic through an Opera Mini 2 it has apparently installed on your phone as firmware. (This Opera Mini might in turn plug into the system-native browser; hence the server side NetFront identification).

Fortunately this is a SIM card setting; once I switched it off on one phone, the two Opera Minis disappeared and the underlying browsers (NetFront 3.4 and Opera Mobile 8.00) were allowed to take charge.

Like, wow. You can’t make this up. Nobody would believe you.

In theory content adaptation is similar to Opera’s desktop and mobile modes: it’s vendor control asserted in an attempt to help people with less able phones.

In practice it’s far worse because Vodafone doesn’t have the faintest idea what it’s doing. The two phones that adapted my content had a fine native browser that could handle websites decently. Vodafone’s intrusion was unnecessary.

And even if Vodafone (or Opera) pulled it off perfectly, I wonder if vendor control ought to be attempted at all.

A side effect is that I cannot test on Opera Mini at the moment. I’m going to resuscitate my old “Nokia 2 megapixels” and install Opera Mini 4 on it. Unfortunately the battery is dead; I’ll have to bring it to Vodafone to breathe new life into it. So Opera Mini tests will resume next week at the earliest.

The Nokia keyCode problem

In my previous entry I suggested that Nokia devices might not return the code of the keys the user pressed to the browser. This turns out to be incorrect.

What happens is that the keyCode is missing from the key events when the target is a form field. When I switched from form fields to doing tests directly on the document, proper keyCode appeared.

As a result, my current advice is not to read out key strokes in a form field, but instead check the form field’s value. That always returns the result of the users’ keystrokes (which might be performed on a numerical keyboard, where three key 50 presses equal one key 67 press on a qwerty keyboard).

In fact, this episode only confirmed that I still know very little about mobile phone testing, and that my simplistic view of its input modes was ... well ... too simplistic.

Some keyboard phones open special interfaces when the user wants to enter text in a form field. Right now my inconclusive testing suggests that JavaScript events are suppressed while the user interacts with this interface.

Maybe even on devices that do not show such an interface, keyCode still has no value as a kind of a relic from the days when they used to use a special interface. Of course I could be totally wrong here; I’m just guessing.

All this does not go for touch phones. They always show a keyboard when the user focuses on a form field, and they usually allow JavaScript events to fire while the user interacts with the keyboard, too.

Random browser facts

We’ll close off with some random browser facts I discovered.

Blackberry

The story I’ve heard says that Blackberry used to use its own browser, which was crappy, but that the new Blackberry Storm would switch to WebKit.

This story turns out to be untrue — so far. I tested the Blackberry 9500, and because the browser reported itself as Blackberry I assumed the 9500 was an older version. However, when I asked for a Blackberry Storm for new tests, I was told the 9500 was actually a Storm.

Then had I tested a WebKit in disguise? I was pleasantly surprised by the Blackberry’s CSS2 selector support (CSS3 selectors remain a bit sketchy), and I especially noticed that it didn’t have any dynamic issues in the + selector test; and this is something that both Opera and WebKit generally fail on. Besides, Blackberry does not support the load event on XMLHttpRequests, something WebKit does.

My well-honed instincts screamed at me that this browser is just not a WebKit. It’s a separate browser; a Blackberry browser.

So I feel that the rumour of Blackberry switching to WebKit is not (yet) correct. Right now I’m not even sure whether the switch would be necessary; the Blackberry browser is holding up surprisingly well in my tests.

Obigo

My mother’s new phone turns out to run the Obigo browser. Once created for the WAP system that never quite took off, its makers have apparently decided to enter the mobile web space and upgraded their browser considerably. I’ve only done a few quick CSS 2 selector tests; the browser holds out quite well. I will include it in my test program.

IE

IE Mobile is quite crappy; as nobody will be surprised to hear. It tries to show my site in desktop mode but fails miserably. The main text column is about ten characters wide.

Bug-wise I encountered a golden oldie: IE Mobile interprets pre + p as p. IE 5.0 used to do that, you’ll remember. It’s wonderful to be able to relive a few of my fondest browser wars memories (not).

Speaking of not, IE Mobile supports the :not selector. Say what? Isn’t that advanced CSS 3? Well, yes, but it’s going ahead and supporting it anyway. Fortunately this is the single CSS 3 selector IE Mobile supports.

Remember I’m talking about the old IE Mobile here. IE Mobile 6, when it’s released, will probably solve some of these problems, but it will also host lots of good old IE6 CSS bugs. It’s an IE6 branch, after all.

All in all there’s still a depressing amount of work to be done.

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?

Categories:

Comments

Comments are closed.

1 Posted by Anne van Kesteren on 16 March 2009 | Permalink

I just skimmed through the bit about CSS support. Are you sure the device actually supports the font faces the CSS is asking for? Lots of devices just support one or two font faces and might therefore not do bolding and such. That does not mean the CSS is actually unsupported though...

2 Posted by ppk on 16 March 2009 | Permalink

How do I test font face presence without CSS?

Besides, if the device doesn't support certain fonts, that, too, is something we ought to know.

But I agree we'll have to test it in another browser on the same device, just to be sure.

More work to do ...

3 Posted by Maarten on 16 March 2009 | Permalink

handheld is a mediatype not to be used when programming also for mobile. Better is to use user-agent checking and then giving it the correct stylesheet. At the moment i always work with one stylesheet for all types and then 4 special sheets for windowsmobile,blackberry(not supporting much styles),symbian and iphone overruling basic layout stuff. Personally i think this is the best way to do it (using screen for all default and exceptions for mobile specific; less recoding; friendly to maintain), because when i know it is the iphone i can set the meta viewport on the screensize he/she is watching it. So personally i like the way to first find out who is visiting and then do the actions. Can give you an example.

4 Posted by Doeke Zanstra on 17 March 2009 | Permalink

You could perform handheld detection in javascript, when combined with some CSS. See the following example:
http://www.xs4all.nl/~zanstra/void/handheld.html

A disadvantage is the DOM is littered. But that can be cleaned up afterwards...

5 Posted by Artemy Tregubenko on 17 March 2009 | Permalink

> Desktop Opera users are very good at upgrading their browser when a new version is released. Mobile Opera users, however, won’t do it.

Once I was browsing with a bit outdated version of Opera Mini, and it was showing notifications about new version on every page displayed. I'm not sure how it was done (proxy-side, probably) and whether Opera Software wants to stick to this solution, but global upgrading is definitely possible.

6 Posted by Robert Sherby on 18 March 2009 | Permalink

> Better is to use user-agent checking and then giving it the correct stylesheet.

This sounds very much like a step backward to the bad old days of desktop web development. Then, as there appears to be now, there was certainly a practical incentive to do this kind of thing. But it is no less a kludge now than it was then, and I shudder at the idea of reviving the practice.

Of course, the onus is on browser vendors to standardize behavior before too many developers are forced down the browser detection path.

7 Posted by Alberto on 18 March 2009 | Permalink

My guess is that content adaptation is NOT done on the mobile device, but by a transparent proxy between the device and the web server. The proxy being transparent it probably won't touch the User-Agent header, hence the NetFront identification. The proxy (or the operator) might well add other headers to the request, that you could use to identify it as such (same for Opera Mini), therefore I suggest you also look at the HTTP headers in your tests. Some valuable information might be hidden there.

The content adaptation scheme seems like a big mess, but it was originally meant to overcome the limitations of the early mobile browsers and devices. Newer devices have made the technology obsolete, but a lot of legacy phones still remain in the wild, so mobile operators struggle to find a good way to cater to both audiences.

8 Posted by Gregj on 18 March 2009 | Permalink

I'd urge developers to accept some element of user configurability. For my own situation, I'm always using a phone one-handed, so horizontal scrolling is not really practical, especially as the sites I access are text-based. So in Opera 8 on the Motorola Z10, I have Fit To Screen selected because for me that's more important than preserving the intended layout. Plus with the onset of middle age, presbyopia creeps in and ensures I can no longer read comfortably a typeface that would be OK for someone 20 years younger. As my one essential page is the BBC news page at http://news.bbc.co.uk/nolpda/ukfs_news/hi/default.stm? which seems to default to a small typeface, I'm running the Zoom level at 140% which gives a comfortable size on that site, without being grotesquely oversize elsewhere on the web. That bit of user customisation makes the difference between using and not using the mobile web for me, so I hope the option for an element of user reformatting remains.

9 Posted by Gregj on 18 March 2009 | Permalink

Sorry, typo in my previous comment, meant to say "Motorola Z10" not Z9 - very different. I think that means the browser is Opera 8.65 for Symbian, in case the comment made no sense on other platforms.

10 Posted by ppk on 19 March 2009 | Permalink

Gregj,

I definitely want to allow you to view the site on a narrow screen. In fact, what I want is to be able to narrow down wide web sites on mobile devices; not widen them and force you to scroll horizontally.

Right now Opera desktop mode gives you problems; I hope to be able to solve some of these problems for you. But in order to do that, Opera Mobile desktop mode needs to support @media handheld.

11 Posted by ppk on 19 March 2009 | Permalink

Alberto,

It seems you are right. I don't have all the details yet, but it probably didn't involve a local Opera Mini install.

As to content adaptation, if you want to use such a scheme, maintain it. Else it's worse than useless.

12 Posted by David on 21 March 2009 | Permalink

Opera don't seem to want to give out much info about these rendering modes. I found a couple of page, one which has a list that lists a number of features of the different modes, which looks like it could be useful:

http://dev.opera.com/articles/view/differences-between-opera-mini-3-and-4/

CTRL + F: Opera Mini 4 has two rendering modes

http://dev.opera.com/articles/view/evolving-the-internet-on-your-phone-des/

CTRL + F: When in desktop rendering mode

Also found this on using @media:

http://dev.opera.com/articles/view/how-to-serve-the-right-content-to-mobile/

Although, there are people in the forum saying the same as you - that it doesn't work properly.

Can't use use US strings or are you trying to avoid such JS mess? :)

13 Posted by slxception on 24 March 2009 | Permalink

Sorry that I said this in your other post, but iPhone does support specific CSS directed to it. Using the media type:

"only screen and (max-device-width: 480px)"

in either tags or @-rules. I guess the logic is that you could connect it to a TV.

However, I think it sounds sad, but using the dreaded browser sniffing via UA is the better solution right now. Shame because it's the total opposite of the browser wars.

14 Posted by Andrew Hedges on 28 April 2009 | Permalink

Back to Anne van Kesteren's 1st comment, I can confirm that Webkit/Skia on the Android simulator (and, I assume the G1 and G2) only support the 2 system fonts, even when other compatible fonts are installed on the device. Don't know if that's a helpful lead or not.

May I speak for the whole mobile web community when I thank you for your hard work and transparency in ferreting out the mobile browser compatibility landscape!