new feature: warning if autoping is disabled #80

Manually merged

jabber.developer merged 8 commits from feat/autoping-warning into master 2026-06-23 11:11:48 +00:00

Conversation 2 Commits 8 Files Changed 10 +220 -9

jabber.developer commented 2026-01-27 10:29:42 +00:00

Owner

Copy Link

This feature introduces warning to the user if the server he is connecting to supports autoping, but autoping is disabled in settings. Autoping is an important feature since it allows to detect disconnections that happen during IP changes (such that can happen on VPN/TOR node changes). Due to its importance, it's preferred for all users to enable it if the server supports this feature.

Initially, the issue had higher significance since autoping feature sometimes got false negative server feature support (due to a bug, potentially related to disco feature), however, feature for automatic disabling of autoping preference was changed to a warning instead in 3738be4a.

Resolves #1

This feature introduces warning to the user if the server he is connecting to supports autoping, but autoping is disabled in settings. Autoping is an important feature since it allows to detect disconnections that happen during IP changes (such that can happen on VPN/TOR node changes). Due to its importance, it's preferred for all users to enable it if the server supports this feature. Initially, the issue had higher significance since autoping feature sometimes got false negative server feature support (due to a bug, potentially related to `disco` feature), however, feature for automatic disabling of autoping preference was changed to a warning instead in 3738be4a. Resolves #1

jabber.developer added 1 commit 2026-01-27 10:29:43 +00:00

[WORK IN PROGRESS] feat: warning if autoping is disabled 6548329616

jabber.developer force-pushed feat/autoping-warning from 6548329616 to 1f38ff0522 2026-01-27 19:56:58 +00:00 Compare

jabber.developer force-pushed feat/autoping-warning from 1f38ff0522 to 6086391b0e 2026-01-27 20:00:13 +00:00 Compare

jabber.developer added a new dependency 2026-01-28 13:30:33 +00:00

#84 Add tests for XEP-0030 Service Discovery

jabber.developer added a new dependency 2026-03-04 11:31:48 +00:00

#99 WIP: tests: Add disco tests

jabber.developer removed a dependency 2026-03-04 11:54:44 +00:00

#99 WIP: tests: Add disco tests

jabber.developer force-pushed feat/autoping-warning from 6086391b0e to 75a035cd34 2026-05-20 11:43:53 +00:00 Compare

jabber.developer2 force-pushed feat/autoping-warning from 75a035cd34 to 0a3b2b235f 2026-06-19 09:06:45 +00:00 Compare

jabber.developer2 referenced this issue from a commit 2026-06-20 11:40:09 +00:00

test(autoping): cover availability-warning conditions

jabber.developer2 force-pushed feat/autoping-warning from 0a3b2b235f to 45b81cf2de 2026-06-20 11:40:09 +00:00 Compare

jabber.developer2 changed title from WIP: new feature: warning if autoping is disabled to new feature: warning if autoping is disabled 2026-06-20 11:41:13 +00:00

jabber.developer referenced this issue from a commit 2026-06-20 12:48:58 +00:00

fix(disco): avoid autoping warning on disco#info responses from users

jabber.developer added 1 commit 2026-06-20 12:48:58 +00:00

fix(disco): avoid autoping warning on disco#info responses from users ... bdff48c765

The autoping availability warning should only trigger for disco#info
responses from the XMPP server (no 'from' attribute), otherwise the
warning message is displayed excessive amount of times.

Refs #80

jabber.developer referenced this issue from a commit 2026-06-20 20:47:36 +00:00

fix(disco): avoid autoping warning on disco#info responses from users

jabber.developer force-pushed feat/autoping-warning from bdff48c765 to 7fd0cded3d 2026-06-20 20:47:36 +00:00 Compare

jabber.developer added 1 commit 2026-06-21 15:37:20 +00:00

fix(xmpp): prevent autoping warning repetition on disco items ... b5bbad8d2c

The previous logic triggered warnings for disco items. This change restricts the check to only the connection domain, ensuring that auto-discovered items do not trigger duplicate warnings.

jabber.developer added 1 commit 2026-06-22 09:17:52 +00:00

test(autoping): add test for autoping warning exclusion on subdomain services ... 19bfad76ba

The new test verifies that disco#info responses from subdomain services
(e.g., conference servers) do not trigger the autoping warning, ensuring
the check is correctly restricted to the server's own domain.

jabber.developer2 commented 2026-06-23 10:31:41 +00:00

Collaborator

Copy Link

No blockers — tentative notes only.

Minor / tolerable

• _disco_autoping_warning_message() returns int but always returns 0 and the value is ignored — could probably just be void. Harmless either way.
• Tiny naming/wording: users_prefers_warning looks like it should be user_prefers_warning.

Better to check

