User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

1. require an additional toolbar – bug 1215064
2. have many extensions, use the overflow menu for some
3. given the impossibility of an additional toolbar, use the bookmarks toolbar for extensions alone

Actual results:

4. with Firefox 85 and 86, the bookmarks toolbar can be so inflexibly wide that UI essentials – including the vertical scroll bar – fall invisibly and unusably beyond the right-hand edge of the window
5. in the far right area of the bookmarks toolbar that appears to be non-flexible dead space, place the flexible Search field.

Observations

• Where the wide flexible Search field does work, a narrow flexible space does not
• whilst the Search field works around the bug, it is (with respect) a waste of space in this context – I prefer to use the space for extensions.

Expected results:

1. an additional toolbar, for extensions (or any other reasonable use case)

– or:

4. a non-broken bookmarks toolbar.

From a screen recording: the Search field (workaround) in place …

A split-second later: the subsequent frame from the recording.

As I drag the Search field (the workaround) away from the bookmarks toolbar:

• non-flexible dead space appears in the bar

– to the right of the rightmost extension.

:grahamperrin, if you think that's a regression, could you try to find a regression range using for example mozregression?

Hi, no mozregression with FreeBSD (sorry) however https://new.reddit.com/r/FirefoxCSS/comments/l5ikzu/extensions_placed_in_the_bookmarks_toolbar/ confirms my recollection of encountering the problem with my first use of:

www/firefox 85.0,2

– which, according to https://www.freshports.org/www/firefox/#history, followed 84.0.2,2 (update firefox to 84.0.2). More specifically, from the post in Reddit:

Build ID: 20210119192212

– with 2021-01-19 falling between https://wiki.mozilla.org/Release_Management/Calendar#Past_branch_dates the 2020-12-14 beta of Firefox 85 and its 2021-01-26 release. From past experience with FreeBSD commit histories for www/firefox I think it extremely likely that 20210119192212 was built from a release candidate code base (I can check with committer Jan Beich, but I don't imagine that doing so will significantly narrow a regression range).

It took some time for me to determine that the bookmarks toolbar (not any other bar) was involved. Eventually – probably after reading How to remove the new "Other Bookmarks" button from Firefox | ZDNet – I found bug 1664053 and bug 1674539 then of the two, I guessed that 1664053 was a more likely cause so, at bug 1664053 comment 13 I raised the question.

Bug 1664053 comment 15

… I suspect that the dead space (space that is problematic) occurs in the absence of the Other Bookmarks button. …

I can't recall whether I tested that theory.

The final bullet point under https://discourse.mozilla.org/t/when-will-a-toolbar-api-for-webextensions-be-available/34281/16?u=grahamperrin (Firefox 85.⋯ at the time):

• if I recall correctly, this appeared problem-free because the Bookmarks Toolbar was hidden.

Confirmed today with www/firefox 86.0_2,2 (built from release candidate 3):

1. removal of the Search field (workaround) from the bookmarks bar exposes the bug
2. then using the View menu to hide the bookmarks toolbar (losing sight of all extensions therein) suppresses the bug.

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #2)

… could you try to find a regression range …

The much shorter answer (!) is that I might copy my everyday profile (1.9 G in a compressed file system) from FreeBSD, to a nearby computer with Firefox 86.0 on Manjaro Linux and there, run mozregression however it's a 2008 vintage with Intel Core 2 Duo and probably no more than 4 GB memory, so let's not get excited about gaining an answer there any time soon :-)

% du -hs ~/.mozilla/firefox/58ectoj2.default
1.9G    /home/grahamperrin/.mozilla/firefox/58ectoj2.default
% zfs get compression,compressratio copperbowl/usr/home
NAME                 PROPERTY       VALUE           SOURCE
copperbowl/usr/home  compression    lz4             local
copperbowl/usr/home  compressratio  1.28x           -
% pkg query '%o %v %R' firefox
www/firefox 86.0_2,2 FreeBSD
% freebsd-version -kru
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
% date ; uname -a
Mon  1 Mar 2021 12:06:41 GMT
FreeBSD mowa219-gjp4-8570p 14.0-CURRENT FreeBSD 14.0-CURRENT #87 main-5ac839029d: Mon Feb 22 04:02:26 GMT 2021     root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64
%

Why are you claiming this was regressed by bug 1664053? It doesn't seem related here.

I suspect bug 1674091 is more likely, but I find it really hard to follow this report and don't really understand what "non-flexible dead space" means in this context. If you open a new window, reproduce the problem there, then run document.getElementById("personal-toolbar-empty").remove() from the browser console (opened from that new window), does the problem go away? (Other things in that window might then break, I'm mostly interested in whether my understanding is correct)

Thanks, I was uncertain about things.

