I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

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.

Comments

Comments are closed.