My Opera
Opera Dragonfly 1.0 RC
By David Storeydstorey. Tuesday, April 12, 2011 12:59:17 AM
The final release of Opera Dragonfly 1.0 is edging ever closer. We pushed the Release Candidate (RC) to the experimental branch today (well really yesterday, but who is counting a few hours?).
All being well, the RC will be what is released on the default path as Opera Dragonfly 1.0. We’re now intensively testing this release with the RC of Opera 11.10. If the build passes testing without any show stoppers it will go golden in the near future. We believe this version is a huge improvement on Opera Dragonfly Alpha, which is the version the majority of our user base are currently using. We hope those users will be pleasantly surprised by the improvements, and will find it even more useful. We’ve implemented the vast majority of the most common requests in the recent user survey we did, and have improved the discoverability of those features which many users missed.
For those users that have been following the progress of the latest version, the final version is mostly a polished version of the recent beta release. The UI has been cleaned up and optimised, including a number of new icons. The Network and Resource Inspectors in particular have received a lot of polish, and the colour picker in Utilities has undergone a redesign. The associated colour palette is now integrated with the floating colour picker. The element highlight customisation has also been simplified and uses the colour picker for selecting the highlight colour. Selecting multiple elements should also be improved.
The UI strings have now been reviewed and should be more self explanatory. This will hopefully make the features easier to understand. It was fairly difficult to understand the icons for the status codes in the Network Inspector, so these have now been replaced with the actual codes themselves. If you are not well versed in HTTP status codes you can hover the code to see the description. Cached resources, such as 304s and those that didn't even contact the network are highlighted with a grey background behind the status code.
Changes to the Resource Inspector include syntax highlighting for CSS resources, and a preview for font resources. The font preview is editable, so you can try out adding any glyph you want to see for the font in question. The Resource Inspector is now hooked up to other views. Errors, links to style sheets in the Style Inspector and links to resources in the DOM Inspector will now open the resource in the Resource Inspector.
One change in functionality is that breakpoints are now deleted when clicking on an existing breakpoint in the gutter. They can still be disabled using the right click menu, or the breakpoints panel. All breakpoint related icons have also been updated and polished.
The final release if Opera Dragonfly 1.0 gives us a strong base on while to build. We feel it is a competitive release with many of the features expected in modern debuggers, such as watches and conditional breakpoints. We will build upon these strong foundations to add many innovative features above what we have already implemented. We will also work towards optimising and polishing existing features to improve their consistency, ease of use and functionality. We hope to make each tool in Opera Dragonfly the best in the business. Now that a stable foundation is in place we should be able to have shorter release cycles, improving each feature in turn.
We hope you enjoy Opera Dragonfly 1.0 once it is released and that it helps you in your day to day development needs.
Daniel HendrycksDanielHendrycks # Tuesday, April 12, 2011 1:41:22 AM
d4rkn1ght # Tuesday, April 12, 2011 2:26:17 AM
Charles SchlossChas4 # Tuesday, April 12, 2011 2:27:11 AM
When I ran the beta in 11.01 I got a cpu spike
Ronit Kumarronitrex # Tuesday, April 12, 2011 3:24:08 AM
Pablo MendozaPabloMendoza # Tuesday, April 12, 2011 4:06:22 AM
Michael A. Puls IIburnout426 # Tuesday, April 12, 2011 4:52:30 AM
The main issue I have with DF is the same as always. When things don't fit because of resolution, DF breaks. Things overlap or get hidden instead of wrapping and or showing scrollbars. I'd like to see this improved greatly. There are also lots of things (like the network log URI cell width) that are not resizable that should be. And, some things are resizable, but there's a limit on how much you can shrink them.
It'd also be nice if Opera finally supported auto-scrolling in containers (like overflown divs). Then, DF could allow you to do this in the DOM tree view section for example.
FataL # Tuesday, April 12, 2011 4:57:43 AM
Nice redesign of colour picker in Utilities. But would be interesting to know why you decided to use screenshot for colour peeking instead real page.
The following issues affect me more than others:
nahtanoj999 # Tuesday, April 12, 2011 5:21:11 AM
Erik HauboldAltarius # Tuesday, April 12, 2011 6:02:11 AM
if i now open the clientscript, connect to the server via websocket and open dragonfly, the socket won't get closed anymore.
eg: if i reload the page or close the socket manually (my script reports, the username is still in use). if i close dragonfly then, all connections get closed.
hope there will be some fix/workaround for final, because apart of this it's a very nice piece of software
GreLI # Tuesday, April 12, 2011 6:11:39 AM
sirnh1 # Tuesday, April 12, 2011 6:45:35 AM
(screenshot)
1. Why do some files show the n/a status? Is it because the content blocker blocked them? Or because of something else?
2. Any chance on making it (magically) easier to see what entry in the network inspector matches what file?
David Storeydstorey # Tuesday, April 12, 2011 7:17:59 AM
Originally posted by sirnh1:
1. N/A means there is no HTTP status code. Opera used the resource but it didn't contact the server to request it. It was pulled from the cache. This is different than 304 where the cache is used but Opera checked the server to see if the resource was modified before using cache. Files in cache are shown with a grey box behind the code (or N/A)
2. Right click on the resource name in the network log and select show resource.
Maulkin # Tuesday, April 12, 2011 7:22:18 AM
Seriously, I'm waiting for the final version to come out eagerly!
tbassetto # Tuesday, April 12, 2011 7:31:19 AM
Nice release anyway
VarunVarunM # Tuesday, April 12, 2011 8:25:16 AM
David Håsätherhzr # Tuesday, April 12, 2011 9:49:55 AM
Originally posted by GreLI:
Work has begun on this. The biggest challenge is that it becomes slow to update the DOM view constantly when there are many mutations.Originally posted by tbassetto:
This is a known issue.sirnh1 # Tuesday, April 12, 2011 12:33:57 PM
(screenshot)
The list with the script file names, doesn't show the querystring anymore. For me this is very annoying. These days I work a lot with .NET, and I often have to debug javascript files that are basicly 'embedded resources'. These used to show up as:
'WebResource.axd?d=<enter very long random string here>'
I used to look at the first 6 or 7 few characters of the long random string, and I basically knew what was in the file for the rest of my debugging session.
Any way of getting my querystrings back in the dropdown? (Why did they get removed anyway?)
Edit: I really like the text behind the 'Inline - ' lines. This is a real time saver. Thanks, just need my query string back.
Originally posted by dstorey:
1. thanks for explaining that
2. yeah, but if I want to find 1 specific file, I have to go over them 1 by 1
FataL # Tuesday, April 12, 2011 4:33:42 PM
show all CSS rules, not only that is known for Opera (like WebKit does).
I.e. show all -moz, -webkit, -ie, -whatever CSS rules.
This feature is extremly usesul for CSS3 debugging. Also your own Open The Web team will appreciate it.
JanGen # Tuesday, April 12, 2011 5:26:40 PM
Originally posted by nahtanoj999:
I'm missing this too
sxtynnmach1 # Tuesday, April 12, 2011 5:29:42 PM
Two things I would like to see in the "Scripts" tab:
1) when stepping through a function, hovering over an in-code variable displays a tool-tip with it's value.
2) An option for the filter in the script inspector to, by default, filter through ALL scope levels (currently, you have to expand each scope level separately before they included in the filtered results)
Originally posted by FataL:
I also would like this. And CSS stylesheet line numbers!
Charles SchlossChas4 # Tuesday, April 12, 2011 6:47:50 PM
David Håsätherhzr # Tuesday, April 12, 2011 8:37:03 PM
Originally posted by Chas4:
Yea, this is correct. The RC is on /app/experimental.ncc50446 # Wednesday, April 13, 2011 3:19:37 AM
Runermad # Saturday, April 16, 2011 10:44:53 AM
Nice update
Are there a settings to ignore css errors?
Currently I use Extjs/Openlayers and they generate > 100 error/warnings/info entries on load...
Are there a way to decode base64 encoded response body in the network tab?
Christian Krebsaleto # Saturday, April 16, 2011 11:10:11 AM
Originally posted by rmad:
Depends a bit on the errors, but there is Settings > Error Log > Use CSS filters.
Originally posted by rmad:
What exactly is the use case? Binary resources are base64 encode and displayed appropriately, if possible, e.g. as image?
F.V.F-V # Saturday, April 16, 2011 6:53:14 PM
Originally posted by dstorey:
How far are we on this? Admittedly this release candidate seems to work a bit better than previous versions I used where keyboard operation is concerned (tabbing seems to reach more items now, ctrl+tab is working correctly), but it hardly looks finished:
- Getting initial focus into the Dragonfly pane seems to be impossible.
- Changing focus is often very poorly visible, you have to scan the entire Dragonfly pane for a minuscule outline somewhere.
- Context menus don't work. You can invoke them, but then there are two menus. Trying to navigate the context menu operates the underlying Dragonfly pane. Dismissing with escape produces a weird console.
- Still extremely weird things going on with focus, such as space performing a pagedown on the html page, instead of operating a tabbed control in the Dragonfly pane...
Probably I could make the list a lot longer if I tested it for more than one minute. Anyhow: while the basics are there, the current state seems completely unusable for keyboard users. Certainly not what could be called "showcase of accessibility on the web".
Sadly all of this was indicated years ago when the first alphas were released. Have you given up on accessibility and should we simply conclude that advanced web 2.0 applications and accessibility can't go together?
Michael A. Puls IIburnout426 # Saturday, April 16, 2011 7:12:28 PM
Originally posted by F-V:
This is all probably due to the common development model of not designing with keyboard accessibility as a first-class citizen from the start. Hacking things in now looks to be troublesome, as you'd expect.
F.V.F-V # Sunday, April 17, 2011 8:52:45 AM
Originally posted by burnout426:
Indeed. One of the things I recommended three years ago is to make the whole thing entirely semantic and logically structured, with clear roles and hierarchies showing from the source code. That way you could use Opera's own shortcut keys to bubble and operate on the correct widget in the correct way in the whole Dragonfly environment, instead of hardcoding shortcuts and trying to intercept and then interpret them with Javascript.
I'm very poor at reading obfuscated source code and my Javascript skills are nonexistent, but I've heard that the way the Dragonfly source currently works is simply too complicated to deal with focus in a logical and consistent way.
Look at the 'modal' overlay dialogs, where keyboard control happily operates things in the background: one tried to mimic some native UI here, seemingly glued a few divs and event handlers together to make it work with the mouse, and stopped.
This is not a question of finetuning a few things, or fixing a few remaining buglets; it looks like a fundamental design choice that will be incredibly hard to fix now, now that so much effort has gone in the current state of Dragonfly. As with so many developments in Opera's UI and features, an overall accessibility guru who oversees the project, sets prerequisites and adjusts when things go wrong is sorely lacking in Opera.
Not that the knowledge is not there. On Opera Dev there are a few very informative articles on accessibility in web applications. Sadly much of this advice was missed in Dragonfly, which somewhat switches the tone of the articles from informative to pedantic. Also for accessibility outreach endeavours this is the worst signal you can give.
David Storeydstorey # Monday, April 18, 2011 4:37:10 PM
Originally posted by F-V:
I’m not sure where you heard this, but it isn’t true.
Originally posted by F-V:
Also not true. It is true that there are some issues with keyboard navigation in Opera Dragonfly. There are many ways it can be improved. However we’ve had many discussions on how this can be improved, and it will not be forgotten about. We had to build Opera Dragonfly from the ground up to compete with existing mature tools. Those tools are also not standing still. We are much closer to feature parity now that we were, and we have some unique features.
With Opera Dragonfly 1.0 we have most, if not all all of the critical must-have features that we needed to implement to be a credible product. We have that foundation in place, and we can start working in two core areas: improving the application framework and global features, and polishing and improving the existing tools. We will also work on adding new tools that we find are important, such as a profiler. Improving the keyboard accessibility is a key part of the first area. WAI-ARIA is something we can use to help with this, but we also need a very solid and consistent spec that fits our needs and is predictable for users. Discussions are ongoing on this, and we’re committed to getting it right. We’re very close to the 1.0 release right now, but it will be resolved after that.
F.V.F-V # Monday, April 18, 2011 5:49:40 PM
It's very good to hear it is still on the radar, and apparently not as fundamentally difficult to solve as I feared.
I still think it is a pity, and a very poor signal, to start doing accessibility after a 1.0 release instead of seeing it as a prerequisite around which a whole product should be built from the start. Also not requiring accessibility in any public (or at least any final) release might make a development team susceptible to a vicious circle where, at any future stage, the rush to introduce new features always gets higher priority than fixing what didn't make it in 1.0. This attitude has already bitten many a feature in Opera Desktop, accessibility-wise, so I hope we won't see the same pattern here.
Michael A. Puls IIburnout426 # Monday, April 18, 2011 7:20:18 PM
Originally posted by F-V:
Pretty much the way I feel too, fwiw.