1561904 - Stop overlapping other toolbars with the focused urlbar

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Dão Gottwald [:dao]]

From https://mozilla.invisionapp.com/share/DNSDVW5E8QK#/screens/367251846_Photon_Design_Update:

"When the quantumbar is automatically focused (startup, new tab, clicking home, new window) and the Bookmarks Toolbar is displayed, the toolbar will get a 10px top margin so bookmarks clear the bottom. If the quantumbar loses focus, the toolbar's margin will animate away along with the quantumbar to its unfocused state."

Comment 1

[Dão Gottwald [:dao]]

I'm not quite convinced of the proposed UX here e.g. as it implies shifting the whole content area. I propose we just don't expand the urlbar at all when the bookmarks toolbar is present. mconnor is going to discuss this with verdi.

Comment 2

[Verdi [:verdi] Best to slack me]

Mike and I discussed this today and agreed that we should go ahead and implement it.

Comment 4

[Tooru Fujisawa [:arai]]

(In reply to Verdi [:verdi] NI or PM me from comment #2)

Mike and I discussed this today and agreed that we should go ahead and implement it.

is "it" mean "don't expand the urlbar at all when the bookmarks toolbar is present" in comment #1 ?
if so, can we change the bug summary for clarity?

Comment 5

[Verdi [:verdi] Best to slack me]

(In reply to Tooru Fujisawa [:arai] from comment #4)

(In reply to Verdi [:verdi] NI or PM me from comment #2)

Mike and I discussed this today and agreed that we should go ahead and implement it.

is "it" mean "don't expand the urlbar at all when the bookmarks toolbar is present" in comment #1 ?
if so, can we change the bug summary for clarity?

No it means we're going to do what the bug title says - shift the bookmarks toolbar downwards when the urlbar is focused in new tabs.

Comment 6

[Tooru Fujisawa [:arai]]

so, this bug covers the case for new tabs (that shows about:newtab), right?
should we open another bug for non-new tabs? or does bug 1585958 cover the case?

Comment 7

[Verdi [:verdi] Best to slack me]

(In reply to Tooru Fujisawa [:arai] from comment #6)

so, this bug covers the case for new tabs (that shows about:newtab), right?

Yep.

should we open another bug for non-new tabs? or does bug 1585958 cover the case?

No. On non-new tabs we don't autofocus the address bar so it doesn't cover anything until you interact with it.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

The fact that it changes the viewport of the browser is going to be pretty annoying / have side effects like content jumping around, which is not great.

Comment 9

[Marco Bonardo [:mak]]

I must note it's only on "(startup, new tab, clicking home, new window)", on normal focusing it won't do it.

Comment 10

[Dão Gottwald [:dao]]

How are we supposed to handle the whole content area shifting as the urlbar loses focus the moment the user interacts with the new tab page?

Comment 11

[Tooru Fujisawa [:arai]]

when (in which timing) does the bookmark bar shifts and unshifts ?
what happens when user starts interacting with bookmark bar (like, opening bookmark folder, drag and drop item) while urlbar is expanded?

Comment 12

[Adrian Wielgosik [:adrian17]]

The fact that it changes the viewport of the browser is going to be pretty annoying / have side effects like content jumping around, which is not great.

Also, in general, seems to conflict with the idea of compact density. Maybe disable this behavior when compact density is set?

Comment 13

[Mikael Håkansson]

What about extensions that change the new tab page? There is quite a few of them that use the top-most part of the page, or can be configured to do so.

I have a custom made new tab page that uses webextension API to create a bookmarks bar, and there is at least a few extensions on AMO that have the same functionality.

Maybe decrease the bottom padding of the megabar when there is a non-default new tab page so it won't cover content?

Comment 14

[Verdi [:verdi] Best to slack me]

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

How are we supposed to handle the whole content area shifting as the urlbar loses focus the moment the user interacts with the new tab page?

I'm not quite sure what you are asking. Maybe we can delay moving the content until mouseup so that targets don't move under the pointer and maybe we can skip moving the content if another url has been requested.

Comment 15

[Tooru Fujisawa [:arai]]

(In reply to Verdi [:verdi] NI or PM me from comment #14)

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

How are we supposed to handle the whole content area shifting as the urlbar loses focus the moment the user interacts with the new tab page?

I'm not quite sure what you are asking. Maybe we can delay moving the content until mouseup so that targets don't move under the pointer and maybe we can skip moving the content if another url has been requested.

about:newtab contains things that require multiple click (I mean, not something that triggers pageload by one click) to interact.

example case with Top Sites menu:

1. click "..." button next to "Top Sites"
2. a menu is opened under the button
3. click a menu item there, or just click elsewhere to close the menu

another case in search field:

1. click search field
2. secondary click there to open context menu
3. a context menu is opened next to the cursor
4. click "Paste"
5. click arrow button to search the pasted text

in both case, if a content slides up in any timing, that will be annoying.
if something else than about:newtab is opened there by extension, similar case will happen there also.

also, the same thing happens when user starts interacting with bookmark toolbar items.

Comment 16

[Matthew Turnbull [Bluefang]]

Why not change the behavior to only expand the megabar once the user starts typing (or results are displaying via clicking the drop-down arrow)? It seems like that would address a lot of the usability/UI concerns with the current implementation/design without making the UI feel even more janky.

Comment 17

[Dão Gottwald [:dao]]

Attachment: Bug 1561904 - Stop overlapping other toolbars with the focused urlbar. r=harry

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e71fb039af06
Stop overlapping other toolbars with the focused urlbar. r=harry

Comment 20

[Cristina Coroiu [:ccoroiu]]

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

Comment 21

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I can confirm this fix on the latest nightly(Fx 74.0a1: 2020-02-04), I verified on Windows 10 x64, Ubuntu 18.04 and macOS 10.15.
Updating the flags accordingly.