From https://www.reddit.com/r/firefox/comments/eqy7wf/firefox_fullscreen_f11_does_not_auto_hide/

Steps to reproduce:

1. Open Firefox.
2. Open a web page
3. Enter full screen (F11)
4. Use Ctrl-l to open address bar, navigate to any URL

What happens:

The addressbar does not autohide.

Expected result:

The address bar should autohide.

12:55.13 INFO: No more inbound revisions, bisection finished.
12:55.13 INFO: Last good revision: 12d4df6de36eaae416b024531d12eb8ee802835c
12:55.13 INFO: First bad revision: 2e388d4237d0473f6e14f4218290d54857be84d6
12:55.13 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=12d4df6de36eaae416b024531d12eb8ee802835c&tochange=2e388d4237d0473f6e14f4218290d54857be84d6

[Tracking Requested - why for this release]: Regression in user facing full screen feature.

We're not going to be able to fix this in a dot-release for 72 anymore; 73 comes out in 2 weeks.

Seems like bug 1477525 was a previous incarnation of this problem given bug 1195927 and all its dupes.

Dão, can you take a look given you reviewed the patch there and wrote the regressing patch?

I'd take a low-risk for Fx73 still, but not tracking since it's been around since 68 and we're already getting late in the Beta cycle.

I'm not sure how exactly bug 1554158's patch would have caused this, and reverting that change doesn't seem to help...

We should look at this soon since it sounds like it makes full-screen mode pretty unusable? Has this really been around since 68?

Drew, any news on this one? Is that something we should worry about for 74? Is that still a P2? Thanks

If this has really been a problem since 68, I don't think it really needs to track 74, but we should look at it soon. I'll take it and see if I can reproduce it.

Oh, I misunderstood this. I thought this bug was about the urlbar view/panel not hiding, but it's about the entire top chrome of the window not sliding off the screen. This doesn't need to be a P2 and I'm even more convinced it doesn't need to track 74, but I'll see if I can figure out what's going. It doesn't seem like it would have to do with the urlbar per se.

The regression range in comment 0 isn't right. This is due to bug 1551598, not bug 1554158, but I'm not sure why yet. It looks like it may be because browser-fullScreenAndPointerLock.js uses a popuphidden listener to hide the nav toolbox. This goes back to 70, not 68. Updating bug info accordingly.

This fixes it. I'll work on a test tomorrow. Looking back to older builds though, there seems to be something else that changed. In very old builds, the nav box went away after you hit enter in the urlbar. In more recent builds (before bug 1551598), it goes away after you click a link in the page you loaded. This patch restores that latter behavior.

OK, the regression range in comment 0 is the other half of the story, sorry for saying it was wrong. There's a keypress listener in FullScreen that receives a keypress event from the urlbar, and that's what should hide the nav box right after you press enter. Bug 1554158 broke that by calling event.preventDefault() on the event, so it doesn't reach the listener. The reason I was seeing the nav box hide after clicking a link, after fixing the popup problem, is that there's also a click listener on the window.

Bug 1554158 does indeed go back to 68

Two fixes:

• The urlbar view isn't a popup anymore, so FullScreen should listen for onViewOpen and onViewClose on the urlbar controller instead of popup events.
• The urlbar now consumes enter keypresses, so FullScreen needs some other way to know when text has been entered or a result has been picked. UrlbarView.close already takes an elementPicked param, so pass that to onViewClose listeners.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ba968c8b360928f3b1e13b62f97250d1f274461

Drew, just in case, any idea if/how this is related to bug 1219775?

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

(In reply to :Gijs (he/him) from comment #15)

Drew, just in case, any idea if/how this is related to bug 1219775?

Sorry for not replying sooner, it took a while to figure out this bug. No, bug 1219775 doesn't seem to be related to this bug. I'll comment over there.

https://hg.mozilla.org/mozilla-central/rev/8f18cb0e10ff

Please nominate this for Beta approval when you're comfortable doing so.

Comment on attachment 9125209 [details]
Bug 1610200 - In full screen, properly hide the toolbars after the user picks a result in the urlbar.

Beta/Release Uplift Approval Request

• User impact if declined: In full screen on Windows, when the user presses the enter key in the urlbar, the top window chrome will incorrectly remain on the screen.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Please see comment 0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small patch, has test, changes not likely to affect anything else
• String changes made/needed:

Reproduced the initial issue in Beta 74.0b4 (Build id: 20200216164042) using Windows 10.
Verified - Fixed in latest Nightly 75.0a1 (Build id: 20200216210001) using Windows 10 and Ubuntu 18.04.

Comment on attachment 9125209 [details]
Bug 1610200 - In full screen, properly hide the toolbars after the user picks a result in the urlbar.

Fix for a UX bug on Windows, verified on Nightly, uplift approved for 74?0b5, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/9886ef72fd07

Verified - Fixed in latest Beta 74.0b5 (Build id: 20200218224219) using Windows 10 and Ubuntu 18.04.