OWSTableViewSheetViewController is inherited from InteractiveSheetViewController
and has additional size calculation logic that updates current sheet size based
on UITableView's contentSize. However, there's also a "max height" constraint
that also needs updating - this commits adds that.
Short story: we now properly decide whether the sheet is being resized
or scrolled, fixing the bug.
Long story:
Some users report that they can't scroll the forward message sheet
([example report 1][1], [example report 2][2]). This wasn't just a bug
with the forwarding sheet. It was a bug with all subclasses of
`InteractiveSheetViewController`.
When you gesture on the sheet, there are effectively two modes: "resize
the sheet mode", and "scroll the contents" mode. (See
`beginInteractiveTransitionIfNecessary` for a boolean that expresses
this.) The logic is effectively this:
def getMode():
if sheetHeight < maximumSheetHeight:
# Note: there are some other ways to get this mode, e.g. by
# grabbing the handle. But those aren't relevant for this bug.
return "resize the sheet mode"
else:
return "scroll the contents mode"
Unfortunately, there was a bug in how we computed the max sheet height
if that height was larger than the height of the screen (e.g., in
landscape mode or on a shorter device). That bad height caused you to
get into "resize the sheet mode" incorrectly. This fixes that, and does
a few other cleanups.
[1]: https://github.com/signalapp/Signal-iOS/issues/5366
[2]: https://community.signalusers.org/t/beta-feedback-for-the-upcoming-ios-5-44-release/45401/3
Co-Authored-By: Igor Solomennikov <igor@signal.org>
This fixes one violation of [SwiftLint's `block_based_kvo` rule][0] in
our video player view.
I also removed a method (`playbackTimeDidChange`) for consistency.
[0]: https://realm.github.io/SwiftLint/block_based_kvo.html
It looks like this was removed in
7f4a5f3f7b.
`git grep -w AttachmentCaptionDelegate` and `git grep -w
AttachmentCaptionViewController` both return no results after removing
this file.
Long recipient name in the top right corner would not be faded at the
end upon initial presentation.
This was happening because subviews did not have their final frames at
the end of `layoutSubviews`.
The fix is to call method that updates fading on next run loop run.
I introduced a bug in 16daabdd2e.
In English: I accidentally added an observer to the _old_ superview
instead of the _new_ one.
In pseudocode: here's a diff of what went wrong:
remove_observer_from(old_superview)
-add_observer_to(new_superview)
+add_observer_to(old_superview)
We want the default stroke width to be represented by a position
close to the center of the stroke width slider, with max value being
eight times the default value (four times for the blur tool) and min
value being 20% of the default value.
To do that slider value (which grows linearly) is raised
to power of 3 (2 for blur) when that value is > 1, and only then
that value becomes a multiplier for default stroke width.
• improvement: correct amount of padding between text field and keyboard.
• fix: text field isn't tall enough when there's a message draft and
keyboard isn't up.
• fix: onscreen keyboard briefly changes style to 'light' upon dismissal.
This is done to prevent incorrect layout when moving buttons off-screen
in ImageEditorBottomBar.
All instances of RoundMediaButton always have a fixed size and there are
no cases when it would be necessary for button's layoutMargins to include
safe area (which is inherited from the superview).
This change also fixes a bug when bottom buttons in the crop screen
were not visible. That happened because ImageEditorBottomBar by default
had its controls hidden (with the intent that they are animated in once
view controller's view is visible). That was a poor design choice on my
end and is fixed in this commit.
We frequently send outgoing messages with some parameters, like "link
preview" or "quoted reply", empty.
This change lets those parameters be omitted (instead of explicitly
empty) for brevity.
This is a stylistic change and should have no user impact.
Tested this by sending a regular message, a message with a link preview,
and two messages with photos.
You can add callbacks to be executed when a transaction completes. We
usually do this when sending messages, but not always.
Previously, the logic was "add a callback that runs the completion
function, if it exists." Now, the logic is "if the completion function
exists, add a callback that runs it."
I think this slightly better reflects our intent, and helps reduce
memory usage (and potential capturing?) slightly.
* 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
