1689200 - Address bar focus state seems to persist unnecessarily

Status: NEW

(Firefox :: Address Bar, enhancement, P3)

Description

[Aaron Benson]

STR

Give the address bar focus and then either a) click the toolbar or b) open a menu (e.g. the application menu). The address bar remains in focus when it should probably return to its unfocused state much as it does if you click in the web content area of a page.

Comment 1

[Harry Twyford]

The new address bar originally had a state where it was focused but not expanded, but that introduced too many engineering challenges to warrant keeping and we ultimately removed it in bug 1589826.

I see you're suggesting we unfocus the address bar entirely when browser chrome is clicked. This would probably be less complicated. However, a couple things would break: users wouldn't be able to open the hamburger menu then keep typing in the address bar, and they also wouldn't be able to click the address bar, refresh the page, and then keep typing. These don't seem like big losses to me – honestly, the existing behaviour feels buggy. I'm curious for Dao's thoughts on this.

Comment 2

[Marco Bonardo [:mak]]

I think there was a bug on file about closing the urlbar panel when other panels open. Maybe bug 1626741?

Comment 3

[Drew Willcoxon :adw]

I agree with Harry. As far as I know, clicking chrome outside the urlbar has never unfocused it, it's just way more noticeable now that it's also expanded when focused. So it's hard to call this a defect IMO, and I'll change the bug type accordingly. Feel free to change it back and/or the priority.

Comment 4

[Dão Gottwald [:dao]]

What Drew said.

Comment 5

[Harry Twyford]

Duped from Jira:

Currently, Firefox remembers Urlbar-focus states per tab. For example, consider a user who has two tabs open. In Tab 1, they click the address bar, focusing it. Then they click Tab 2. The address bar is not focused in this tab. When they switch back to Tab 1, the address bar will re-focus, since it was previously focused in that tab. If they had an unfinished search in that tab (i.e., they typed something in the address bar then abandoned it), we will also re-open the address bar panel so they can continue that search.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1689200, we specify that we should blur the address bar after all clicks outside it. As it stands, this would break the per-tab focus-retention described above, since the click on Tab 2 is a click outside the address bar. We'd thus unfocus the address bar in Tab 1 before switching to Tab 2. When the user returns to Tab 1, we wouldn't re-focus the address bar since it was unfocused before.

Comment 6

[Marco Bonardo [:mak]]

Clicking on unselected tabs should probably not blur.

Comment 7

[Dão Gottwald [:dao]]

Edit menus were already mentioned as well as a problematic case. I'm afraid there could be more edge cases, and adding exceptions would make the behavior less consistent and predictable. It's therefore still questionable to me whether we should do this at all.

Comment 8

[Marco Bonardo [:mak]]

We can check where the click originated, it should be trivial to either exclude some target, or only include some targets.
For example I think clicking anywhere on the nav-bar (modulo the urlbar box) and bookmarks-toolbar would cover most of the UX expectations.

Comment 9

[Marco Bonardo [:mak]]

Thinking about the Edit menu, I guess you mean the AppMenu button edit target? That's a good question for UX indeed.

Comment 10

[Marco Bonardo [:mak]]

Ah, it looks like Proton is removing the Edit part from the AppMenu, so it may not be a problem for the address bar.

Comment 11

[Dão Gottwald [:dao]]

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

We can check where the click originated, it should be trivial to either exclude some target, or only include some targets.
For example I think clicking anywhere on the nav-bar (modulo the urlbar box) and bookmarks-toolbar would cover most of the UX expectations.

I already acknowledged that we can add exceptions, so it's not a question of what we can do. What I'm saying is that exceptions make the behavior less consistent and predictable, and we might miss cases. In fact, even if there were no exceptions, making this change would make the address bar itself an exception because other text fields in chrome don't behave like that.

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

Ah, it looks like Proton is removing the Edit part from the AppMenu, so it may not be a problem for the address bar.

There's still the menu bar's Edit menu.

Comment 12

[Marco Bonardo [:mak]]

Yes but my suggestion was to do this only on nav-bar and PersonalToolbar, that'd not create issues to the menubar or tabbar, and it would be predictable since it's a click on the foreground area that contains the urlbar.
I think the search bar should act the same, but it's not a Proton target, we should still make it consistent though.

Comment 13

[Marco Bonardo [:mak]]

There is one case that particularly bothers me here, that is dragging a window with a focused address bar. That will lose focus.
I must also note that I was testing Chrome in regard of this, and they act the same as current Firefox.

I'm starting shifting my opinion towards doing this much later in the Proton chain (maybe one of the last things), it's actually high likely that this will be a non-issue with the non-expanding urlbar.

Comment 14

[Mike de Boer [:mikedeboer]]

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

I'm starting shifting my opinion towards doing this much later in the Proton chain (maybe one of the last things), it's actually high likely that this will be a non-issue with the non-expanding urlbar.

As a I was thinking the exact same thing here, I chime in: let's do this at a much later stage of the project and focus on the visual/ appearance changes first.

Comment 15

[Harry Twyford]

From Aaron on Jira:

I don't think this is necessarily a Proton-related issue. I can see there's some nuanced behavior outlined in the bug I filed. I'm not sure some of the workflows being described are valid workflows to account for (e.g. clicking into the address bar and then opening up menus). This shouldn't be blocking any work, currently, so for the sake of time I think we can de-prioritize this.