Steps to reproduce:

• Open any page or a new tab.
• Click the address bar so that it opens and shows all the top sites.
• Click in an empty space in the tab bar or the bookmarks bar.

Actual result:

The address bar doesn't close. It only closes if you click a button or a menu item.

Expected result:

The address bar should close and not show any top site nor search result when you click in an empty space in the tab bar or the bookmarks bar, just like the search bar does.

Additional notes:

The search bar, the hamburger menu, every other button in the toolbars, and the titlebar menu items close when clicking any empty space in any of the toolbars, whereas the current address bar doesn't, making it's behaviour inconsistent with the rest of the interface.

A possible user case would be copying a link from the address bar to update a bookmark manually, and having the search suggestions or the top sites blocking the bookmark bar visibility, which wouldn't be able to be closed like any other popup element in the toolbar.

When the user wants to close the popup to access the bookmarks in the bookmarks bar they either have to click the search bar, the web area (which may incur in misclicks for the user being focused on the bookmark editting and just wanting to get rid of the popup) or click any button they have in the toolbar, which would require the user to click more times (to close the popup that the other buttons may generate).

Clicking on the empty space on the bookmarks toolbar closes the results list for me. The tabbar doesn't.
Could you please check again if the bookmarks toolbar works for you or not?

Neither on the tab bar nor the bookmarks toolbar empty spaces makes it close the suggestions popup, it only hides it when clicking any toolbar button, right clicking anything, or clicking the web area.

These are the things I tried:

• On Windows 10, 1909, with my normal profile, the issue was first tested here.
• Tried on another computer that has W10 1809, same results.
• Restarted Firefox in safe mode, same results (Windows 10 1809).
• Creating a new empty profile, same results (Windows 10 1809).
• Asked a friend that has Windows 10 1803, and he says the bookmarks does close it, but the tab bar doesn't.
• Tested on Kubuntu 18.04 on a VM, the issue wasn't present.
• Tested on Mac OS Catalina (10.15) on a VM, the issue wasn't present.

So I guess it's a Windows-only issue that gets worse on 1809 at least (in 1803 still doesn't work on the tab bar empty spaces, but at least works on the bookmarks).
I'll add an apng attachment to preview the testing in a new empty profile (w10 1809).

I am testing on Windows 10 1909 as well, and the bookmarks toolbar still closes the panel for me, I can't explain this difference.
But maybe it's because I'm using Nightly.

After some more testing I found that when having overflowing bookmarks the in bookmarks toolbar (enough for the ">>" button to appear) the popup DOES hide when clicking the empty space between the last bookmark and the ">>" button, but if your bookmarks don't overflow and fit in less than 1 row, the suggestions popup won't hide when clicking an empty space in it.

This would explain why it's working for my friend (he has more than 1 row of bookmarks), and I assume this might be your case as well?

It also won't hide when clicking a flexible space (as shown in the attachment).

I just tested on Nightly (version 77.0a1 (2020-04-09) (64-bit)), on Windows 10 1909 and the issue persists.
Also tried in safe mode on nightly, but same thing.

Since it seems that the bookmarks space wasn't working for me on my regular computers I also tested with Firefox Stable on an old laptop that I had with Windows 7 which barely has any other program installed apart from Firefox (to avoid any possible interference of third party programs like third party antivirus), but it still had the issue for both the tab bar and the bookmarks toolbar.

I guess this is applicable to all Windows versions and not just W10.

(In reply to ipasc91 from comment #4)

After some more testing I found that when having overflowing bookmarks the in bookmarks toolbar (enough for the ">>" button to appear) the popup DOES hide when clicking the empty space between the last bookmark and the ">>" button, but if your bookmarks don't overflow and fit in less than 1 row, the suggestions popup won't hide when clicking an empty space in it.

This would explain why it's working for my friend (he has more than 1 row of bookmarks), and I assume this might be your case as well?

Yes, it's also my case. Thank you for figuring that out.

I think window dragging is interfering here.

Yep, tested disabling window draggability on both stable and nightly through userChrome with:

#tabbrowser-tabs, #PlacesToolbar {
    -moz-window-dragging: no-drag;
}

...and the dropdown will hide correctly when clicking the empty area in those.

