User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

This is relating to the megabar that becomes swol when you select it. When you open the options screen it gains focus and becomes swol, however clicking away from it (by clicking on blank space within the page) does not remove focus from the tab bar.

Actual results:

The megabar becomes swol and seems to become stuck like that. Clicking on other UI elements largely does not cause it to lose focus, with the only way to clear its state to switch tabs or click on another text input.

Through my own testing, I've noticed the following affected areas:
about:preference

It also does not lose focus when clicking on the hamburger menu and the bookmarks menu. (the library menu works as expected)

Expected results:

Clicking anything other than content inside the megabar should cause it to lose focus.

I said "tab bar" but I actually meant "megabar". Sorry, I've no way I can see to edit the description.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

So, not all the clicking targets are expected to unfocus the urlbar (the hamburger menu button probably should not unfocus it), but about:preferences looks really strange, so there should be space for improvement here.

(In reply to Marco Bonardo [:mak] from comment #3)
So, not all the clicking targets are expected to unfocus the urlbar (the hamburger menu button probably should not unfocus it)

Would it be possible to know the rationale behind that decision? For me, if the user click on any other item in the UI that can be focused like the hamburger menu then that new focused item should be the only one focused no?

(In reply to Danny Colin [:sdk] from comment #4)

(In reply to Marco Bonardo [:mak] from comment #3)
So, not all the clicking targets are expected to unfocus the urlbar (the hamburger menu button probably should not unfocus it)

Would it be possible to know the rationale behind that decision? For me, if the user click on any other item in the UI that can be focused like the hamburger menu then that new focused item should be the only one focused no?

Clicking the hamburger menu doesn't focus it. It never did. Focus doesn't work like that.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e6fa62187db798c6c58c2bf973cc453768047b67&tochange=8b79d4ccb76e0a85a1f9de2933b4c16665065c82

(In reply to Dão Gottwald [::dao] from comment #5)

(In reply to Danny Colin [:sdk] from comment #4)

(In reply to Marco Bonardo [:mak] from comment #3)
So, not all the clicking targets are expected to unfocus the urlbar (the hamburger menu button probably should not unfocus it)

Would it be possible to know the rationale behind that decision? For me, if the user click on any other item in the UI that can be focused like the hamburger menu then that new focused item should be the only one focused no?

Clicking the hamburger menu doesn't focus it. It never did. Focus doesn't work like that.

As a user who also spends a lot of time working UI design: I think it kinda should.

Even if it doesn't, and that's by design, the hamburger menu presents like a button, and I see no difference between it and the downloads button (which does take focus from the megabar).

Likewise, I've also identified the file/edit/view buttons with the same issue. Clicking them doesn't remove focus from the megabar.

(In reply to Sollace from comment #7)

(In reply to Dão Gottwald [::dao] from comment #5)

(In reply to Danny Colin [:sdk] from comment #4)

(In reply to Marco Bonardo [:mak] from comment #3)
So, not all the clicking targets are expected to unfocus the urlbar (the hamburger menu button probably should not unfocus it)

Would it be possible to know the rationale behind that decision? For me, if the user click on any other item in the UI that can be focused like the hamburger menu then that new focused item should be the only one focused no?

Clicking the hamburger menu doesn't focus it. It never did. Focus doesn't work like that.

As a user who also spends a lot of time working UI design: I think it kinda should.

Likewise, I've also identified the file/edit/view buttons with the same issue. Clicking them doesn't remove focus from the megabar.

Cut/Copy/Paste menus would not work if clicking a menu changed focus - so opening menus doesn't change focus. This is also the case on e.g. macOS where the toplevel menu is OS-implemented, for instance, and although I don't have Windows to hand, I'd be stunned if this behaved differently on, say, MS Word, as it would break basic interaction patterns.

Even if it doesn't, and that's by design, the hamburger menu presents like a button, and I see no difference between it and the downloads button (which does take focus from the megabar).

There's some different behaviour in some of these panels for various reasons, but this bug got filed about the preferences / content window, so let's keep it focused on that. I'm pretty sure there are already bugs on file for the focus behaviour of the panels and they predate any changes to the location bar.

The about:preferences behaviour also reproduces on some empty parts of about:addons (e.g. the bottom of the category list near the links pointing to preferences - but not everywhere, presumably because some content page JS calls .focus() somewhere). So I'm moving this out of preferences.

Note that this isn't really a regression, either - the same behaviour occurs on beta. It's only the address bar that's changed. So I'm punting this back to address bar folks to figure out what they want to do here. I don't think changing the prefs to more aggressively call .focus() is going to help.

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

Note that this isn't really a regression, either - the same behaviour occurs on beta.

That doesn't mean it's not a regression. I assumed it broke earlier, but it's also possible it's always been broken.

It's only the address bar that's changed. So I'm punting this back to address bar folks to figure out what they want to do here. I don't think changing the prefs to more aggressively call .focus() is going to help.

We're not going to do anything about this in the address bar. We should fix whatever is preventing these pages from taking focus.

The priority flag is not set for this bug.
:bgrins, could you have a look please?

For more information, please visit auto_nag documentation.

This is at least partly because of the * { -moz-user-focus: ignore; } rule at https://searchfox.org/mozilla-central/rev/053826b10f838f77c27507e5efecc96e34718541/toolkit/content/minimal-xul.css#24 - if I remove that rule then the address bar blurs when clicking around in about:preferences. I don't think we'd want to make a universal change like that since it could have side effects with focus in-content for stuff like scrollbars. And possibly in various chrome UI as well).

FWIW, some elements get -moz-user-focus set to normal at https://searchfox.org/mozilla-central/rev/053826b10f838f77c27507e5efecc96e34718541/toolkit/content/xul.css#87-96, and the initial value is none if nothing is set.

Perhaps adding -moz-user-focus: none to https://searchfox.org/mozilla-central/rev/053826b10f838f77c27507e5efecc96e34718541/browser/themes/shared/incontentprefs/preferences.inc.css#36 would work and be a more targeted fix. Though really we'd want to exempt the elements in the xul.css list above (button, checkbox, menulist, ...) because otherwise they would be switched from normal to none.

Though, I wonder at root this is really a remote vs non-remote browser difference. Because if I load data:text/html,<html><style>* { -moz-user-focus: ignore; }</style>test</html> and click on the text then the address bar blurs. So maybe there's something that could be done to make non-remote browsers act as if they were remote.