Right now, the only way of closing the global search pane is to press ESCAPE or delete what's entered in the "Filter Scripts" searchbox. Let's either add a close button, or hide the search pane when loosing focus.

Try: https://tbpl.mozilla.org/?tree=Try&rev=19fe5eeabd68

Comment on attachment 655436 [details] [diff] [review] v1 Rob's leaving!

Comment on attachment 655436 [details] [diff] [review] v1 Review of attachment 655436 [details] [diff] [review]: ----------------------------------------------------------------- Nice polish. The only confusing thing that I noticed is that clicking on the empty stack pane would not make the results go away. ::: browser/devtools/debugger/debugger-view.js @@ +263,5 @@ > /** > + * True if the search results container is hidden. > + * @return boolean > + */ > + get hidden() this._pane.hidden, <3 ::: browser/devtools/debugger/test/browser_dbg_scripts-searching-08.js @@ +12,5 @@ > +var gScripts = null; > +var gSearchView = null; > +var gSearchBox = null; > + > +function test() How about a comment explaining the purpose of the test? @@ +43,5 @@ > + > + function runTest() > + { > + if (scriptShown && framesAdded) { > + Services.tm.currentThread.dispatch({ run: testScriptSearching }, 0); executeSoon would be shorter...

(In reply to Panos Astithas [:past] from comment #4) > Comment on attachment 655436 [details] [diff] [review] > v1 > > Review of attachment 655436 [details] [diff] [review]: > ----------------------------------------------------------------- > > Nice polish. The only confusing thing that I noticed is that clicking on the > empty stack pane would not make the results go away. tl;dr It's a feature. Hmm, I think it's to be expected. Clicking on a stackframe has a high chance of changing the currently shown script, or at least move the caret to a different line number, which will effectively make the currently highlighted search result useless. Even more, I think you can safely assume that clicking on a stackframe means "show me where this happened in the source", and you'd want to see as much context as possible. The global search pane occupies quite a lot of space. > > ::: browser/devtools/debugger/debugger-view.js > @@ +263,5 @@ > > /** > > + * True if the search results container is hidden. > > + * @return boolean > > + */ > > + get hidden() this._pane.hidden, > > <3 > I love js. > ::: browser/devtools/debugger/test/browser_dbg_scripts-searching-08.js > @@ +12,5 @@ > > +var gScripts = null; > > +var gSearchView = null; > > +var gSearchBox = null; > > + > > +function test() > > How about a comment explaining the purpose of the test? > Ok. I'll add a comment in all other related tests to keep things consistent. > @@ +43,5 @@ > > + > > + function runTest() > > + { > > + if (scriptShown && framesAdded) { > > + Services.tm.currentThread.dispatch({ run: testScriptSearching }, 0); > > executeSoon would be shorter... Consistency...

(In reply to Victor Porof [:vp] from comment #5) > (In reply to Panos Astithas [:past] from comment #4) > > Nice polish. The only confusing thing that I noticed is that clicking on the > > empty stack pane would not make the results go away. > > tl;dr It's a feature. > > Hmm, I think it's to be expected. Clicking on a stackframe has a high chance > of changing the currently shown script, or at least move the caret to a > different line number, which will effectively make the currently highlighted > search result useless. Even more, I think you can safely assume that > clicking on a stackframe means "show me where this happened in the source", > and you'd want to see as much context as possible. The global search pane > occupies quite a lot of space. Er, that actually sounds like an argument for fixing this then :-) Note that the behavior I observed was that clicking on the (in my case empty) stack list didn't hide the results.

(In reply to Panos Astithas [:past] from comment #6) > (In reply to Victor Porof [:vp] from comment #5) > > (In reply to Panos Astithas [:past] from comment #4) > > > Nice polish. The only confusing thing that I noticed is that clicking on the > > > empty stack pane would not make the results go away. > > > > tl;dr It's a feature. > > > > Hmm, I think it's to be expected. Clicking on a stackframe has a high chance > > of changing the currently shown script, or at least move the caret to a > > different line number, which will effectively make the currently highlighted > > search result useless. Even more, I think you can safely assume that > > clicking on a stackframe means "show me where this happened in the source", > > and you'd want to see as much context as possible. The global search pane > > occupies quite a lot of space. > > Er, that actually sounds like an argument for fixing this then :-) > Note that the behavior I observed was that clicking on the (in my case > empty) stack list didn't hide the results. Huh, I thought that was happening already. Let's followup since it's a relatively mild improvement.

Addressed comments.