Vivaldi Web Inspector (Dragonfly revival)
-
I would really like a dedicated web inspector for Vivaldi, ideally in addition with the current Chromium Dev Tools.
Why?
- Because it is part of the browser identity.
- Because Chromium Devtools becoming a real mess. Huge tool with a very confusing multi-level UI. I do believe there is others ways (The Webkit Web Inspector for example do have a quite nice and ergonomic UI, Opera Dragonfly also had a very clear and nice UI).
- Because diversity is good, and there is only 3 different inspectors existing now (Safari WebInspector, Chromium DevTools & Firefox DevTools). A few years back we had 2 more: Edge inspector & Opera Dragonfly.
- Because Chromium DevTools only exists in english in Chromium (Even if Microsoft did a lot of work of translation in Microsoft Edge about it, but it is still not done on Chrome).
- Because today, we have computers running with Android but we can’t open the DevTools in any browser on them. Theses devices can have a mouse, a keyboard and a screen similar to a laptop, but they can’t have a browser DevTool…
- Because it could use some very specific features of Vivaldi. For example, snippets are not that good in Chromium DevTools. But in Vivaldi, it would be quite nice if snippets could actually be stored in one of my Note folder (And then, they would even be synchronised
). - Because some parts of the inspector could be used in others places of Vivaldi. For example, the source viewer could be used in replacement for the default chromium source viewer. And the XML/JSON viewer could be used when we arrive on XML/JSON urls (Firefox do that, and it would cover this feature request for example).
- Because Opera Dragonfly had some uniq features which are still not in any browser inspector today. Such as:
- Representing the DOM as a node tree, which allow to see the text content which exists between tags. Sometimes quite useful for debugging.
- Overriding HTTP headers & manually send HTTP requests, with a minimalistic “postman-like” tool.
- Show event listener on a page, or on a HTML element, by origin (On what script file the event is declared).
- Dragonfly can be updated asynchronously of the web browser. It is a classic web app launched in a particular level of privileges so it as all the advantages of a real web app.
Let’s be clear, I don’t say than Opera Dragonfly is better than Chromium DevTools. Opera Dragonfly is very old and the fact than some things are still better on Dragonfly VS ChromiumDevTools definitely show than diversity is good.
Of course, if Vivaldi build it own web inspector, as advantages we could also have a lot of new things such as “Disable Javascript on this tab” in QuickCommand. Also, all the web inspector shortcuts could come from Vivaldi Keyboards Settings, which would be great in term of integration.
And finally if Vivaldi built it own DevTools, there is no reason why we should remove Chromium Dev Tools. Let's keep both & use both for a better life of debugging & developing.
-
@Trent said in Vivaldi Web Inspector (Dragonfly revival):
Because Opera Dragonfly had some uniq features which are still not in any browser inspector today.
How true.
Great post !! Well thought out and written.
I am not sure if Dragonfly is part of the proprietary Opera that may be lost to us(?).... -
I am not sure if Dragonfly is part of the proprietary Opera that may be lost to us(?)....
The code is OpenSource on a very permissive Apache License. It is published on Github here, but it is really made to work in Opera Presto. For debugging, Opera Dragonfly used a Opera-Homemade protocol named “Scope” which is not at all equivalent to the implementation of the inspector in Chromium or Gecko (I think).
So we have the source code, but since Presto is deprecated, we can't do much with it. -
@Trent Like Edge, Vivaldi can just adapt the inspector to its own UI. I really hate that V hasn’t changed the chromium UI yet.
And Vivaldi’s edits to the chromium UI could make it more usable
-
@Trent Unfortunate...
-
@Gwen-Dragon Well, me I see only advantages:
- Chrome Devtools will still be accessible, I don't see any reason to remove it.
- Devs will probably have more focus on improving a tool they build, than a huge complex tool build into Chromium, where they will need to contribute to the general project and wait the pull requests and everything.
- If you have bugs in a feature in Chrome Devtools, maybe the same feature in Vivaldi Devtools will not have the same bug
