STR:

1. Open Firefox and then a 2nd window.
2. In first window, open a familiar website.
3. In second window, type a few characters in the address bar, drop-down should appear.
4. Try to interact with first window.

Expected:

• Can scroll.
• Can click, select, copy, etc., and nothing happens in second window (drop-down stays open).

Actual:

• Cannot scroll.
• Clicks in the first window make the second window's drop-down disappear.

I found this because I was starting to type something, but I needed some information that was out of view in another window, but couldn't access it.

Which version of Firefox and OS is this?

Sorry, I assumed that was a "feature", so I didn't think the version&OS were important. Thank you for following up.

Seen on Nightly 69.0a1 (2019-07-04) on Windows 10-64, and Nightly 69.0a1 (2019-06-28) on Mac 10.14.5.

Hm, I'm on Windows 10 and I cannot reproduce this, as soon as I click on the first window the second window address bar panel closes and everything looks normal. There must be something else?
Can you reproduce this problem in a new profile?

(In reply to Marco Bonardo [::mak] from comment #3)

as soon as I click on the first window the second window address bar panel closes

That is my (second) problem! 😅
I think different windows shouldn't influence each other, so clicking on one shouldn't close the other window's address bar panel.

My first problem was that I couldn't even scroll (with the mouse wheel) in the first window while the 2nd window was showing the address bar panel.
Hence my bug title: The panel prevents scrolling in another window. (But feel free to rephrase if not clear.)

And yes, I can reproduce these in a new profile.

Ok, this is an enhancement request, I had misread your report.

You would like a window losing focus to retain its status, included the focused urlbar and open panel.
This will likely require UX, but it may be an acceptable enhancement, unlikely to be prioritized in the team though, unless we collect more feedback about it from other users.

Felt like a defect to me, but enhancement is fine. 🤷‍♂️

I think the most important issue is scrolling, as it doesn't change focus. Note that the "other" browsers handle this just fine.

I'm happy to drop the 2nd request about clicking, as it's less ambiguous, and others also close their address bar panel when clicking in another window.

Mark made me notice scrolling is a bug, though the other things (select/copy/don't close the panel on focus loss) are an enh request, that should be filed apart.

Let's start from bug 1551598, it may actually help here.

Do we know what changed between awesomebar and quantumbar to cause this? I don't see any obvious difference code-wise with regard to the panel. With awesomebar, the panel closes once you start a mouse-wheel scroll. There's a rolluponmousewheel attribute, but I don't think we ever used that.

Adding rolluponmousewheel="true" does fix this fwiw.

Oh wow, this looks like it. nsXULPopupManager checks the "type" attribute of the popup element. If it starts with "autocomplete", rolluponmousewheel is effectively true: https://searchfox.org/mozilla-central/rev/07f7390618692fa4f2a674a96b9b677df3a13450/layout/xul/nsXULPopupManager.cpp#361

We got rid of the type attribute of course. So setting rolluponmousewheel="true" actually seems like the right thing to do.

With awesomebar we got this for free because nsXULPopupManager checks the "type" attribute of the popup element. If it starts with "autocomplete", rolluponmousewheel is effectively true [1]. We got rid of the type attribute in quantumbar since it wasn't otherwise necessary.

[1] https://searchfox.org/mozilla-central/rev/07f7390618692fa4f2a674a96b9b677df3a13450/layout/xul/nsXULPopupManager.cpp#361

Removing the dependency now that we know what caused this. Adding the regression keyword, but it's regressed by quantumbar in general and not a particular bug, so I'm not sure what to set regressed-by to.

https://hg.mozilla.org/mozilla-central/rev/caa7933e91e4

STR

1. Open a page that's long enough to scroll.
2. Type something in the urlbar or click its dropdown arrow, so that its popup opens.
3. Leaving the popup open, move the mouse below the popup and onto the page and scroll with the mouse wheel. The popup should close and the page should scroll.
4. Open another window.
5. Type something in the urlbar or click its dropdown arrow, so that its popup opens.
6. Leaving the popup open and the second window focused, move the mouse back to the page in the first window and scroll with the mouse wheel. The popup should close and the page should scroll.

Comment on attachment 9078291 [details]
Bug 1563617 - Quantumbar: Set rolluponmousewheel="true" so that you can scroll in pages while the popup is open.

Beta/Release Uplift Approval Request

• User impact if declined: This is a regression since 68, so if declined, users would have to wait until 70 for the fix.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Please see comment 16
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): A single-line change that simply adds an attribute to the urlbar popup. This attribute was inferred in versions before 68 but it's not starting in 68, so this patch just makes it explicit.
• String changes made/needed: None

Comment on attachment 9078291 [details]
Bug 1563617 - Quantumbar: Set rolluponmousewheel="true" so that you can scroll in pages while the popup is open.

Fixes an awesomebar regression from 68. Approved for 69.0b6.

https://hg.mozilla.org/releases/mozilla-beta/rev/65d76c6f48b2

Reproduced the reported faulty behavior on 69b5, then proceeded into verifying the issue as follows:

     69.0b6 2019-07-18
     70.0a1 2019-07-19

on:

     Windows 10
     Ubuntu 16.04
     Mac 10.14.5 

Leaving the qe+ for the esr68.

Is this something we should uplift to ESR68 for the 68.1esr release as well? If so, please nominate.

Comment on attachment 9078291 [details]
Bug 1563617 - Quantumbar: Set rolluponmousewheel="true" so that you can scroll in pages while the popup is open.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: It's a very small, simple fix to a small annoyance with the new quantumbar in 68.
• User impact if declined: Scrolling the current web page with the mouse wheel while the quantumbar panel is open will not work -- nothing will happen.
• Fix Landed on Version: 69
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): All this does is add a single rolluponmousewheel="true" attribute to the quantumbar panel. With the old awesomebar, that attribute was implied so we didn't need to specify it. I tested the patch manually on esr68.
• String or UUID changes made by this patch: None

Comment on attachment 9078291 [details]
Bug 1563617 - Quantumbar: Set rolluponmousewheel="true" so that you can scroll in pages while the popup is open.

Fixes an annoyance with the awesomebar. Approved for 68.1esr.

https://hg.mozilla.org/releases/mozilla-esr68/rev/4dd26f6454d9