I'm writing a CSS book

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

sitemapcontact

Testing BlackBerry WebKit, or how I encountered a browser tester’s worst nightmare

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.)

Last week I received a BlackBerry Torch (9800) which runs the brand-new and long-expected BlackBerry WebKit browser. I put it through all the motions, but quickly found out that the touchmove event didn’t work as expected. In my test page it fired only once, but the scrolling layer example worked fine, even though it depends on an continuous stream of touchmove events.

Fortunately the browser people at RIM are very helpful. When I sent out a plea for help I got an extremely useful reply within hours: BlackBerry WebKit fires only one touchmove event if the event’s default (scrolling the page) is not prevented.

I hurriedly added a return false and lo and behold: the generic test script reported dozens of touchmove events. In addition, it did not report any mouse events any more.

When I did the new test in other browsers it turned out that some of them, too, suppressed mouse events. I’m certain about the iPhone, and I’ve seen the behaviour elsewhere, too. However, I need to fully describe all browsers’ behaviour both with and without default prevention. Hence the need for re-tests.

That means that my BlackBerry WebKit report will be delayed: I don’t have all the data available yet. Suffice it to say for now that it’s an excellent browser, supporting every single mobile feature I currently test for.

BlackBerry WebKit scores perfectly in the viewport tests, with the single exception of screenX/Y event coordinates. That’s enough to put it in the top spot in this series of tests, relegating the iPhone (3.1) to place #2 and Symbian WebKit to #3.

In addition the browser has good documentation; and that’s something the other browser vendors can learn from.

BB WebKit’s performance can still use some work; it’s slightly slower than the other top browsers when it comes to dragging layers, repainting the page after a zoom, and similar processor-intensive jobs. I assume RIM is aware of these problems and is working on them.

Incidentally, performance is the reason BB WebKit is so strict in not firing more than one touchmove event without default prevention. It turns out that a natural touchmove action (dragging your finger across the screen) not only scrolls the page, but also any iframe or div with overflow: auto in the page. Other browsers have not implemented this universal scrolling; probably because of performance worries.

In any case, BB WebKit deliberately restricts the number of touchmove events if the web developer doesn’t clearly state it wants to take over the interface by returning false to suppress natural scrolling. If the browser had to handle a lot of touchmove events in addition to natural scrolling it would become too slow.

That’s understandable, and it’s possible that other browsers do something similar. None of them restrict the touchmove events to only one, but it may be they fire more touchmove events when the default is prevented. That’s one of the things I have to test.

Anyway, I made a mistake, and now I have to pay for it by retesting the event cascade in all browsers. Such is a browser tester’s life.

Comments

Comments are closed.