Is Opera 10.5 ready for the March 1 'choice screen?'

One of the more brilliant coups in the history of Web browsers, were it feasible, would be for Opera Software to seize Google's key argument -- that the best Web browser that European Windows users should switch to next month, is the fastest one -- and make it its own. Those users will get that opportunity starting March 1, when Microsoft's rollout of its browser "choice screen" through Windows Update, begins in earnest.

That's next Monday, however, and the acceleration of Opera's next-generation Web browser project from 10.2 Alpha 1 status in mid-December, to 10.5 "pre-alpha" status just 10 weeks ago to 10.5 Beta 2 status on Wednesday, is not making time go by any more slowly. As Betanews tests since December until now have revealed, test builds of Opera 10.5 provide an unbelievable 452% the performance of Opera's final 10.2 alpha daily build. With the ongoing replacement of Opera's JavaScript engine, Opera's engineers have made astonishing progress in a very short period of time.

But unless Opera truly plans to pawn off its rapidly advancing browser as a finished application in just a few days' time, like the crew of the Enterprise at the start of the first Star Trek movie, users switching from Internet Explorer 6 could find themselves in a wormhole. Betanews tests of the public build of 10.5 Beta 2 in Windows 7 show evidence of the kind of problems a tester encounters in an alpha or, at best, an early beta. Usually a build dubbed "Beta 2" looks and feels closer to a release candidate.

A heavily customized Opera 10.5 Beta 2 reveals little aesthetic 'splinters' that could be sanded down.

In fairness, I'll start by saying that Beta 2 was much more cooperative with us with regard to folding, stretching, and mutilating the browser frame, than Beta 1. I've always liked Opera's optional panels along the left side, for instance. The screenshot above shows what 10.5 looks like with the "Sand" skin applied (an attractive and unobtrusive tan shade), with "wrapping" turned on for the Tab bar (enabling multiple lines of tabs), with the left side panel selector engaged, and with the Personal bar (Opera's counterpart to Firefox's Bookmarks toolbar) moved to the bottom of the window.

One of the space-saving features in the 10.5 build is the elimination of the window's title bar. Since the title of the active window appears in the active tab anyway, there's a good argument that the title bar is redundant. However, for some peculiar reason, whenever the Personal bar is attached to the top frame of the window, the title bar returns, thereby extending the width consumed by the top of the frame. Move the Personal bar to the bottom, like in the screenshot above, and the title bar disappears again.

Though the 10.5 skin is quite innovative, there's a number of unfinished features about it that I call "splinters" -- little problematic visual elements that detract from the aesthetic flow of the program:

• When the Tab bar is set for "wrapping," thus enabling multiple rows of tabs, the width of each tab becomes fixed. As a result, you can end up with a lot of wasted space on the right side of the Tab bar.
• Also with wrapping turned on in the Tab bar, the Opera button (where the menu bar contents are absorbed) mysteriously floats to the bottom of the bar. It doesn't do this when thumbnails are turned on -- a feature that can consume as much, if not more, width.
• When the arrangement of the window is heavily customized, tabs tend to dovetail into open space. The currently active tab in a multi-line tab bar is one example, as is the floating Opera button. Also, the Panels selector on the lower status bar can dovetail to nothing if the Personal bar is scooted to the bottom.

Some users, especially longtime Opera fans, will say this is nitpicking. They're right. But that's what beta testing is. While experienced users have built up a tolerance for features that look wrong but aren't, novice users who see dovetails and unfinished borders will wonder if something's wrong -- more accurately, if they have done something wrong.

To drag or not to drag

In Betanews tests since Wednesday's release, we encountered a series of related, and perhaps obvious, functional anomalies. Opera has its own mouse movement interpreter, created so that users can make "mouse gestures" without the use of on-screen buttons or gadgets. The browser can interpret a special gesture as a command. But when trying to do ordinary things, like move imported bookmarks to a toolbar, we noticed several inconsistencies.

Historically, we've noted that applications that manage their own mouse movements may have problems with specific mouse drivers, so it may be notable here that our test system uses a standard Logitech mouse. It's important to note here: These behavioral problems persisted up until the point where Opera recognized a mouse movement we attempted with the right button held down as a gesture, and put up a dialog box asking us if we wanted to accept mouse gestures as commands. This happened a half-hour or so into our tests; we responded "Yes." At that point, the behaviors listed below vanished. When we disabled mouse gestures from the Settings > Preferences menu, the behavior returned. Thereafter, we notice the symptoms listed below from time to time when mouse gestures are turned off. However, none of these behaviors caused Opera to crash.

Opera 10.5 Beta 2 puts its bookmarks in a separate tab, like Chrome, rather than a separate window like Firefox.

In any event, we ran into several instances of awkward or unexpected behavior, including the following:

• Dragging an imported bookmark from Opera's Bookmarks tab onto the Personal bar either did not result in the bookmark ending up there, or triggered a rearrangement of the entire contents of the Personal bar, shuffling all the bookmarks that had appeared there before, and adding one other that was not the one being dragged.
• The toolbar being customized sometimes does not accept the dragged object, even though the separator that pops up during the operation clearly shows the toolbar should be receptive.
• Clicking on an item the first time in the Bookmarks tab, just after it's opened, accomplishes nothing, but clicking on it a second time selects it. Clicking on any other single item afterwards will select it.
• "Lasso" drags around a group of items doesn't work in the Bookmarks tab, and perhaps that's by design but it's a bit unexpected.
• Dragging multiple items to a folder (a bookmarks category) does not work the first time, though it will work on successive tries.
• If you click on an item in the Bookmarks tab and then click and hold on some other item, thinking you're dragging it, you might find yourself having dragged the item you clicked on first instead.
• A warning dialog will sometimes appear saying that to add an item to a toolbar, we need to hold the Shift key down. We might see that warning even if we don't have to hold down Shift to successfully alter the arrangement of a toolbar. For the panel selector, you do have to hold down Shift when adding an object to that particular device, and we noted this behavior was consistent throughout.

These are behavioral anomalies consistent with a program that tries to take care of Windows housekeeping for itself; we saw the same level of anomalies with the earlier builds of Google Chrome at the very beginning of its development cycle. But those early builds were classified as such. The problem with Opera 10.5 Beta 2 so far may not be slipshod development (in fact, judged on a timeline, it's actually coming along quite nicely). It's that its readiness for public release and consumption may be somewhat overestimated. These aren't problems that are going to fix themselves over the weekend.

Next: The potential hazards of subdividing the ecosystem...