As long as the user is just interacting with the search box the search popup should stay open. There are two issues here. First since we don't want to use noautohide, any outside click, even on the textbox attempts to close the popup. That might not be a big problem because we could just keep the popup open in a click handler on the textbox, but because the textbox is the anchor for the popup any clicks there are always consumed regardless of consumeoutsideclicks (http://mxr.mozilla.org/mozilla-central/source/layout/xul/nsXULPopupManager.cpp#205) so the caret neither moves nor do we see an event to keep the popup open with.

Neil, this seems like it might be up your alley, want to take it? I'm guessing that we might want a new attribute on panels to be able to say that clicks on the anchor shouldn't be consumed and cause rollup but you know the popup code better than me. If that is the way to go it might be worth using the same attribute to skip over the call to handleKeyNavigation that is the problem in bug 1114707.

This patch applies on top of the one in bug 1089005.

This is a better version which excludes the fix for bug 1114707.

Comment on attachment 8544002 [details] [diff] [review] Add an attribute to allow clicks on the anchor to not close the popup The C++ changes work but you might need further review on the browser changes with particular reference to the handling of clicks on the magnifying glass.

Comment on attachment 8544002 [details] [diff] [review] Add an attribute to allow clicks on the anchor to not close the popup Felipe, see above comment.

Comment on attachment 8544002 [details] [diff] [review] Add an attribute to allow clicks on the anchor to not close the popup Review of attachment 8544002 [details] [diff] [review]: ----------------------------------------------------------------- Strangely, I had added a comment together with that review, but it somehow got lost. Here it is again: ::: browser/components/search/content/search.xml @@ +871,5 @@ > // but since we're overriding openPopup we need to unhide the panel > // ourselves. > popup.hidden = false; > > + popup.setAttribute("norolluponanchor", "true"); The popup being used here is always PopupSearchAutoComplete? If yes, then there is no need to clean up this attribute. But if it was the previous PopupAutoComplete, which is shared between the searchbar and formfill in content, we would need to do it. The comment above says PopupAutoComplete, so let's update it to say the proper id name.

Verified as fixed using Nightly 38.0a1 2015-02-08 under Ubuntu 12.04 LTS 32-bit, Windows 7 64-bit and Mac OS X 10.9.5.