Yesterday I was visited by a browser tester’s worst nightmare: when testing BlackBerry WebKit I found I made a mistake in my touch event research. I have to re-do all these tests in all browsers because my current results don’t take one variable into account.
That variable is preventing the event default. While writing my test page I left out the return false at the end of the test event handler, simply because I didn’t think of including it. The test results seemed fine, so I didn’t notice the mistake for months and months. (Meanwhile I added a setting for preventing the default.)
continue reading
I have made a list of the fifteen mobile browsers I currently test. This will give you some insight in the current mobile browser market, which is volatile, complicated, and sometimes shrouded in mystery.
One of the commonest questions I get is “Which mobile browsers should I test?” The hidden question here is which devices you should own. It’s time to attempt an answer.
continue reading
After seven months of mobile testing (as well as a wealth of inventive invective aimed at mobile devices) I think it’s time to share some of my experiences with others who are inclined to violent self-punishment.
Welcome to my world! Bring your whip, bring a first-aid kit, and let’s have some fun punishing ourselves.
Today we’ll discuss the process of testing mobile browsers. We will not talk about the test results or their interpretation, we’ll leave that gorefest for another time.
continue reading
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.
continue reading
About a month ago the software department
of Vodafone Internet Services, based in Düsseldorf, Germany, asked for my help in creating
mobile widgets according to the W3C
Widgets specification. In particular, they’d noticed there are differences between
browsers even on mobile phones (imagine my surprise), and decided they needed advice from
a specialist (that would be me).
Better still, it quickly turned out that they were willing to pay me for doing
serious mobile browser compatibility tests and publishing them on this site.
The payment thingy is quite unusual, I can tell you (though not entirely unique).
This is easily the best job offer I’ve gotten in my entire freelance career, so I hurried to
accept it. Meanwhile I’ve done mobile tests for five days; enough to offer some
guidance for setting up a doctrine for mobile browser testing.
As far as I’m concerned you can look over my
shoulder while I’m working, but please PLEASE remember that everything I say
may change radically without notice after I’ve tested the same browsers on other devices.
Right now I’ve only done a few tests of functionality that’s basic to the
mobile experience, and even these basic tests will likely have to be expanded.
Besides, right now getting a general feeling for mobile testing and its manifold problems
is more important than running lots and lots of tests.
continue reading