I'm writing a CSS book

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

contact

New kid on the browser block: Samsung Dolfin

Back in early June I got a Samsung Wave that runs the brand-new bada OS and did some brief tests of the native Dolfin browser. In the past few days I’ve done some more extensive testing, and the verdict is in: good browser, well on the way to becoming excellent.

(Oh, and Dolfin ought not to be confused with Dolphin, which is a skin for Android WebKit.)

It’s Samsung’s philosophy that it will not compete in a market unless it belongs to the top three of that market. In the case of the mobile browsing market Samsung has succeeded: from nothing, Dolfin has become the third-best mobile browser in the world. Only iPhone and Android are better.

If you’re keeping track of the mobile browser landscape you should add Dolfin to your A-list. It’s easily good enough, and Samsung has big plans with the bada operating system. Somewhere in 2011 the installed base of Dolfin will pass that of Safari iPhone, and bada might even become a competitor to Android. (Samsung sure hopes so.)

I have updated my mobile pages with Dolfin data. (By the way, I also tested Android 2.2 while I was at it: few changes. There’s not a single difference with 2.1 in my great WebKit table.)

The good parts

Dolfin is only the third browser in the world to support the touch events, after iPhone and Android, and that’s a large part of the reason I count it as the third-best mobile browser.

Mobile browsers for touchscreen phones just must support these events by the end of the year, or they’re out of the race. (Opera, Firefox, Microsoft, NetFront, Nokia, BlackBerry, you have been warned.)

Dolfin’s implementation is even slightly better than Android’s. If I do a pinch-zoom test on my touch test page I use two fingers, and during replay I want the browser to show the position of both fingers. iPhone does so, Android doesn’t. Now Dolfin also shows both fingers’ position.

Unfortunately Dolfin is not quite up to iPhone quality: my multitouch drag-and-drop does not work. Still, the stuff it does support is quite impressive for a browser that didn’t exist at the start of this year.

Dolfin’s responsiveness to pinch-zooming is good. One friend who’s used to the iPhone even said it’s better than Apple’s implementation. I’m not quite prepared to go that far yet, but it easily gives Android a run for its money.

Dolfin incorporates a very modern WebKit version, and in my great WebKit table it is the best mobile browser, narrowly above Android 2.1/2.2 and comfortably above the iPhone 3.1 (4 not yet tested).

I’m currently working on a little side project: the perfect scrolling layer script for touchscreens. Obviously it should work in all three browsers that support the touch events. Of the three Android gives me the biggest problems right now, with Dolfin smoothly sailing along in the wake of the iPhone without any serious problems.

Dolfin is just a bloody good browser.

The buggy parts

Still, not all is rosy. I found a few bugs in Dolfin, and I’ll enumerate them here for the benefit of the Samsung team:

• The viewport dimension properties are an absolute mess. Not only do they generally give wrong data, but a few of them change meaning when a <meta viewport> is present in the page. This must be addressed as soon as possible; it’s a show-stopper.
• There’s a bug in the touchstart event. When you assign an event handler to it and execute it once, the event handler is removed. See this test page for the effect. Works fine on iPhone and Android, but fails in Dolfin the second time you want to drag the item.
  The workaround, obviously, is setting the touchstart event handler again ontouchend. That works fine.
• Dolfin is over-eager in firing the scroll and contextmenu events. Basically they always fire, even if an action does not result in a scroll or a contextmenu. (In fact, I haven’t yet discovered any contextmenu on Dolfin.)
  These events should only fire if the scroll or contextmenu action actually take place.
• The event coordinates are wrong: clientX/Y and screenX/Y copy the values of pageX/Y, while they should report the coordinates relative to the visual viewport in CSS pixels and in device pixels, respectively.
• A personal peeve: on the browser software keyboard the “Go” button is located on the left. A standard is emerging whereby it’s the right button that says “OK, do it,” while the left button says “Never mind.” I got confused by Samsung’s button placement more than once.
• Samsung bada is supposed to support W3C Widgets, but there is no way for developers to upload test widgets to the phone. In practice that means nobody will test on Samsung bada. This situation must be rectified.

Still, such bugs are only to be expected from a first release. In general Samsung has delivered a good browser that’s only a few small steps away from becoming excellent. I will follow Samsung’s next moves with interest.

Comments

Comments are closed.