Mobile Technology News & Mobile Fun

Is Opera 10.5 ready for the March 1 ‘choice screen?’

By Scott M. Fulton, III, Betanews


Download Opera 10.5 Beta 2 for Windows from Fileforum now.


Banner: Test Results

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.

Actual Beta News feature bannerBut 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.

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.

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…

Download Opera 10.5 Beta 2 for Windows from Fileforum now.


Banner: Test Results

The potential hazards of subdividing the ecosystem

Up until now, one of the strengths that have sustained Opera through the rough periods has been its customizability and extensibility. For the most part, Opera can be made to function the way that users want it to function, and that customizability comes as part of the package. By comparison, Firefox’s strength to this point has been that a very strong community of developers, fostered and nurtured by Mozilla, have been able to craft extensions and add-ins to Firefox that enable professional users such as myself to practically reconstruct the browser into the tool they need it to be.

Opera has also nurtured a development community, but the model Opera has promoted revolves around widgets — mini applications that are executed by Opera’s JavaScript interpreter. Since Firefox is a JavaScript app in itself, extensions can run in the context of the browser and modify it. Now, Opera is becoming more strict about its development model. With version 10.5, widgets will be restricted to applets that run outside the browser context, such as weather applets, e-mail checkers, and sidebar-like games.

In Opera 10.5 Beta 2, widgets are supposed to be stand-alone applets.  Tell that to the developers who display their wares in Opera's gallery.

The new model for Opera 10.5 widgets is supposed to be based on stand-alone applets. But some of Opera’s select widgets in its own gallery, are not.


Fair enough, especially since Opera doesn’t need a lot of add-ons (like Firefox does) to be customizable. But when European Web browser users see the Opera brand for the first time, by virtue of its prominent placement on Microsoft’s new browser “choice screen,” whether 10.5 is ready for public consumption or not, Opera will likely lead new users to the place where they can download the fastest browser the company produces. After they do, users will want to experiment with how far they can stretch it…or, they may happen upon the Widgets panel while simply playing around with new and shiny buttons. Once they’re taken to Opera’s widgets gallery, they’ll see add-ons like the homemade version of Google Toolbar (whose listing is shown in the screenshot above).

These users may not know old-style extension widgets won’t work in the 10.5 context until installing them and seeing that nothing happens. Users may take that to be a bug in the program, when really it’s a change in the architecture that hasn’t been passed on to the proprietors of Opera’s Widgets gallery. And that may become a problem.

Working with Opera in the performance department

In our report last Tuesday on Opera 10.5 Beta 1’s relative performance, we noted that there appeared to be a continuing bug in the way the browser was executing one of our tests. Opera’s engineers wondered whether the bug was in the test we were using — which is actually fairly old, as benchmarks go: the Testnet.World JS JavaScript instruction test.

We’ve encountered situations before where Opera’s and Safari’s counters were synched with their respective JavaScript interpreters in such a way that they tended to report that no time was expended whatsoever (“0 ms”). Whether that’s actually a defect or an architectural symptom may depend on where one stands (and who signs his paycheck while he’s standing there). Nevertheless, two of Opera’s architects suggested improvements to the Testnet.World battery that they said would avoid this perception problem.

Giving Opera the benefit of the doubt, we implemented their suggestions. What we discovered made us satisfied that we were given good advice. Essentially, the old benchmark tested the time expended, but when it came up 0, it assumed the test never started running, so it maintained the loop. Our new test battery no longer trusts the expended time indicator, but rather, triggers a binary “done” flag for each test. In order to better measure events that used to take tenths of seconds but now take fractions of milliseconds, we increased the workload for each test by a factor of 10, for a million iterations rather than 100,000.