• Repetition across reconnects. The from == connection_get_domain() gate stops within-connect repeats (subdomain services), but there doesn't seem to be an "already warned this session" latch, so the warning looks like it re-fires on every reconnect. Since the feature targets frequent reconnects (IP changes on VPN/TOR), it might end up showing on each one — worth deciding whether that's intended, or whether a per-session flag would be nicer.
• Duplicate display. The setting is printed in both /notify (cons_notify_setting) and /autoping (cons_autoping_setting). No other pref appears to be shown in two settings dumps, and inside /notify every other line points to a /notify subcommand whereas this one points to /autoping warning, so it slightly breaks that block's pattern. Might be cleaner to show it in just one place (likely /autoping, leaving the [notifications] storage group as-is). May not really matter.
• Domain match is exact-string. g_strcmp0(from, connection_get_domain()) does no case-folding / IDNA normalisation. If a server ever echoes from in a different case than the bound domain, the warning might silently not fire. Rare, but a normalised compare may be safer.

Incidental (noticed during review, pre-existing — unrelated to this PR)

• _disco_info_response_id_handler_onconnect returns 1 on the connection_get_features() == NULL path but 0 on success. The id-handler dispatch treats non-zero as "keep", so the NULL path seems to leave this one-shot handler registered as a dead entry in id_handlers until disconnect — harmless (no crash, cleaned up later), but a return 0 there would be more consistent. Possibly intentional.

No blockers — tentative notes only. ## Minor / tolerable - `_disco_autoping_warning_message()` returns `int` but always returns `0` and the value is ignored — could probably just be `void`. Harmless either way. - Tiny naming/wording: `users_prefers_warning` looks like it should be `user_prefers_warning`. ## Better to check - **Repetition across reconnects.** The `from == connection_get_domain()` gate stops within-connect repeats (subdomain services), but there doesn't seem to be an "already warned this session" latch, so the warning looks like it re-fires on every reconnect. Since the feature targets frequent reconnects (IP changes on VPN/TOR), it might end up showing on each one — worth deciding whether that's intended, or whether a per-session flag would be nicer. - **Duplicate display.** The setting is printed in both `/notify` (`cons_notify_setting`) and `/autoping` (`cons_autoping_setting`). No other pref appears to be shown in two settings dumps, and inside `/notify` every other line points to a `/notify` subcommand whereas this one points to `/autoping warning`, so it slightly breaks that block's pattern. Might be cleaner to show it in just one place (likely `/autoping`, leaving the `[notifications]` storage group as-is). May not really matter. - **Domain match is exact-string.** `g_strcmp0(from, connection_get_domain())` does no case-folding / IDNA normalisation. If a server ever echoes `from` in a different case than the bound domain, the warning might silently not fire. Rare, but a normalised compare may be safer. ## Incidental (noticed during review, pre-existing — unrelated to this PR) - `_disco_info_response_id_handler_onconnect` returns `1` on the `connection_get_features() == NULL` path but `0` on success. The id-handler dispatch treats non-zero as "keep", so the NULL path seems to leave this one-shot handler registered as a dead entry in `id_handlers` until disconnect — harmless (no crash, cleaned up later), but a `return 0` there would be more consistent. Possibly intentional.

jabber.developer added 1 commit 2026-06-23 10:58:04 +00:00

fix(disco): clean up autoping warning message handling ... 14fb6e3b41

Remove unused return value from _disco_autoping_warning_message by
changing its return type to void. Rename local variable from
users_prefers_warning to user_prefers_warning for correct grammar.

Use g_ascii_strcasecmp instead of g_strcmp0 for the domain match
check, so the warning fires correctly regardless of case differences
between the stanza 'from' field and the bound domain.

Remove duplicate autoping warning display from cons_notify_setting(),
keeping it only in cons_autoping_setting() where it belongs.

jabber.developer commented 2026-06-23 10:58:14 +00:00

Author

Owner

Copy Link

Addressed.

Addressed.

jabber.developer manually merged commit 02e679c277 into master 2026-06-23 11:11:48 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

Compat/Breaking

Breaking change that won't be backward compatible

Kind/Bug

Something is not working

Kind/Documentation

Documentation changes

Kind/Enhancement

Improve existing functionality

Kind/Feature

New functionality

Kind/Security

This is security issue

Kind/Testing

Issue or pull request related to testing

Priority

Critical

1

The priority is critical

Priority

High

2

The priority is high

Priority

Low

4

The priority is low

Priority

Medium

3

The priority is medium

Reviewed

Confirmed

1

Issue has been confirmed

Reviewed

Duplicate

2

This issue or pull request already exists

Reviewed

Invalid

3

Invalid issue

Reviewed

Won't Fix

3

This issue won't be fixed

Status

Abandoned

3

Somebody has started to work on this but abandoned work

Status

Blocked

1

Something is blocking this issue or pull request

Status

Need More Info

2

Feedback is required to reproduce issue or to continue work

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

admin jabber.developer jabber.developer2

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Depends on

#84 Add tests for XEP-0030 Service Discovery

devs/cproof

Reference: devs/cproof#80

No description provided.