From Newsgroup: muc.lists.freebsd.stable

Hello,
I would like to report a reproducible issue with the www/chromium port
that affects the chrome://password-manager/passwords WebUI page
specifically. The problem occurs both inside a FreeBSD jail and
directly on the host system, so it does not appear to be jail-related.
I originally noticed this on version 149.0.7827.200 and have since
upgraded to 150.0.7871.100 -- the issue persists unchanged.
Summary
-------
The chrome://password-manager/passwords page renders as empty/blank,
even though the underlying password database exists, is structurally
intact, and contains valid, non-blacklisted entries. No JavaScript
errors appear in the DevTools console, and no failed requests appear in
the Network tab. Other WebUI list pages (chrome://bookmarks,
chrome://history) work correctly and display their content as expected
-- this issue is specific to the password manager page.
System information
-------------------
- Package: chromium
- Version tested: 149.0.7827.200 (original report), 150.0.7871.100
(current, issue still present)
- OS: FreeBSD (reproducible both inside a jail and directly on the
host)
- Desktop environment: Xfce
Steps to reproduce
-------------------
1. Start Chromium normally, or with a fresh empty profile:
chrome --user-data-dir=/tmp/chrome-cleantest --password-store=basic
2. Log in to any site and save a password via the normal "Save
password?" prompt (I used https://the-internet.herokuapp.com/login with
the well-known public test credentials tomsmith / SuperSecretPassword!
to confirm this without touching real accounts).
3. Navigate to chrome://password-manager/passwords.
Expected result: the saved password entry appears in the list.
Actual result: the list remains completely empty. The page loads
correctly otherwise (headers, "Add" button, layout, settings sub-page
all present), but no list items are ever rendered.
Additional verification performed
----------------------------------
To rule out a corrupted profile or database, I ran the following checks
on the password database (with Chromium fully closed):
ps ax | grep chrome
pkill chrome
sqlite3 "$HOME/.config/chrome-<profile>/Default/Login Data" "SELECT
count(*) FROM logins;"

returned 216, confirming entries are present (increased from 215 to

216 after saving a new test entry, confirming saving itself works
correctly)
sqlite3 "$HOME/.config/chrome-<profile>/Default/Login Data" "SELECT blacklisted_by_user, count(*) FROM logins GROUP BY
blacklisted_by_user;"

0|196
1|21

(196 valid, non-blacklisted entries -- more than enough that the UI
should display something)
sqlite3 "$HOME/.config/chrome-<profile>/Default/Login Data" "PRAGMA integrity_check;"

ok

sqlite3 "$HOME/.config/chrome-<profile>/Default/Login Data" ".tables"

field_info, insecure_credentials, logins, meta, password_notes,

stats,
sync_entities_metadata, sync_model_metadata
So the SQLite database itself is structurally sound, saving new entries
works correctly, and it contains valid, non-blacklisted entries -- yet chrome://password-manager/passwords displays nothing.
D-Bus session bus explicitly tested and ruled out ---------------------------------------------------
Since the verbose log output shows repeated "Failed to connect to the
bus" errors (see below), I want to preempt the natural follow-up
question of whether a missing D-Bus session bus could be the cause. I
tested this explicitly:
eval $(dbus-launch --sh-syntax --exit-with-session)
echo $DBUS_SESSION_BUS_ADDRESS

unix:path=/tmp/dbus-

Ea40b0zrnE,guid=ae21e85846a53be06ea4a8b36a5b74f8
ls -la /tmp/dbus-*

confirmed the socket exists

chrome --user-data-dir="$HOME/.config/chrome-<profile>" --password- store=basic
With a valid, running D-Bus session bus and DBUS_SESSION_BUS_ADDRESS
correctly pointing to it, chrome://password-manager/passwords still
renders an empty list. So a missing D-Bus session bus is not the cause
of this issue, even though the errors do appear in the logs during
normal (bus-less) operation.
Logging output
---------------
Running with verbose logging (in the normal, bus-less environment):
chrome --enable-logging=stderr --v=1 chrome://password-
manager/passwords 2>&1 | grep -iE "error|fail|mojo|password"
shows no explicit error tied to the password manager WebUI itself, but
does show a repeating GPU process initialization failure (four separate
PIDs cycling through the same failure during a single session):
[pid:tid:...] ERROR:ui/gl/init/gl_factory.cc:110] Requested GL
implementation (gl=none,angle=none) not found in allowed
implementations: [(gl=egl-angle,angle=default)].
[pid:tid:...] VERBOSE1:gpu/ipc/service/gpu_init.cc:502] gl::init::InitializeStaticGLBindingsOneOff failed
[pid:tid:...] ERROR:components/viz/service/main/viz_main_impl.cc:190]
Exiting GPU process due to errors during initialization
I am not certain this is related, since chrome://bookmarks and
chrome://history render correctly despite the same GPU log entries
appearing during those sessions too. I tested launching with --disable-
gpu as well, which did not resolve the blank password-manager list.
Also present in the logs, but ruled out as described above:
ERROR:dbus/bus.cc:405] Failed to connect to the bus: Failed to connect
to socket /tmp/runtime-<uid>/bus: No such file or directory
ERROR:dbus/object_proxy.cc:572] Failed to call method: org.freedesktop.DBus.NameHasOwner ...
And, likely unrelated:
ERROR:crypto/nss_util.cc:377] After loading Root Certs, loaded==false:
NSS error code: -8018
What I have already ruled out
------------------------------
- Not a file-permission issue (profile files are correctly owned, mode
600)
- Not a disk-space/quota issue
- Not a database corruption issue (integrity_check: ok)
- Not caused by Google-account sync interference (I explicitly tested
by signing out of my Google account; new entries are still saved
correctly into the local database, confirmed by the logins count
increasing from 215 to 216, but the entry still does not appear in the
WebUI list)
- Not specific to my existing profile (a brand-new, empty --user-data-
dir shows the same blank password-manager list)
- Not related to running inside a jail (the same behavior is
reproducible directly on the host)
- Not fixed by --disable-gpu
- Not a general WebUI rendering problem (chrome://bookmarks and chrome://history both work correctly and display their content)
- Not fixed by upgrading from 149.0.7827.200 to 150.0.7871.100
- Not caused by a missing D-Bus session bus (explicitly tested with a
valid, running session bus; issue persists identically)
Request
-------
Could someone familiar with the chromium port take a look at this? I am
happy to provide additional logs, run further diagnostic commands, or
test proposed patches. Please let me know what additional information
would be useful.
Thank you for your time and for maintaining this port.
Best regards,
Franz
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2