I'm not sure whether there's a way to detect window-dragging intercepting mouse events, it would be nice if platform could fire a custom event so things like the urlbar panel can react. Or we could unset window-dragging when the panel is open, though that would probably break dragging in a single operation.

Resetting severity to default of --.

Neil, do you know if there is a way to get an event (even a custom one) when there's a mousedown on the toolbar that is eaten up by the window dragging code?

I assume this is a Windows-only bug. I looked at what messages are being sent to the window in this case. No dom event will be sent as the click was on the titlebar area. Windows sends a different message WM_NCLBUTTONDOWN for this. A normal popup will close as a result of the mouse button press in nsWindow::DealWithPopups. Otherwise, we don't handle this windows message. So some kind of response would need to be put in here.

I've considered the possibility of adding some event in-between here that could ask whether popups should close. Adding this might be the best option. Or perhaps, just an event firing when clicking in the titlebar area. Does it need to be a real mouse event or is it sufficient to just have some custom event?

Another possibility is just create a custom nsIRollupListener implementation.

(In reply to Neil Deakin from comment #12)

I've considered the possibility of adding some event in-between here that could ask whether popups should close.

That'd be great, though I must note that the urlbar is no more a popup, we need some kind of event that the urlbar can listen to and close itself.

Does it need to be a real mouse event or is it sufficient to just have some custom event?

We can listen to whatever, I think it doesn't matter it being a real mouse event. Our problem is just closing the urlbar panel when there's a mousedown in the dragging area. Of course a normal mousedown event would allow to share code with the other platforms.
This is the code doing it right now:
https://searchfox.org/mozilla-central/rev/df4c90d4b8c92c99f76334acfe4813c573c12661/browser/components/urlbar/UrlbarInput.jsm#2042-2057

Another possibility is just create a custom nsIRollupListener implementation.

Yes, we could also register our own custom nsIRollupListener and close the urlbar from it. That'd need all the xpcom wrapping though, so it seems more work than just firing an event.

I noticed that we handle WM_NCMBUTTONDOWN
https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/widget/windows/nsWindow.cpp#5732-5736
This was done indeed to support opening a new tab in the same area.
I wonder if we couldn't just handle WM_NCLBUTTONDOWN the same way. I can try and see if something obvious breaks.

On other platforms we get a mousedown event when the non-client area is clicked,
but not on Windows, where handling the WM_NCLBUTTONDOWN message breaks dragging
the window. This dispatches the mousedown event like other platforms, but on
the next tick.

I'll see if I can write a test, and then eval uplifting, it seems an annoyance that'd be nice to have fixed in ESR.

https://hg.mozilla.org/mozilla-central/rev/cb3bea25854a
https://hg.mozilla.org/mozilla-central/rev/9e688ade8790

I asked dluca to backout these changes. It sounds like mousedown in the ncl area has too many implications with other things in the same area... We may have to go with a custom event.

Backed out 2 changesets (bug 1628948) as requested by dev.

Backout:
https://hg.mozilla.org/integration/autoland/rev/92df7c0f022dee60abcb7a429fe9013bb84aa1dd

I was asked by Marco to backout this bug because it was causing regressions.

This bug should be reopened if it's backed out.

https://hg.mozilla.org/mozilla-central/rev/b78a8d72ed9d
https://hg.mozilla.org/mozilla-central/rev/0b16eb769825

Verified with Firefox 79 beta 3 and Nightly 80.0a1 2020-07-02 under Win 10 64-bit and noticed that:

• urlbar panel is closed when clicking on menu bar, toolbar and bookmarks bar, but megabar remains focused/expanded
• urlbar panel doesn't close when clicking on Title Bar (enabled from Customize Menu)

(In reply to Petruta Horea [:phorea] from comment #25)

Verified with Firefox 79 beta 3 and Nightly 80.0a1 2020-07-02 under Win 10 64-bit and noticed that:

• urlbar panel is closed when clicking on menu bar, toolbar and bookmarks bar, but megabar remains focused/expanded
• urlbar panel doesn't close when clicking on Title Bar (enabled from Customize Menu)

These are expected for now, the title bar is a different entity and an edge case.
The megabar is not supposed to lose focus unless the focus is moving to a different widget.

Yep, it's working as intended now on both stable (79) and nightly (81 2020-07-28).
Thank you all for the fix!