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.

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 Alex on 3 September 2010 | Permalink

Sorry to hear you need to do so much extra work, but it's extremely fascinating nonetheless.

2 Posted by Tanny O'Haley on 4 September 2010 | Permalink

Glad you found the solution. The webOS webkit browser supports scrolling for iframes and other elements with overflow: auto. Just tap the item and press the space bar. It's not best, but works when you need it. It's how I read long comments on this site.

3 Posted by cbsides on 4 September 2010 | Permalink

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

That's really interesting. I think I'll watch this BB Webkit closely!

4 Posted by Michael Hixson on 14 September 2010 | Permalink

@cbsides: That is interesting. It always seemed strange that iDevices did nothing - no scrolling, no scroll bar. (With some strange two-fingered motions I was never able to nail down, I could get those areas to scroll, sometimes.) You can write JavaScript to emulate this functionality, but I'm sure a native implementation would be far more efficient.

What I'm curious about is the behavior at the edges of the div overflow:auto. On the outer window, does BB Webkit have the same resistance / bouncing effect that's on iDevices? If it does, I wonder how website authors would specify what's in the "mystery area" beyond the edges of the scrollable content.