It was in ten-tupling the workload that we made several interesting discoveries:

  • Internet Explorer 7 wasn’t such a slouch.. At 100,000 iterations, yes, IE7 on Vista SP2 (our slow index browser, for purposes of comparison) is pretty darned slow. Frankly, I was afraid that increasing the workload would make IE7 slow down exponentially. It did not; in fact, it scaled up the workload rather well, in some cases handling each iteration of the larger workload faster than for the smaller one. As a result, as the workload scales up, the comparative scores for other browsers measured against IE7 go down. That helped reset our overall scores by about 12% across the board.
  • For some very repetitious workloads, Firefox is twice as fast as Chrome. No, that’s not a typo. It could be argued that real-world Web pages are not going to repeat a million conditional statements. However, if we treat this test battery not in terms of how well browsers repeat statements but of how well they scale large (if artificial) workloads, Firefox is actually the champion here. The stable Firefox 3.6 on Windows 7 scored a 4.45 (445% the speed of IE7 in Vista SP2) on the corrected Testnet.World battery. By comparison, the latest daily build of WebKit/Safari 4 scored a 3.91, while Google Chrome 5 Dev build 335.0 scored a 2.26. The latest stable Chrome 4 scored 2.09. What difference does that make? On our old (uncorrected) Testnet.World battery, using one-tenth the workload, Firefox 3.6 scored a 31.88, while Chrome 5 scored 43.18.
  • Opera’s developers are pretty decent folk. Their suggested changes eradicated the appearance of the “0 ms” anomaly, but it did not result in Opera 10.5 Beta 2 receiving favorable treatment. It only scored a 3.32 on our corrected battery.

Compensating for the anomaly did, as we predicted, improve Opera 10.5 Beta 2’s scores relative to Chrome. Though the revised Testnet.World numbers scaled everyone back (IE8 and Firefox least among them), there’s now a three-point performance gap between Opera’s and Google’s most recent development builds. Chrome 5’s scores on the other batteries in our Windows 7 test suite were generally lower once again. The latest dev build, among other adjustments, changed the way that browser interprets the source of locally stored HTML files — each one is now considered within its own individual domain, rather than in the shared domain of the computer. That’s a very important safety adjustment that security-minded users should welcome.

Relative performance of Windows-based Web browsers in Windows 7, February 26, 2010.

Click here for a comprehensive explanation of the Betanews CRPI index version 2.2.


After resetting our numbers, Opera 10.5 is now the only browser that scores above a 20 in our Windows 7 index, with a 21.50 versus 18.51 for Chrome 5. In the latest builds, Chrome 5 opened up a bit more of a lead against Opera 10.5 in the all-important SunSpider battery. But Opera gained back quite a bit of performance in the table element rendering category, which has historically been a strong point for Opera anyway.

Does Opera feel ready?

As Microsoft would probably tell us at this point, performance gains only matter if users can feel them. “Splinters” such as skin elements that don’t line up can lend to perception problems that the browser feels unfinished, and that perception can become a lens that magnifies any other problems the browser has.

One such problem we encountered with Opera 10.5 Beta 2 concerns hesitancy. From time to time, after clicking on a bookmark or a hyperlink, or even during our performance tests, we noticed that the browser can go into a state of limbo for as long as a second, before our network meter validated that it has started loading the page. And when a page contains a long <TABLE> element — for instance, of items pulled up from an SQL database — reloading or refreshing the page, or loading a page with a different <TABLE> element, causes the entire plotting area of the window to go white for a noticeable period of time.

There appear to be lots of little issues like this in the latest public beta of Opera 10.5 — enough for us to suggest there should be at least a Beta 3 cycle before a final public release. If the aim is to move users off of Internet Explorer, it should be noted that IE8 does not have lots of little issues like this. It’s slow as a jar of molasses buried under a glacier, but many users don’t care because, to them, it feels finished, usable, drivable, like a ’76 Cadillac Eldorado.

Opera has come a very long way in a very short period of time. But as Vista proved, perception in this business is everything. If its engineers take the time they need to sand off all the splinters, this browser has all the ingredients it needs to dethrone Firefox, Chrome, and even IE in their respective categories of strength. This is the one that could actually do it. But if it’s rushed, and it premieres to the general public looking unfinished and cobbled together, those ingredients may go unnoticed.

Copyright Betanews, Inc. 2010

Add to digg
Add to Google
Add to Slashdot
Add to Twitter
Add to del.icio.us
Add to Facebook
Add to Technorati


Have something to add? Share it in the comments.

Your email address will not be published. Required fields are marked *