[EdSharkey]

> .. the current Debugger tool which has a better interface

Respectfully, I disagree. The debugger tool's search in files is klunky with the bang prefix required to search all files and the search results shown in a scrollable popunder panel. Search should operate over all files/nodes in the current tab's category by default. And, it is bad UX for a tool that itself is (usually) a docked panel in the main browser window to have temporary panes appear that crowd out or obscure their neighbors. You've already got a file tree on the left, why not make that a twisty tree and categorize the search results under their parent files there - that is, if you feel your developers must have fancy clicky bits.

For those interested, here's some related bugs to look at:

Can't search in multiple sources in the Style Editor https://bugzilla.mozilla.org/show_bug.cgi?id=889571 (4 years old)

Firebug gaps https://bugzilla.mozilla.org/show_bug.cgi?id=991806 (3 years old)

The comments in that Firebug gaps ticket hurt me to read. Firebug got shanked by you guys like over a year ago and Developer Tools aren't close to feature parity.

Dear Firefox product owners: developer tools have to be great for the boring use cases -AND- the sexy HTML5 debugging use cases. Please put more resources into the Firebug gaps ticket and knock that one out.

[wldcordeiro]

When they said "current debugger tool" they were referring to this Debugger[0].

[0] https://github.com/devtools-html/debugger.html

[EdSharkey]

There's lots of great UX enhancements there! I'm so looking forward to this!

Is this really the "current debugger tool" though? It doesn't ship with Firefox yet, does it? It's vaporware to users until it's displayed in developer tools and WebIDE.

I really wish this new Debugger would not show search results as a popunder/panel replacement the way that devtools does though! You have a massive amount of precious screen real estate in the debugger already devoted to the script sources panel. Why wouldn't you just cycle through matches in the actual script sources where the most characters surrounding each search result can be viewed by the user? Not only is using the script sources as the viewer for search results simpler to code, but the user is not taken out of the flow of their script editor/viewer in order to cycle through the results they've requested. What's the usecase that is being satisfied by breaking the user out of the script editor here?