Dragonfly feedback follow-up

I've gone through the comments on my previous Dragonfly post, here's a more-or-less organised overview. I've reported BitBucket issues on the requests I found really good – sorry about this bit of favouritism, but I encourage everyone to report issues themselves and they should all be considered on their merits whether reported by insiders or end users ;). I hope nothing important is missing, and sorry about the lack of proper credits on several points.

General feedback and feature requests

  • JavaScript profiling is a required feature, both timing and memory usage (planned).
  • Make UI take up less space (not sure what the plans are, but I'll let the designers know that several users thought the new design requires too much space..)
  • Add a mode that does not require reloading to get script context, and optionally let Dragonfly tab/window follow current opera tab automatically. (This is DFL-811 internally – because I personally think several other things are more important I have not created a twin issue at BitBucket but feel free to do so.).
  • Show IFRAME contents in DOM view (This is DFL-74 internally, I've cloned it to unable to traverse IFRAMES/FRAMES on BitBucket in case somebody wants to pick it up ;))
  • Multiline console (seems shift-enter isn't enough 🙂 – and seems shift-enter to type multiple lines has disappeared in the experimental version anyway..)
  • Picture previews in CSS/DOM inspectors
  • With OS's "Group similar taskbar buttons" enabled, avoid being grouped with the main window's taskbar button
  • Being able to run Dragonfly in a tab inside Opera
  • Being able to use the JS console as an interpreter, not attached to a page.
  • Optional mode that strips vendor prefixes from CSS if Opera knows the non-prefixed attribute
  • A ruler or grid in the utilities, suggested by Daniel Hendrycks. Daniel, since you're on BitBucket perhaps you can add some issues there for these requests?

F.V. requests "native appearance and behaviour, keyboard accessibility and consistency". Well, that would be good but it's a bit too high-level to be truly useful. I've had a quick look at keyboard accessibility, and came across a few issues:

Probably more, it would be good to get more eyes (or rather fingers, actually) on this.

Specific minor requests / bug fixes

  • Show User JavaScript filenames in UI, requested by lucideer. Though I first filed a BitBucket issue with some further testing I concluded it's a core problem, so send file name of user scripts through scope in OnNewScript is the one that needs fixing.
  • More efficient pane resizing
  • Parts of DF become inaccessible when docked in a small window – enable scrolling the entire UI
  • Copy script addressreported here
  • Cleaner network request view (or default to "raw") – now, the entire network feature will see a lot of work as shown under "Core upgrade: Resource Monitor" on the Dragonfly roadmap. As a consequence I guess the UI will change dramatically, and probably for the better.
  • There's a redraw issue with the inspection area under "Scripts" – can't find a bug here, though it's a really obvious problem so perhaps it's just too well known to bug it?
  • Easier way to open DF from menus – Michael, isn't right-click – > "Inspect element" easy enough though?

Questions (aka features that are there but too hard to find..)

Where is the place i can see global objects? All i can see is dom properties of html objects?

If you're at a breakpoint, clicking "Global scope" at the top of the call stack shows the properties of the global object in the inspection pane. If you are not at a breakpoint I guess the fastest way is to type "top" into the command line and click the returned link. Perhaps it would be more convenient if the inspection pane would default to showing the global object initially?

Originally posted by hellspork:

One crazy-awesome thing would richer support on "view source"/apply changes. If "view source" had a small selector pane, which allowed the picking of elements to edit.

Right-click, "Inspect element", expand it and double-click it. You can now edit the source of a specific element, in its current state in the DOM.

Originally posted by hellspork:

An engine improvement that allows the export of a loaded page, by bundling cache files with a master cache document?

That's basically what Opera's "File > Save" does if you save the page as a Web Archive. 😉

Thanks for all the feedback! If you are on BitBucket please follow Opera Dragonfly, and feel free to report new issues there.

Advertisements

35 thoughts on “Dragonfly feedback follow-up

  1. tomasb writes:"Easier way to open DF from menus – Michael, isn't right-click – > "Inspect element" easy enough though?"Nope. Dragonfly has a nice icon. Why not place it to bottom right corner? that's the place where firebug in ff is.

  2. Originally posted by anonymous:

    Nope. Dragonfly has a nice icon. Why not place it to bottom right corner? that's the place where firebug in ff is.

    Put it yourself like I did. I also have error console button there and some others.

  3. Most importantly for me – in network requests tab, let me se:- request header- request response- the response itself, I can't see why it's not there…???

  4. Originally posted by Svoboda:

    – the response itself, I can't see why it's not there…???

    This is on the roadmap, part of the network work I'm mentioning in the blog post :).

  5. I've got a tiny request. Make UI buttons work when they are clicked once. Often the buttons are visually pushed but you have to click twice to make the button do what it should do. This is *really* irritating!

  6. Easier way to open DF from menus – Michael, isn't right-click – > "Inspect element" easy enough though?

    Yeh, I forgot that was added and my eyes have missed it in the menu. It's as quick as using the keyboard shortcut. But, I think I still might use the shortcut a lot though because I often don't want to inspect an element and want to look at http headers instead (even if there's no harm in inspecting an element by default in this case).I still think something should be done about the "Developer Tools" menu being buried though. But, I'll propose something on that later as it requires a new feature for the menu ini files. Or, maybe this stuff can be fixed with an extension.

  7. I will quote Steve Ballmer:"Developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers."source:

    They are important because even if web page isn't compatible with standards it will display properly on Opera (if they develop using opera). Opera should care more about web developers.P.S.What will happen to DF when opera enable plugins?

  8. Originally posted by Penge4:

    Originally posted by hallvors:

    Being able to run Dragonfly in a tab inside Opera

    +1000! And/or attached only to the inspected tab, not to the all.

    +10000!

  9. Originally posted by hallvors:

    Make UI take up less space

    +1Originally posted by hallvors:

    Being able to run Dragonfly in a tab inside Opera

    +1000! And/or attached only to the inspected tab, not to the all.Originally posted by hallvors:

    Optional mode that strips vendor prefixes from CSS if Opera knows the non-prefixed attribute

    +1000!Originally posted by hallvors:

    F.V. requests "native appearance and behaviour, keyboard accessibility and consistency"

    +1

  10. Originally posted by Michael A. Puls II:

    Originally posted by FataL:

    Ability to work with JavaScript disabled, please.

    Yes.

    Please! And at the very least a <noscript>-ed error message in the interim to remind us when we've got it off – this occasionally has me baffled for quite a while.

  11. Originally posted by lucideer:

    Please! And at the very least a -ed error message in the interim to remind us when we've got it off – this occasionally has me baffled for quite a while.

    Indeed!

  12. Being able to run Dragonfly in a tab inside Opera

    Would be nice, yes!But I'm still dreaming about ability to run it inside a panel 🙄

  13. Originally posted by FataL:

    But I'm still dreaming about ability to run it inside a panel

    +1 for the Developer/DragonFly panel.

  14. Originally posted by FataL:

    But I'm still dreaming about ability to run it inside a panel

    Ideally, something like opera:debugger could point to whatever's served by opera:config#Developer Tools URL and provide scope access – this would give both a tab and a panel and possibly other things…Originally posted by hallvors:

    Show User JavaScript filenames in UI, requested by lucideer. Though I first filed a BitBucket issue with some further testing I concluded it's a core problem, so send file name of user scripts through scope in OnNewScript is the one that needs fixing.

    Thanks for this. Funny, I would've assumed it would've been included in CORE first time this was enabled too. I suppose this is why I suggested providing script metadata through Scope as well – I can't think of an immediate use for it in the Dragonfly UI either, but surely the point of providing a documented API like Scope, and open-sourcing Dragonfly is so people can do things with the API that you might not have considered when spec-ing it.

  15. Anonymous writes:@Hallvors, thanks for the update. ||| few more remarks: – dragonfly must be able to be locally installed and updated (work offline). some companies (like mine) do most rnd without access to internet (you use your other machine to google etc, but code is isolated). – 'reloads' MUST go away. watching how my QA department works i know for sure, that they'd revolt when given dragonfly to work with. it simply sux when you have to pay serious attention to open tab/df in correct order etc, it is frustrating. i know why you want to dismiss it (approach youve chosen makes it almost impossible) but it is problem of a person that made that decision, firebug works that way, so you should also do that. without it – dont expect much use from folks at yahoo, google, ms etc. BTW. is there anythign that dragonfly would do, that firebug does not (except remote debug).

  16. Originally posted by anonymous:

    dragonfly must be able to be locally installed and updated (work offline)

    It is. Download a copy from the BitBucket repo and point opera:config#Developer Tools URL at the src directory.Originally posted by anonymous:

    firebug works that way, so you should also do that

    No it doesn't – it has to be explicitly enabled for the page, which loads scripts. The only difference is that Firebug is capable of running in the background, without a window/docked pane at all… which would actually be an excellent addition to Dragonfly come to think of it.Originally posted by edvakf:

    I want to see request/response body in the network tab.

    It's already in the roadmap, waiting on a core fix.

  17. This is an excellent update. Next phase just keeps on looking better.Hallvors: I will further examine MHT behavior a bit. What I was trying to describe was the capability to treat a page as more of a…project file…? Something which would allow me to attach a complete, "fixed" page to an email when contacting the designers of a broken site. This is why I figured either Opera's native source editor could be strengthened, OR Dragonfly could have an import/export structure. I assume Dragonfly also has access to FileI/O?…even so, it's more important to implement those script-tracing tools and the extra resource-tracking. Thanks again for sorting out priorities.

  18. Originally posted by Penge4:

    attached only to the inspected tab, not to the all.

    +1, I requested this when they first started laying the groundwork for dragonflyOriginally posted by fearphage:

    important: the entire console should be attached to each page. it should not be shared across tabs

    Tuesday, 11. September 2007 (source)I hope it comes

  19. How should the multiline console work? You can add lines with ctrl-enter (I wasn't aware of the shift-enter command. I can re-enable that on I suppose.) Any more features except the ability to add newlines that are needed?

  20. Anonymous writes:multiline console? just run firebug with console open in the right pane (not as a single line 'command prompt') and that's it. so you can comment code, run it with ctrl-enter, all usual undo/paste. and normal enter goes to new line, not runs it. tab formatting/indenting. that's it – it is simple as that, but trying to work with anything less is painful. if we are at requests – https://chrome.google.com/extensions/detail/ognampngfcbddbfemdapefohjiobgbdl – make this your starting point of how resource monitor/profiler should look like.

  21. It's indeed very inconvenient to edit slightly longer strings of code in the single-line console (especially when the string is incorrectly formatted and you use up-arrow to fetch it from history to re-edit.. It's not even clear from the UI that the entire string has been restored, you see only a bit of it at a time.)Oh, and Rune: please make the shortcut for linebreaks in the console shift-enter as ctrl-enter seems to be used differently by the competition 🙂

  22. Anonymous writes:firebug console uses 'enter' for linebreaks, shift enter is not used at all (i never used it myself anyway). the only way to run it is to use ctrl enter (or click RUN) – and if you want to have something i miss in firebug – 'run selected code'. i sometimes found myself with LONG part of code in the console and at the same time had to run single query to 'just check something'. commenting it out and de-commenting a moment later was a pain. oh. and in firebug you can drag/drop bits of code, probably yours could do the same as it is textarea anyway.

  23. Anonymous writes:I don't know if my request is what's meant by 'ES: Inspect closures and scope' on the public roadmap, but I'd really like a way to see every object/variable/function/… available at a certain point in a script, including those provided by this, arguments, the global object, the lexical scope and augmented scopes (catch etc.). Obviously, all objects should also allow inspection of their prototypes, getters/setters, etc.Especially lexical scope inspection must be implemented.

  24. Originally posted by anonymous:

    I'd really like a way to see every object/variable/function/… available at a certain point in a script, including those provided by this, arguments, the global object, the lexical scope and augmented scopes (catch etc.).

    If I understand you correctly, this is already there. Maybe I'm misreading you, but don't you get this in the inspection pane to the bottom right of a paused script? You can then change scope in the call stack pane to access different object/variable/function sets. Am I missing something?

  25. Originally posted by lucideer:

    If I understand you correctly, this is already there

    Almost. For example the this object and the arguments object are already there, but for example closure data is missing. I've been waiting for that a few years now, but it's finally coming 🙂

  26. Anonymous writes:Make the "Scripts" tab search box search for strings /across/ all scripts listed in the dropdown, not just the currently-selected one. When a site has 12 inline scripts plus 10 linked scripts … it is very time-consuming to search for something by doing change the dropdown, search, change the dropdown, search, change the dropdown, search.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s