network applet: several small correctness bugs (dead loop, splice truncation, unresolvable icon name, missing return, WPA3 unclassified)

[IvanTheGeek]

Distribution

Linux Mint 22.3 (Zena)

Package version

cinnamon 6.6.9 — all of these are also present in master at 22e0e5c

Graphics hardware in use

Not relevant

Frequency

Always

Bug description

Five small correctness bugs in files/usr/share/cinnamon/applets/network@cinnamon.org/applet.js, found while investigating #12178. Grouping them in one issue rather than filing five, since each is a couple of lines. Four have a fix in #13911; the fifth is listed here for the record.

---

1. updateAccessPoints() never executes its loop

for (let i = 0; i < accessPoints; i++) {

The index is compared to the array, not accessPoints.length, so the condition is number < object → false on the first iteration. _accessPoints is left empty and the notify::strength handlers are never reconnected, so signal-strength updates silently stop for that network after its access point set changes.

2. splice(pos) in _connectionRemoved() truncates the list

this._connections.splice(pos);

With no delete count, Array.splice removes everything from pos to the end. Removing one connection drops every connection after it from _connections.

3. The VPN-over-wireless panel icon resolves to nothing

iconName = 'xsi-network-wireless-signal-' + signalToIcon(ap.strength) + '-secure-symbolic';

set_applet_icon_symbolic_name() passes the name through unchanged and sets St.IconType.SYMBOLIC; St appends -symbolic itself during lookup. So this asks for ...-secure-symbolic-symbolic. Checked against the shipped icons:

FOUND    xsi-network-wireless-signal-good-secure-symbolic
MISSING  xsi-network-wireless-signal-good-secure-symbolic-symbolic

Result: while a VPN is active over wireless, the panel icon renders as nothing at all. (xapp-symbolic-icons provides these, so it is not theme-dependent.)

The same block also dereferences dev.device.active_access_point without a null check; that is null on a wireless device that is still activating.

4. _correctStateForTunnel() falls through returning undefined

It returns NM.ConnectivityState.FULL for tun and wireguard, but has no return on the path where neither matches, so it yields undefined instead of the state it was passed. Currently only reached from the commented-out connectivity check, but wrong regardless.

5. _getApSecurityType() cannot classify WPA3 or OWE

It only tests KEY_MGMT_PSK and KEY_MGMT_802_1X. NM also exposes KEY_MGMT_SAE, KEY_MGMT_OWE, KEY_MGMT_OWE_TM and KEY_MGMT_EAP_SUITE_B_192, none of which are matched — so for a WPA3-SAE network type is left undefined and cached as such on the access point.

The visible effect is mild today, because _getIcon() tests != UNKNOWN && != NONE and undefined passes both, so the padlock still appears — by accident rather than by design. Anything that switches on the returned value will misbehave. WPA3 networks are common now; there are several in range as I write this.

Steps to reproduce

1 and 2 are visible by inspection. For 3: connect to wireless, then bring up any VPN — the panel icon disappears rather than showing the bars-with-padlock variant the code is reaching for.

Expected behavior

As described per item above.

Additional information

#13911 fixes 1-4 (plus #12178). Item 5 is left alone there because classifying WPA3/OWE properly means deciding what the applet should do with the answer, which felt like a separate conversation.

---

Disclosure: I worked on this with Claude (Anthropic's Claude Code). It did the bulk of the code reading, diagnosis and patch authoring, and drafted this write-up; I reviewed the changes and ran them on my own machine before filing. The commits carry a Co-Authored-By: Claude trailer to the same effect. Flagging it so you can weight the review accordingly.