STR:

1. Open Firefox and maximize it so it covers the whole screen (no full screen though)
2. Open a second Firefox window (in the same profile) private or non-private and move this window so that just about 1/4 of it is still visible at the bottom of your screen
3. Start typing in words in the search bar of the second window

Expected results:
Firefox lists the results within the second window

Actual results:
Firefox lists the results outside of the second window and overlaps the first one.

Additional information:
I'm not quite sure if this behaviour is due to the Awesome Bar but I can't reproduce it with Firefox 66.

could you please check in about:config if you have a "quantumbar" pref set to true? (Or you may be involved in the quantumbar experiment currently active in Nightly)

Hi Marco, not it's not, sorry to that I not made that clear in the initial description. browser.urlbar.quantumbar is false

Mark, could you please check this behavior on Mac, related to both QB and AB? I'll be away next days and I'm interested in understanding if QB acts properly or not.

On 68.0a1 (2019-04-23) I can reproduce this only with browser.urlbar.quantumbar set to true, i.e. QuantumBar enabled. The behaviour in the overlap case is bad, as it also covers up the address bar, so you don't know where you're going to end up if you press enter.

With just the standard awesomebar, I can't reproduce this.

Tagging this as potentially blocking the release for now.

Patrick, could you re-check the behaviour please? You shouldn't have to restart in-between toggling the pref, but it might be best just to test.

Forgot to open a new window... Sorry, my bad.
I'm only able to reproduce the issue with browser.urlbar.quantumbar set to true,.

Can't reproduce on Windows and Linux.

AFAIK flip="none" is supposed to prevent this behavior and we already set that here:
https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/browser/components/urlbar/UrlbarInput.jsm#65

Enn, any idea why that doesn't work?

One thing to point out is that not only the flip attribute can affect this behavior, but offsets from openPopup can too:
https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/layout/xul/nsMenuPopupFrame.cpp#1513

The old awesomebar used an offset: https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/browser/base/content/urlbarBindings.xml#2235

The new implementation doesn't: https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/browser/components/urlbar/UrlbarView.jsm#379

So maybe that makes a difference? Though again, with flip="none" set, that shouldn't really be the case.

Does it work if you disable nsCocoaWindow::FitRectToVisibleAreaForScreen?

(In reply to Neil Deakin from comment #11)

Does it work if you disable nsCocoaWindow::FitRectToVisibleAreaForScreen?

Yeah, it does.

Tentatively moving this to Widget::Cocoa since we seem to be doing the right thing in the front-end and this bug doesn't reproduce on Windows or Linux.

Probably we shouldn't be calling FitRectToVisibleAreaForScreen for certain popups.

This is a new problem with the new address bar implementation which targets 68. Can this prioritized higher? While we could potentially work around this in the front-end somehow, it would be better if the underlying bug got fixed.

Taking a look.

I just built Firefox (debug and optimized) with the 10.11 SDK on macOS 10.13, but the URL bar doesn't work. Suggestions don't appear while typing and unless I type a chrome URL, I can't hit enter to navigate to the URL. Only about:config and similar URLs work. This happens with the "quantumbar" pref set to true and false.

I will have to figure out what's going on with my local builds before I can look into this. Unassigning myself until I've been able to fix this.

Restoring needinfo to make sure this doesn't get lost.

See the suggestion in bug 1551598.

I rebuilt my local build with the 10.13 SDK and I now have a working, local build. A few observations so far:

1. With quantum bar disabled, I can intermittently reproduce the popup appearing on top of the URL bar. However, after appearing in the wrong place for a split second, it immediately moves and appears in its expected position.
2. I am only able to reproduce this issue on a screen that does not have the macOS menu bar or the Dock. This is true for both the quantum bar and the issue described in point 1 above.
3. In the broken case, I can see continuous and repeated calls to nsCocoaWindow::DoResize. This does not happen when the popup appears in the correct location, be that with quantum bar enabled or disabled.
4. Not calling FitRectToVisibleAreaForScreen does not seem to be the right solution, since the rect appears to be calculated correctly (or at least not more incorrectly than in the working cases). The reason why skipping this call appears to work is because we don't end up calling [mWindow setFrame:newFrame display:YES]. It would seem best to figure out why we have these continuous calls to nsCocoaWindow::DoResize and fix that.
5. The window level of the popup has not changed between the old style popup and the quantum bar popup, so this should not be a reason why the popup starts appearing on top of the URL bar.

I would like to take a look at how the quantum bar was implemented. If someone could point me to a bug or place in our code, that would speed things up.

I can confirm that my Dock is not visible during the time the issue appeared.

(In reply to Stephen A Pohl [:spohl] from comment #20)

I would like to take a look at how the quantum bar was implemented. If someone could point me to a bug or place in our code, that would speed things up.

The relevant code is in UrlbarInput.jsm and UrlbarView.jsm, see also the pointers in comment 10.

I've spent a considerable amount of time on this but have yet to find a clear answer to what is going on. If we don't adjust the y-coordinate in FitRectToVisibleAreaForScreen[1], things work as expected. However, the y coordinate is also wrong if the browser is on a screen that displays the macOS menu bar and the dock. It would therefore seem like the popup should appear incorrectly there as well, but it doesn't.

I have been tracing all the calls to nsMenuPopupFrame but have yet to unearth a meaningful difference between the two URL bar implementations.

I will continue to look into this as time permits. Leaving n-i set.

[1] https://searchfox.org/mozilla-central/rev/f4c39907e0b527dc4b9356a1eeb8c6e6c62d383a/widget/cocoa/nsCocoaWindow.mm#256

Is there no particular urgency here anymore, since bug 1551598 got fixed?

I'm no longer able to reproduce this bug in a new profile with browser.urlbar.quantumbar set to true on a 2019-07-31 Nightly build.

Yes, I think this can't happen anymore.

(In reply to Stephen A Pohl [:spohl] from comment #24)

Is there no particular urgency here anymore, since bug 1551598 got fixed?

No.

(In reply to Marco Bonardo [::mak] (Away 7-25 Aug) from comment #26)

Yes, I think this can't happen anymore.

Pretty sure it can because it's a cocoa widget bug. It just can't happen with the address bar anymore.

I'm sorry, I missed that we moved this bug to platform.

Bugbug thinks this bug is a regression, but please revert this change in case of error.