I ran mozregression once, identified a date in November 2020 (the 20th?) but accidentally clicked skip at one point, so I'm re-running now with debug builds hoping to get something more definite.

True, the problem does disappear in response to:

document.getElementById("personal-toolbar-empty").remove()

Result of mozregression on shippable

…
2021-03-01T16:32:50.793000: INFO : Narrowed integration regression window from [e3f638c6, bb956d9f] (3 builds) to [e3f638c6, af10a3ff] (2 builds) (~1 steps left)
2021-03-01T16:32:50.805000: DEBUG : Starting merge handling...
2021-03-01T16:32:50.806000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=af10a3ffbbd17443b54446ec5f39fb8531a010f0&full=1
2021-03-01T16:32:50.806000: DEBUG : redo: attempt 1/3
2021-03-01T16:32:50.806000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=af10a3ffbbd17443b54446ec5f39fb8531a010f0&full=1',), kwargs: {}, attempt #1
2021-03-01T16:32:50.810000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2021-03-01T16:32:51.854000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=af10a3ffbbd17443b54446ec5f39fb8531a010f0&full=1 HTTP/1.1" 200 None
2021-03-01T16:32:51.900000: DEBUG : Found commit message:
Bug 1667237 - bookmarks toolbar flickers on startup / new windows in some cases, r=florian,jaws

Differential Revision: https://phabricator.services.mozilla.com/D97712

2021-03-01T16:32:51.901000: DEBUG : Did not find a branch, checking all integration branches
2021-03-01T16:32:51.903000: INFO : The bisection is done.
2021-03-01T16:32:51.904000: INFO : Stopped

Final verdict: b:

app_name: firefox
build_date: 2020-11-21 10:59:45.795000
build_file: /home/grahamperrin/.mozilla/mozregression/persist/8d8561344299-shippable--mozilla-central--target.tar.bz2
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/YZnz3bZIRQ6a3xD7v7QPcg/runs/0/artifacts/public%2Fbuild%2Ftarget.tar.bz2
changeset: 8d8561344299516728989604a0c7a14d2bff91e7
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fd1683e51ec5eae6a5c5b516492d6a81eb06e7ea&tochange=8d8561344299516728989604a0c7a14d2bff91e7
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
task_id: YZnz3bZIRQ6a3xD7v7QPcg

(In reply to Graham Perrin from comment #6)

Thanks, I was uncertain about things.

I ran mozregression once, identified a date in November 2020 (the 20th?) but accidentally clicked skip at one point, so I'm re-running now with debug builds hoping to get something more definite.

True, the problem does disappear in response to:

document.getElementById("personal-toolbar-empty").remove()

If you inspect this element with the browser toolbox when it's not removed, how is it styled? I would expect it to have the hidden attribute and therefore display: none. Which part isn't working?

Sorry mid-air collision I didn't intend to change the regression field! I'll re-enter

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

If you inspect this element with the browser toolbox when it's not removed, how is it styled? I would expect it to have the hidden attribute and therefore display: none. …

For these two screenshots and the screen recording (up next), I made

toolkit.legacyUserProfileCustomizations.stylesheets false

So I don't understand. The layout overlay shows that the empty bookmarks toolbar item (visibility: hidden) is not anywhere near the overflown content, so it's not directly causing the overflow, right? It also seems like its parent still has a nowidth attribute which means it's 0 width anyway...

If you're using userChrome.css you might as well set display: hidden on that node if that fixes it, though it doesn't make sense that it does...

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

Honestly (sorry), I have very little understanding of what's going on. I held back from reporting for over a month because it seemed quite mind-bending and difficult to describe.

Whilst I made the screen recording, I half-expected something to be 'highlighted' at or near the right-hand side of the bookmarks toolbar, whilst I hovered over those lines in the code. Did you have a similar expectation?

I tried each of these two sets of lines in my userChrome.css, neither set has the desired effect:

#personal-toolbar-empty {
    display: hidden !important; 
}

– then:

#personal-toolbar-empty {
    visibility: hidden !important;
}

Is this (non-effectiveness of userChrome.css) even more mind-bending? Or am I mistaken to put the # character at the beginning of the line?

(I'm quite ignorant of how to work with CSS. Happy to raise a question in https://old.reddit.com/r/FirefoxCSS/, if you think it's worth asking there.)

Thanks for looking into this.

(In reply to Graham Perrin from comment #14)

I tried each of these two sets of lines in my userChrome.css, neither set has the desired effect:

#personal-toolbar-empty {
    display: hidden !important; 
}

You want display: none !important, not hidden - though I expect it should work without the !important anyway.

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

#personal-toolbar-empty {
    display: none; 
}

– works around as required. Thank you!

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

