Opera has posted what looks like a great new Web debugging tool Opera Dragonfly which is released in alpha.
Debug JavaScript, inspect CSS and the DOM, and view any errors – Opera Dragonfly makes developing using Opera easier than ever, both on your computer and mobile phone.
Shawn Lauriat has a nice write-up that tells the story:
It offers most of the familiar tools for DOM inspection (along with a nice DOM editing capability), error logging (with the same granularity as before wrapped in a more polished UI), a JavaScript debugger that rivals WebKit’s Drosera, a JavaScript thread logger, and a lot more that I haven’t explored yet.
Time will tell whether Dragonfly can get enough developers to use Opera and keep them there, and how much the developers behind the new developer tools listen to the community in the coming iterations, but so far this looks extremely promising.
Features
Reach breaking point step by step: Opera Dragonfly’s fully featured JavaScript debugger makes building sophisticated Ajax applications easier than ever. Step through your code line by line, setting break points along the way. This allows you to make sure your application and scripts are acting as you designed them.
Redefine your style: Its not just the DOM you can inspect. Check out what CSS rules apply to which element, and what rules are inherited or set by browser defaults. Overridden rules are highlighted so you can see what styles are or aren’t applied. Support for editing CSS rules will be added in an upcoming version.
Spot your errors: An improved error console allows you to see, filter and log any errors in your scripts, pointing to the exact position the error occurred. Use this in combination with the other tools to hunt down and fix your site’s bugs.
Debug the DOM: View source isn’t much use if you use DOM Scripting to alter the DOM. Opera Dragonfly allows you to inspect the updated DOM and all it’s properties. Support for editing the DOM will be added in an upcoming version.
The features that are not there yet, but are upcoming, include support for editing of CSS, JavaScript and the DOM, a single window mode, improved JavaScript thread handling, XHR and HTTP monitoring, improved keyboard navigation, and translation into a number of languages.
We have a couple of browser updates. First, we have Firefox 3 beta 5 which has improved integration with the host system, a better places organizer, and a bump:
Speed improvements to our JavaScript engine as well as profile guided optimizations have resulted in continued improvements in performance. Compared to Firefox 2, web applications like Google Mail and Zoho Office run twice as fast in Firefox 3 Beta 5, and the popular SunSpider test from Apple shows improvements over previous releases.
Opera also released a new browser with their Opera Mini 4.1 beta. The improvements talk about “faster” a lot: performance, finding things faster, and URL completion magic. This latest mobile browser also supports JSR-75:
JSR-75 is a specification for Java applications such as Opera Mini to access device internal storage and functionality within the phone. Some of Opera Mini features like “Save Pages” and “Download/Upload Files” vary on how much JSR-75 that is supported by the phone.
Since the test was officially announced recently, our Core developers have been hard at work fixing bugs and adding the missing standards support.
Today we reached a 100% pass rate for the first time! There are some remaining issues yet to be fixed, but we hope to have those sorted out shortly.
We will release a technical preview version on labs.opera.com within the next week or so. For now, the screenshot above shows the Acid3 test as rendered in our latest WinGogi Desktop build. WinGogi is the Windows version of our reference builds used for the internal testing of Opera’s platform independent Core.
“The updates from Ian have been done since the release of the test. Opera gets 100/100 on the latest version of the test.”
Sub-pixel testing: It turns out that the original test accidentally required that browsers implement sub-pixel positioning and layout (and in fact the reference rendering got it wrong too, and relied on the same kind of rounding as Firefox does), which is somewhat dubious. I’ve changed the test to not rely on sub-pixel layout. However, it is very likely that this will be tested in Acid4, if we can get the specs to be clearer on this.
Surrogate pairs in SVG APIs: One of the submitted tests assumed that SVG APIs worked on Unicode codepoints, but the SVG spec changed to work on UTF-16 codepoints, like the rest of the DOM API, so the test was changed there. (The test changed a couple of times, because I originally got the fix wrong.)
The click() method: The test originally assumed that the click() method was reentrant, but the specs were vague on this and someone suggested making it fail if calls to it were nested, so I removed this part of the test (the spec hasn’t been updated yet). I replaced it with an attribute test (the new second part of subtest 64).
The Performance Test: I made the loop counter in the performance test (a part of subtest 63) less complicated and shorter, to make it at least plausible that browsers could be fixed to pass that test quickly enough that it wouldn’t always feel jerky. At the same time, I updated the test’s infrastructure to report more details about pass and fail conditions and how long each subtest takes to run.
Namespace bug: Someone noticed that http://www.w3.org/1998/XML/namespace should have been http://www.w3.org/XML/1998/namespace in one of the subtests.
Linktest timeout
I made the linktest more resilient to slow network conditions. However, the test is still going to give you major issues if you are on a network with multi-second latency, or if the acidtests.org site is being slow.
Just as Reddit is celebrating Opera reaching 100/100, with the misleading headline Opera the first browser to pass the Acid3 test (hey, submitter: it wouldn’t hurt to read the Opera blog post before submitting it to Reddit), the Apple guys track me down and point out that there’s yet another bug in the test. With heycam’s help, we have now fixed the test. Again. This presumably means Opera is now at 99/100… the race continues!
I have to say, by the way, that the relevant parts of the SVG spec are truly worthless. Where are the UA conformance criteria? You’d think a spec that was so verbose and detailed would actually tell you stuff, instead of just rambling on without actually saying what the requirements were…
The complaint describes how Microsoft is abusing its dominant position by tying its browser, Internet Explorer, to the Windows operating system and by hindering interoperability by not following accepted Web standards. Opera has requested the Commission to take the necessary actions to compel Microsoft to give consumers a real choice and to support open Web standards in Internet Explorer.
“We are filing this complaint on behalf of all consumers who are tired of having a monopolist make choices for them,” said Jon von Tetzchner, CEO of Opera. “In addition to promoting the free choice of individual consumers, we are a champion of open Web standards and cross-platform innovation. We cannot rest until we’ve brought fair and equitable options to consumers worldwide.”
Opera requests the Commission to implement two remedies to Microsoft’s abusive actions. First, it requests the Commission to obligate Microsoft to unbundle Internet Explorer from Windows and/or carry alternative browsers pre-installed on the desktop. Second, it asks the European Commission to require Microsoft to follow fundamental and open Web standards accepted by the Web-authoring communities. The complaint calls on Microsoft to adhere to its own public pronouncements to support these standards, instead of stifling them with its notorious “Embrace, Extend and Extinguish” strategy. Microsoft’s unilateral control over standards in some markets creates a de facto standard that is more costly to support, harder to maintain, and technologically inferior and that can even expose users to security risks.
Should antitrust courts be the ones in charge of determining which versions of Cascading Style Sheets (CSS), XHTML, Document Object Model (DOM) and other Web standards are the ones to which all browser/Web developers should be writing? Participants in various standards bodies can’t even agree among themselves which version of these standards is the best. How are judges supposed to wade through the browser-standards confusion in a good/fair way?
Would it be positive for customers if Microsoft were suddenly forced to create a version of IE that looked good on paper, in terms of more complete standards compliance, but which broke third-party and custom Web applications? Microsoft has argued that it is trying to avoid this situation with IE and is working on various ways it can make IE more standards-complaint without breaking existing apps, completely upsetting the partner/customer universe.
With Mozilla, Firefox has proved you don’t need government intervention to wrest a substantial percentage of the browser market from Microsoft. You just friends with deep pockets (like Google) and a community of dedicated developers — plus a guaranteed customer base who prefer anything other than Microsoft technologies.
In the end, Microsoft’s own inertia, browser-security problems and inability to react quickly to market changes (where, oh where, is IE 8?) will continue to help its browser competitors more than a ruling by the EU or other antitrust body would.
What do you think? Is Opera’s attempt to get the European Commission to force the unbundling of IE from Windows too late? And what’s your take on Opera’s attempt to get the courts involved in enforcing Web-standards compliance?
Tim Johansson is talking about Opera's support for a 3d Canvas which differs from Mozilla's in that it doesn't map directly to OpenGL, which they did because:
It makes it easier to implement on non-OpenGL platforms (such as D3D)
We wanted to have some form of collision detection available
What can you do? Here is the interface that you get to work with:
We've added support for Opera Link in Opera Mini 4. With Opera Link, you're able to instantly synchronize and share your bookmarks and Speed Dial with the Opera browser for your computer.
Overview mode
Opera Mini 4 includes a new rendering architecture that allows you to view webpages just like you would on your computer. When you first load a webpage, Opera Mini will show you an overview snapshot of the page; using the new mouse cursor you can instantly zoom in to the selected region of the page.
Size of text fits width of screen
Opera Mini 4 dynamically changes the size of the text on webpages to fit the width of your phone's screen, meaning you won't have to scroll horizontally.
Context menu
A context menu is displayed when pressing the number 1 key. From the context menu you could change the viewing modes to 'Mobile view', reload the page, and show webpage information. When the mouse cursor is focused on a link, the Context menu will show you the link information (i.e. where the link points to, etc.).
Mouse cursor
With the mouse cursor you could scroll to any direction on the page and more easily click on links.
Scrolling shortcuts
Pressing these number key shortcuts will help you quickly navigate around the page.
2 - Page up
8 - Page down
4 - Go to the left one column
6 - Go to the right one column
5 - Zoom in and out
Create search
With this new feature, you could add any search engine of your choice to the Opera Mini start page. To add a new search engine, click on the search field, press the menu button and click on the 'Create search' option.
View pages in Landscape mode
By pressing the * and # shortcut keys, you could switch the page view to landscape mode.
New standards support
Support for HTML tables, CSS handheld stylesheets, and more advanced support for CSS have been added to Opera Mini.
Opera Mini is a very clever way of bringing the web to your mobile phone - it will work on most phone models, even low spec ones, as long as they will run a JVM. Basically, when you request a web page from Opera Mini, a request is sent to the Opera Mini servers. They retrieve the page, convert it into OBML (Opera Binary Markup Language,) a very compact binary markup format that reduces the page size by up to 90%, and then serve it to your phone....But what about JavaScript?
The areas covered in his article include:
How Opera Mini interprets JavaScript
Server-side support
Client-side support
Ajax support
One key point that jumped out at me is that the Opera Mini servers have full support for ECMAScript 4 on the server-side but is hindered on the client side by the limitations imposed on individual handsets.
After the page has been transferred to the client, things are a lot more limited - basically all events are processed on the server. The client does absolutely no JavaScript processing at all, and instead the page is kept in the server (basically the client works as an input device for the opera running in the server).
My reaction was obviously that this is a major limitation but Chris goes on to give this perspective:
This sounds limiting, but there is another point to consider - Opera Mini can execute JavaScript on the server if it's triggered by the JavaScript events listed above in the client, so some complex pages work surprisingly well - for instance Facebook is able to display popup menus and popup dialogs very well on Opera Mini.
There are also some considerations when trying to use Ajax, as the Opera Mini architecture handles Ajax requests slightly differently based on the expected functionality. Chris cited the use of automated page refreshes as a possible sticking point.
As with any mobile device or browser, a lot of homework needs to be done when developing for Opera Mini but it looks like Opera is making some good strides towards easing that pain.
It looks like the Opera team really focused on the rendering engine, with some fast results displayed during CyberNet's review. Ryan, CyberNet's reviewier:
...decided to do a rather unofficial speed test to see how fast the different browsers rank in terms of loading our site (with an empty cache). I did three tests for each browser and averaged out the time it took for each to completely load our site. Here are the results with the slowest browsers first:
Internet Explorer 7: 18 seconds
Firefox 2: 15 seconds
Opera 9.23: 12 seconds
Firefox 3 Nightly: 11 seconds
Opera 9.5 Alpha: 8 seconds
In addition, it looks like accessibility is big on the list of enhancements with enhanced support for Window-Eyes, Jaws, and VoiceOver on OS X as well as updated keyboard shortcuts to make navigation easier. You can get more info at the Opera Desktop Team's recent blog entry about the release.
The Opera folk have released an API that allows you, the developer, to be able to monitor all of the remotes that are connected with The Wii Remote API.
This means that you can watch up to four people buzzing around the screen:
Polling the status of a remote
The Wii Remote data is accessed through the opera.wiiremote object. This object offers a single method opera.wiiremote.update(n) which is used to obtain the status of an individual Wii Remote. The method expects a single parameter; the Wii Remote number. The number is zero-based, so it starts at 0 for the first remote, and ends at 3 for the fourth remote. The method returns a KpadStatus object, which has several properties that give information about the remote.
This update method can be called as often as is needed to obtain a fluid response, but note that the Wii is not as powerful as most desktop computers, so it is important to make sure that it is polled only as often as the script that uses that data can process it. For example, if a script uses the Wii Remote status to update the display of a canvas element, and that update will take perhaps 50 ms to update in Opera on a desktop computer, it may take over 100 ms on a Wii. Attempting to use a polling interval of less than 100 ms will cause the response to appear very sluggish.
Note that the opera.wiiremote object only exists in Opera on Wii, so it is important to check for its existence, as well as the existence of the opera object, before attempting to use it.