_I recommend reviewing this with whitespace changes disabled._
Previously, Settings → Appearance → Chat Color & Wallpaper → Chat Color
would cause a crash. This was because we had a re-entrant database
transaction.
This fixes that by removing the re-entrant transaction—a fairly simple
fix.
There was also a function here that was immediately called and not used
elsewhere, so I removed the function and inlined its contents. Not
strictly related to the crash. I believe it was originally added in
0574d23b6f.
anyUpdate runs its closure twice with different
messages but the batching context applied updates
always to the same copy of the message.
Also apply lint fixes.
This fixes two small regressions introduced in
80e8379738:
1. There's a bit too much spacing at the top.
2. In dark mode, the grabber had the wrong background color. (As you can
see in the code, my solution here is a temporary workaround before we
do a larger refactor.)
* Little fix for context menu
* Add 'My Stories' section to stories tab
* Add new story thread types
* Show stories in conversation picker
* Support for sending stories
* Update story list when sending stories
* Add basic 'My Stories' view controller
* Initial stories settings screens
* Consolidate TSPrivateStoryThread and TSMyStoryThread into one class
* Require an explicit read transaction to initialize an outgoing message
* Fix linting
* Allow enabling group story from internal settings
* Fix tests
* PR Feedback
This respects the `giftBadges` capability when trying to send gift
badges. In other words, it prevents you from sending gift badges to
someone who lacks the capability.
The bulk of this change involves fetching and saving of this new
capability. The rest of the code involves showing it on the "choose
recipient" screen (and some debug screens).
A migration (introduced in b2c0e975b6)
tries to save legacy avatars to disk. However, if that legacy avatar
data is invalid, we'd crash on launch.
A user encountered this.
Our possible solutions:
1. If legacy avatar data is invalid, just drop it.
2. If legacy avatar data is invalid, try to repair it. (For example, if
it's too large, try to resize it.) This might not fix the user's
issue—unfortunately, we don't know why the avatar was invalid.
3. Loosen our definition of a valid avatar. (For example, increase the
maximum size.) This also might not fix things—we don't know how the
avatar was invalid.
I went with the first solution.
This was difficult to test. While developing, I made a temporary button
that (1) updated a group, giving it an empty legacy avatar buffer (2)
tried to migrate it.
(Thanks to c5bd634ff1 for making this easy
to diagnose!)
In e41335a7b5, `String.glyphCount` was updated to match
`String.count`, which eliminates the need to do the pre-emptive “are
there less than 50 characters” check. Since that commit, both of the
character count checks in this method were calling the same underlying
API, so there’s no need to call it twice, and we can just check it
against the strict upper bound immediately.
Attachments need to be mapped back to their messages consistently, and
downloaded attachments should be tracked by the MediaGalleryManager
once this is set up correctly.
The purpose of this change is to alleviate the
main source of CPU-grinding after sending a
message to a large group: about 20% of the total
time is spent decoding and re-encoding messages as
they are fetched from the DB and then updated with
info about which recipients have acknowledged
delivery.
Prior to this commit, we decrypted the payload and
then processed the message in a single rather deep
call tree that began in `processNextBatch`. There
are two completely different paths through this
tree that lead to handling a delivery receipt
because server-generated delivery receipts have
the necessary info in plaintext in the envelope
and client-generated delivery receipts have it in
the ciphertext.
The idea here is to break incoming envelope
handling into two parts.
In the first part, each envelope is decrypted and
other common activities (like handling sender key
distribution messages) are performed. A processing
request is created for each. Next, processing
requests are handled. It's easy to examine a
processing request to determine if it is a
delivery receipt, and if so, for what outgoing
message. Doing so allows the new
DeliveryReceiptContext class to cache message
fetches and combine updates to the same message.
Processing requests are grouped together so that
sequential delivery receipt requests enjoy caching
of messages and coalescing of updates into a
single fetch/decode/encode/commit. Other kinds of
envelopes are handled immediately to avoid
increasing memory pressure that caching multiple
messages could cause.
If your Boost badge expires but it's not your primary badge, our current
text doesn't make perfect sense.
After some discussion, we settled on the following copy change:
```diff
-Your Boost badge has expired and is no longer visible on your profile.
+Your Boost badge has expired and is no longer available to be displayed on your profile.
```
You'd expect this argument to signal a boolean return, but it returns a
`RecipientPickerRecipientState`. I renamed the argument to (hopefully)
make it clearer.
The gist is:
```diff
-foo = foo + 1
+foo += 1
```
Most of the violations were in generated files, so I changed and re-ran the generator.
A few of these violations required implementing some new methods, which I added tests for.
See [the docs for this rule][0].
[0]: https://realm.github.io/SwiftLint/shorthand_operator.html
Co-authored-by: Max Radermacher <max@signal.org>
Co-authored-by: igor-signal <98181527+igor-signal@users.noreply.github.com>
The goal of this commit is to build a "skeleton" UI for sending gift
badges.
It's totally possible that I haven't anticipated future changes
correctly, but my goal was to have each future change be a separate,
unrelated commit. For example, we need some logic to determine whether a
recipient has the "giftBadges" capability. That can be done separately
from the commit to send the badge message.
I also added "TODO (GB)" in these spots.
As with many other badge gifting tasks, this is behind a disabled
feature flag, so it should have no user impact.
_I recommend reviewing this with whitespace changes disabled._
This fixes violations of [SwiftLint's `implicit_getter` rule][0] by
removing explicit getters when an implicit one would do.
[0]: https://realm.github.io/SwiftLint/implicit_getter.html
And fix the presented content type and filename for the attachments in
a quote (it should be the type and filename of the original
attachment, not the thumbnail).
The `Emoji` enum had an [orphaned doc comment][0], which SwiftLint reported.
This updates that file's generator to fix the error. (SwiftLint is disabled for most of the file, though—a bit unfortunate, but probably correct for generated files.)
[0]: https://realm.github.io/SwiftLint/orphaned_doc_comment.html
