There's no reason to special-case "three" vs "four or more" in our
current format (rather than using "three or more"), and in fact the
"three" case wasn't using correct English (it was correct in the
PluralAware table, though). Update both the in-call title text and the
conversation item to use the PluralAware "many" version for "three or
more" people in a call.
This change should have no user impact because it only changes
comments.
We had some comments that referenced the Signal server repo. They
referenced a commit that was a little out of date (from March 2022).
This updates the links.
This change should have no user impact.
We effectively had code like this:
#if TESTABLE_BUILD
foo()
#if TESTABLE_BUILD
bar()
#endif
#endif
The inner ones are unnecessary, so I removed them.
When you compose reply to a message but do not
send it, we would persist the text you entered but
would lose the quoted message to which you were
replying.
This commit adds support for persisting that
information.
ThreadReplyInfo is a new class that uses the
key-value store to associate a single optional
reference to a message with each thread.
The following behaviors are nw:
* When you enter the CVC the input toolbar is
updated to have the quoted message.
* When you exit the CVC the quoted message is
saved.
* When a thread is deleted, the quoted message is
deleted.
* Start muted, unmute when pressing volume buttons
* move ringer switch observation into its own class
* observe ringer switch in stories
* add foreground time to AppContext; use to drive mute foregrounding behavior
* dont double observe
* mix story volume with others, show volume controls
This change should have no direct user impact.
`OWSOutgoingReactionMessage` was untested. This adds a basic test for
its `shouldBeSaved` method.
I think this is a useful change on its own, but may make future changes
easier, too.
SignalServiceKit is currently a separate pod. This makes merges tedious
and error-prone. Ultimately, it slows us down. It might've made sense as
a standalone library before, but it's so tightly integrated now that it
isn't useful to have it be separate.
This changes that, and makes SignalServiceKit a "normal" target.
IMO, most of this change isn't that exciting—just a bunch of changes to
scaffolding. There's one slightly spicier change: our generated
`Acknowledgements.plist` is now a little more clever.
Co-authored-by: Max Radermacher <max@signal.org>
* Propagate ThreadAssociatedData audioPlaybackRate down to CVComponentAudioAttachment
* remove audioplaybackrate from component state; keep only on view state
This commit adds something new to the message detail view: the remaining
disappearing message time, if relevant.
For example, "Disappears: 6d 23h 58m 6s" (or something similar) will be
shown.
Builds off of 70eca7b99b and
846e802784.
Group snapshots fetched from the service do not store the
`didJoinFromInviteLink` field on their members, and when we parse a
snapshot into a group model we hardcode this value to `false` for all
members. However, we store that field locally on a `GroupMembership`'s
`MemberStateMap` when processing an "add members" change action, as the
field is provided in the `AddMember` change action proto.
This becomes an issue, since when we refresh the group's state from the
service (which we do periodically, e.g. when opening a group for the
first time after launch) the `GroupMembership` from the group's snapshot
on the service will not match the `GroupMembership` we have locally,
even though they are from the same revision, due to mismatched
`didJoinFromInviteLink` values (hardcoded in the snapshot).
Consequently, we believed we were "updating the group model in a user-
facing way", but the only change therein was clobbering a
`didJoinFromInviteLink: true` to `...: false`, which was 1) wrong and
2) did not have a description to show.
This commit changes `GroupMembership` to ignore values for
`didJoinFromInviteLink` when comparing equality. This means that when we
parse a snapshot into a `TSGroupModel` with all those values hardcoded
to false, but otherwise identical to our local, we will no longer see it
as different from our local (and subsequently clobber our local and
generate an empty update).
Previously, `String#formatDurationLossless` rolled a custom formatter.
Now, it uses `DateComponentsFormatter`.
See also: the tests in `Signal/test/util/StringAdditionsTest.swift`,
which were untouched as part of this change.
I think this is a useful refactor anyway, but it should also fix rare
RTL bugs where duration components would be backwards. (I don't think
this ever happened under normal conditions, but it could happen if a
disappearing messages timer was set to something unusual like "1 day, 3
hours".)
I also plan to build off of this for an upcoming change, which is why
I did this now.
This is a trivial change that should have no user impact.
`String.formatDurationLossless` calls `NSString.formatDurationLossless`,
so this is a no-op. I think it's slightly better to call a `String`
method from Swift than an `NSString` one.
I did this because it makes an upcoming change easier, but I think it's
useful on its own.
The block-based API returns a token that needs to be explicitly
unregistered, *and* the block should not capture 'self' strongly.
The fixes in this PR come in three flavors:
1. Switch to the selector-based API, sometimes taking advantage of
the fact that extra arguments to an Objective-C method can be
safely discarded (because they are passed at +0).
2. Save the observer token and unregister in deinit.
3. Comment why it's safe to leave the observer registered forever
in this particular case.
This change should have no direct user impact.
This is just a file move.
I think this is a useful change on its own, but it may be useful in
upcoming changes too (e.g., making SignalServiceKit not a pod).
This change should have no direct user impact.
This tests `TypingIndicatorMessage`'s `isOnline` getter.
I plan to add additional tests to this file in a future commit, but I
think this is a useful change on its own.
If we detect database corruption, we should log the [SQLite extended
result code][0], as it may offer insights.
This change also funnels the error handling through a single code path.
[0]: https://www.sqlite.org/rescode.html#extended_result_code_list
Previously, users who experienced database corruption would be asked to
submit debug logs. (Special builds had additional options which were not
generally available, so some of this code was already written.)
Now, if they choose to submit debug logs, they will also be asked to
submit a "database diagnostic" before the logs are submitted. This runs
and logs the results of `PRAGMA cipher_provider`, `PRAGMA
cipher_integrity_check`, and whether `PRAGMA quick_check` succeeds. If
they choose to skip the diagnostic, we still submit debug logs.
Other launch failures, such as "out of disk space", do not run these
diagnostics, as they're irrelevant.
- Drop gift messages sent to groups.
- Drop gift messages if the receipt credential presentation isn’t valid.
- Allow any level in a gift message, for future compatibility.
This broke in 7bef47f356.
The old code cared that is was running on a **specific** background
queue, whereas the intent of the code appears to be “this is slow—don’t
run it on the main thread”.
I believe this new approach is also better for certain pathological edge
cases (though those edge cases would almost certainly never happen with
the global concurrent queues). In the following example, the first check
(old logic) passes, but the second check (new logic) fails.
```
DispatchQueue.main.async {
DispatchQueue.global().sync {
dispatchPrecondition(condition: .onQueue(DispatchQueue.global()))
dispatchPrecondition(condition: .notOnQueue(DispatchQueue.main))
}
}
```
_I recommend reviewing this with whitespace changes disabled._
`RemoteConfig.groupsV2InviteLinks` has been fully enabled for awhile
now. This removes it, and everything that depended on it. Even let us
remove a couple of strings!
This removes `FeatureFlags.giftBadgeReceiving` and
`FeatureFlags.giftBadgeSending`, replacing them with
`RemoteConfig.canReceiveGiftBadges` and
`RemoteConfig.canSendGiftBadges`.
If DNS resolution fails, then it’s expected that there won’t be any
addresses. Fail gracefully in this case.
If DNS resolution succeeds and provides a non-nil but empty list of
addresses, report an error. This shouldn’t happen.