… run document.getElementById("personal-toolbar-empty").remove() … does the problem go away? (Other things in that window might then break, …

(In reply to Graham Perrin from comment #6)

… True, the problem does disappear in response to:

document.getElementById("personal-toolbar-empty").remove()

Maybe I should have been more precise. If I recall correctly:

1. whilst this method of removal did temporarily end the "excessively wide bar" effect on the window (i.e. some flexibility was regained)
2. the removal was not followed by use of the full width of the bar by extension buttons/icons

– there remained a gap at the right-hand side of the bar, as if a non-flexible spacer was present. I didn't think to mention this detail, because I assumed that it fell under the umbrella of "other things" breaking.

Now it seems, the bug is no longer reproducible.

The UI behaves as expected – with flexibility, and with items spread properly across the entire width of the bookmarks toolbar – without the workaround in userChrome.css 🎉

In the absence of steps to reproduce, would you like to close this bug?

Thanks for the follow-up. Yes, let's close the bug. Feel free to flag needinfo if the bug comes back for you.

[Tracking Requested - why for this release]:

Briefly

Symptoms recurred today after I installed the package for this collection of fonts:

https://www.freshports.org/x11-fonts/google-fonts/

The package message:

If installing:
    Add the following line to the "Files" section of X Windows configuration file:

            FontPath "/usr/local/share/fonts/google-fonts/" 

Dependencies: https://www.freshports.org/x11-fonts/google-fonts/#dependencies

The bug was worked around, as far as I could tell, by deleting the package, removing the relevant line from
/usr/local/etc/X11/xorg.conf.d/files.conf
– then removing a cache directory
~/.cache/fontconfig/

– without deleting dependencies.

Screenshots and additional details to follow.

Please:

• should I also, or alternatively, raise a bug for x11-fonts/google-fonts in Bugzilla for FreeBSD?

Screenshot, 08:41 this morning.

Background

Some time over the long weekend (including Spring Bank Holiday Monday in the UK) I noticed that fonts had become jagged in parts of pages such as https://forums.freebsd.org/threads/how-do-you-test-13-0-current.77201/.

After installing x11-fonts/google-fonts and its dependencies I found:

• no improvement to the jaggedness
• a serif font for the URL in the address bar, where previously I had preferred monospace
• recurrence of this bug 1695575

Screenshot, 08:42 this morning.

With the previously identified workaround – addition of the Search field to the right of the bookmarks toolbar:

• the scrollbar for the page becomes visible, and so on.

I quit Firefox and removed the fontconfig cache.

Then started Firefox, repopulation of the cache began and jaggedness was no longer visible.

Screenshot, 08:52 this morning.

I experimented with removal of the Search field from the bookmarks toolbar.

The bug was still evident – the Done button was out of sight, and so on.

Screenshot, 09:04 this morning.

After deleting the google-fonts package and removing the relevant line from files.conf:

1. the bug was no longer apparent
2. I regained monospace appearance of the URL in the address field.

Setting the Qa-not-actionable flag until we get our hands on a FreeBSD machine in order to reproduce this issue on our end.

In brief:

• with an earlier draft of what's below, I wondered whether a recurrence of the bug had preceded installation of google-fonts; whether recurrence had coincided with font jaggedness (but gone unnoticed by me because I was entirely focused, at the time, on a test page that involved zero use of the GUI)
• with a near-final draft of what's below, I no longer suspect any substantial change to the essence of this bug (i.e. it can be triggered, in my case, by installation of google-fonts)
• I'll leave what's below for the record, maybe noisy (sorry) but it's record-keeping of a type that will help me to work more methodically next time.

Yesterday, after experimenting with this combination:

• gfx.webrender.enabled true (where false is the default)
• a change of KDE Plasma compositor preferences from XRender to OpenGL 3.1 for the rendering backend
• also in KDE Plasma compositor preferences, a change from lower latency, to balance of latency and smoothness

– I noticed that a font was jagged (and smaller than it should have been) at a GitHub address.

A problem with width of the GUI was not immediately noticeable.

Additional context, to the best of my recollection (I'm not certain of the exact order of events):

1. I quit my default profile, ran Firefox in a test profile to gauge the effect of the gfx.webrender.enabled preference at https://testdrive-archive.azurewebsites.net/Performance/Chalkboard/Default.html (I ran the test there a few times)
2. I quit the test profile then ran Firefox normally to re-run the test … it might have been around this time that I began changing compositor preferences at the KDE Plasma level

I then cautiously:

1. installed google-fonts-0.0.0.20210120 (associated libglvnd-1.3.2 was not automatically installable – conflict with mesa-libs-20.2.3)
2. added FontPath "/usr/local/share/fonts/google-fonts/" to /usr/local/etc/X11/xorg.conf.d/files.conf
3. ran fc-cache as root.

Around this time, I observed a recurrence of the problem with the width of the GUI (and no improvement to the jagged font, if I recall correctly). No surprise, given my comment #20 above. Then:

1. quit
2. start
3. no improvement to the width problem
4. reverted KDE Plasma compositor preferences to XRender
5. quit Firefox
6. the commands outlined below
7. … eventual removal of google-fonts, after which I found (as expected) an end to the GUI width problem and (perhaps strangely) an end to the jagged font problem.

root@mowa219-gjp4-8570p:/usr/local/etc/X11/xorg.conf.d # mv files.conf ../fontpath.d/
root@mowa219-gjp4-8570p:/usr/local/etc/X11/xorg.conf.d # fc-cache
root@mowa219-gjp4-8570p:/usr/local/etc/X11/xorg.conf.d # ls -ahl
total 2
drwxr-xr-x  2 root  wheel     4B Jun 18 15:19 .
drwxr-xr-x  5 root  wheel     5B Sep 13  2020 ..
-rw-r--r--  1 root  wheel    58B Mar 24  2019 flags.conf
-rw-r--r--  1 root  wheel    59B May 29 05:31 modules.conf
root@mowa219-gjp4-8570p:/usr/local/etc/X11/xorg.conf.d # cat flags.conf 
Section "ServerFlags"
  Option "DontZap" "off"
EndSection
root@mowa219-gjp4-8570p:/usr/local/etc/X11/xorg.conf.d # rm flags.conf 
root@mowa219-gjp4-8570p:/usr/local/etc/X11/xorg.conf.d # 

Yesterday's pkg-related lines from /var/log/messages:

Jun 18 04:59:10 mowa219-gjp4-8570p pkg[50468]: linux-c7-libogg-1.3.0_1 installed
Jun 18 04:59:10 mowa219-gjp4-8570p pkg[50468]: linux-c7-libvorbis-1.3.3_2 installed
Jun 18 04:59:10 mowa219-gjp4-8570p pkg[50468]: linux-c7-gsm-1.0.13 installed
Jun 18 04:59:10 mowa219-gjp4-8570p pkg[50468]: linux-c7-flac-libs-1.3.0_2 installed
Jun 18 04:59:10 mowa219-gjp4-8570p pkg[50468]: linux-c7-tcp_wrappers-libs-7.6_2 installed
Jun 18 04:59:10 mowa219-gjp4-8570p pkg[50468]: linux-c7-libasyncns-0.8_1 installed
Jun 18 04:59:11 mowa219-gjp4-8570p pkg[50468]: linux-c7-libsndfile-1.0.25_6 installed
Jun 18 04:59:11 mowa219-gjp4-8570p pkg[50468]: linux-c7-pulseaudio-libs-10.0_3 installed
Jun 18 04:59:46 mowa219-gjp4-8570p pkg[50468]: linux-wps-office-11.1.0.10161 installed
Jun 18 15:02:03 mowa219-gjp4-8570p pkg[63881]: google-fonts-0.0.0.20210120 installed
Jun 18 15:56:13 mowa219-gjp4-8570p pkg[3165]: py27-dnspython-1.16.0 deinstalled
Jun 18 15:56:14 mowa219-gjp4-8570p pkg[3165]: py27-setuptools44-44.0.0_1 deinstalled
Jun 18 15:56:17 mowa219-gjp4-8570p pkg[3165]: python27-2.7.18_1 deinstalled
Jun 18 15:56:31 mowa219-gjp4-8570p pkg[3181]: google-fonts-0.0.0.20210120 deinstalled

Additional context:

• the experiment with gfx.webrender.enabled true was prior to me discovering that https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255344 HW_COMPOSITING is now enabled by default
• now about:support shows Compositing WebRender whilst gfx.webrender.enabled is false.

Firefox 89.0_2,2 on FreeBSD 14.0-CURRENT,

% uname -KUv
FreeBSD 14.0-CURRENT #98 main-n247326-2349cda44fe: Sat Jun 12 08:19:48 BST 2021     root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  1400021 1400021

FreeBSD bug 257087 – x11-fonts/fontconfig problems with monospace font(s) after updating from 2.13.93,1 to 2.13.93_1,1

Still aiming to make this somehow consistently reproducible.

At the time of writing:

• with x11-fonts/google-fonts installed, I can work around the issue with a general system preference for Fira Sans Condensed 10pt instead of Victor Mono 10pt.

% date 
Wed 22 Sep 2021 05:59:07 BST
% pkg info -x firefox fontconfig google-fonts | sort
firefox-92.0_2,2
fontconfig-2.13.94_1,1
google-fonts-0.0.0.20210120
linux-c7-fontconfig-2.13.0
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #109 main-n249408-ff33e5c83fa: Thu Sep 16 01:11:04  2021     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64 1400033 1400033
% 

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.