This is a follow up commit to `768ab3e9e4f55b872253d55c53983c19ab4c3d8b` in issue #1531
Testing
-------
**Device:** iPhone 14 Pro simulator
**iOS:** 17.0
**Damus:** This commit
**Steps:**
1. Remove all relays.
2. Add the Damus relay.
3. Add `wss://relay.snort.social/` relay **(with trailing slash)**. Shows up on the relay list. (PASS)
4. Add `wss://relay.snort.social/v1` and `wss://relay.snort.social/v2` to the list. Both show up as separate relays (PASS)
4. Watch logs and wait for the relay list event to be sent out
5. Restart Damus (to help ensure the repro is stable)
6. Try removing the Snort relay by swiping. Relay is removed successfully (PASS)
7. Try removing the "v1" relay by clicking on "Disconnect relay" in the detail page. "v1" relay (and NOT "v2") is removed (PASS)
8. Try adding `nos.lol` from the recommended list. Added successfully. (PASS)
9. Remove `nos.lol` with a long press. (PASS)
Changelog-Fixed: Fix issue where relays with trailing slashes cannot be removed (#1531)
Closes: https://github.com/damus-io/damus/issues/1531
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Signed-off-by: William Casarin <jb55@jb55.com>
Testing
-------
PASS
Device: iPhone 14 Pro simulator
iOS: Tested on iOS 17.0 and 16.4
Steps:
1. Go to appearance settings
2. Enable animations. Shows confirmation dialog. PASS
3. Click cancel. Setting is toggled back. PASS
4. Enable animations again. This time click "OK". Setting stays at what was set, and cache is visibly cleared. PASS
5. Restart app. Changes are persistent. PASS
6. Disable animations. Dialog appears like before. PASS
7. Cancel. Toggles back as expected. PASS
8. Disable animations again. This time click "OK". Cache is cleared. PASS
7. Restart app. Changes are persistent. PASS
9. Click on "clear cache". Confirmation dialog appears. PASS
10. Cancel action. We do not see cache being cleared. PASS
11. Click on "clear cache" and click "OK" this time.
12. We can see the cache being visibly cleared. It shows a loading spinner and "clearing cache", and then we see a checkmark icon with a "cache cleared" indicator. We cannot click the button again for now. PASS
13. Go to home view, scroll through some views, then come back to the setting. Clear cache button is visible again.
Closes: https://github.com/damus-io/damus/issues/1301
Changelog-Changed: Improve UX around clearing cache
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Signed-off-by: William Casarin <jb55@jb55.com>
This change makes the text editor/composer more robust and simple and solves Github issue #1558
It builds on the changes made for #1211, and on Jericho's (Jericho Hasselbush <jericho@sal-et-lucem.com>) discovery during his work on #1544
It uses setContentCompressionResistance, disabled text box scrolling, and dynamic height adjustments (based on more accurate layout calculations) to allow several improvements:
- It ensures lines get wrapped and not overflown
- It uses system native "scroll cursor into view" when typing, eliminating the need to a ghost caret
- It ensures we do not have a scroll view within a scroll view (which is confusing)
- It ensures that we set the height of the text box to its ideal value using a native layout calculation (Removes some issues with copying and pasting larger text)
- It resolves other small issues, such as #1558
Issue #1558 repro
-----------------
Result: VERIFIED
Device: iPhone 14 Pro Simulator
iOS: 17.0
Damus: `476f52562a70c2615ad084640dd1a0ba5c4c12e3`
Issue #1558 steps:
1. Type "hello world, hello @da"
2. Select "Damus" in contact list
3. Try moving cursor to the end of "world". Cursor should have gone there, but it immediately goes back to the end of "@damus " instead.
Testing for #1558
-----------------
Result: PASS
Device: iPhone 14 Pro Simulator
iOS: 17.0
Damus: This commit
Steps:
1. Type "hello world, hello @da"
2. Select "Damus" in contact list
3. Try moving cursor to the end of "world". Cursor goes there.
General functionality testing
-----------------------------
Result: CONDITIONAL PASS.
Summary: Behaviour is improved from #1211 patch, and #1558 is fixed. There are a few remaining issues, but they do not look like regressions from these changes. More details below.
Device: iPhone 14 Pro Simulator
iOS: 17.0
Damus: This commit
Coverage:
1. Basic typing works. PASS
2. Basic user tagging works. PASS
3. Typing long text line wraps the line. PASS
4. Adding newlines to the end of the text works and text is visible (i.e. Text box is expanding with text). PASS
5. Adding lots of newlines causes the text box and inner PostView content to expand, and those contents can be scrolled. PASS
6. Typing text when cursor is out of view (both up and down) causes PostView to scroll the cursor into view. PASS
7. Tagging user on a line positioned at the middle of the screen causes view to scroll cursor into view. PASS
8. Tagging user on a very long line positioned causes view to scroll cursor into view. PASS
9. Pasting very long text (5 paragraphs of Lorem Ipsum) expands the text box as necessary, wraps all long lines, scrolls cursor at the end into view. PASS
10. Scrolling through very long text shows that there is only one scroll view active (PostView's). PASS
11. Typing text that expands text box does not cause jitters. PASS
12. Typing mentions do not cause jitter. PASS
13. Adding newline from the end of a mid paragraph unfortunately still causes cursor to jump to the end of the text. This is an existing bug (https://github.com/damus-io/damus/issues/1521). EXISTING ISSUE.
14. Tagging a user at the end of a line when there are other lines below it may cause the cursor to jump a few characters forward. It is unclear whether this is a regression because prior to this change the cursor would get stuck at the end of the mention. But since this is a very specific edge case that might not be a regression, it might be a good idea to address this on a separate ticket. CONDITIONAL PASS
15. Could not run PostView unit tests due to various build errors on the test target.
Closes: https://github.com/damus-io/damus/issues/1558
Changelog-Fixed: Fix situations where the note composer cursor gets stuck in one place after tagging a user
Changelog-Fixed: Fix some note composer issues, such as when copying/pasting larger text, and make the post composer more robust.
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Signed-off-by: William Casarin <jb55@jb55.com>
Applied the content filters to the hashtag search timeline view, to filter out #nsfw-tagged posts on that view if the user has that setting enabled.
Testing of the fix
------------------
**PASS**
**iOS:** 17.0 (iPhone 14 Pro simulator)
**Damus:** This commit
**Test steps:**
1. Search for #sauna hashtag
2. Pick one post from results that contains multiple hashtags
3. Locally change nsfw filter in the code to another hashtag (I picked #homestead in this example) (This is to make testing easier)
4. Run app on simulator
5. Disable nsfw filtering
6. Search for the #sauna hashtag
7. Ensure that the post from step 2 is there
8. Turn on nsfw filtering
9. Search for the #sauna hashtag again. Ensure that post from step 2 is no longer visible
10. Switch keyword back to #nsfw in the code. Re-run app
11. Search for the #nsfw hashtag. No posts appear (timeline view is empty). (Not sure if this is the desired behavior, but seems reasonable)
12. Turn off nsfw filtering
13. Search for the #nsfw hashtag again. #nsfw posts should appear.
Closes: https://github.com/damus-io/damus/issues/1412
Changelog-Fixed: Apply filters to hashtag search timeline view
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Reviewed-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
- Translate Localizable.strings in pl_PL
- Translate Localizable.strings in sv_SE
- Translate Localizable.strings in nl
- Translate Localizable.strings in ja
- Translate Localizable.strings in hu_HU
- Translate Localizable.strings in es_ES
- Translate Localizable.strings in el_GR
- Translate Localizable.strings in de
- Translate Localizable.stringsdict in sv_SE
- Translate Localizable.stringsdict in nl
- Translate Localizable.stringsdict in ja
- Translate Localizable.stringsdict in hu_HU
- Translate Localizable.stringsdict in es_ES
- Translate Localizable.stringsdict in el_GR
- Translate Localizable.stringsdict in de
- Translate InfoPlist.strings in sv_SE
- Translate InfoPlist.strings in pl_PL
- Translate InfoPlist.strings in nl
- Translate InfoPlist.strings in ja
- Translate InfoPlist.strings in hu_HU
- Translate InfoPlist.strings in es_ES
- Translate InfoPlist.strings in el_GR
- Translate InfoPlist.strings in de
Summary
-------
This fixes the issue at Github #1531 where relays with trailing slashes cannot be removed.
The root cause (Identified by @fishcakeday) was that for a relay to be removed, a certain dictionary entry containing the relay url needed to be removed prior to sending the updated relay list. However those dictionary keys used `String` objects, which cannot tell that two URLs are the same with or without a trailing slash.
To fix the issue, I have used a dictionary with the type `[RelayURL: RelayInfo]`, and made the necessary protocol conformance implementations for RelayURL. This way, URLs are handled with higher accuracy (e.g. Trailing slashes do not matter, URLs that resolve to the same location will match no matter what).
This allows us to leverage the existing parsing and handling logic that comes with the `URL` type, instead of manually handling URL strings.
Generally speaking it is preferrable to work with higher level `URL` or `RelayURL` objects than handle URLs via `String`. There is an opportunity to refactor more code, but I intentionally kept the changes to `RelayURL` limited to the functionality in this issue, because otherwise the changeset becomes very big and risky.
Issue reproduction
------------------
**Device:** iPhone 14 Pro simulator
**iOS:** 17.0
**Damus:** Local build from `476f52562` with the following local change:
``` diff
Signed-off-by: William Casarin <jb55@jb55.com>
Issue reproduction
------------------
**Device:** iPhone 14 Pro simulator
**iOS:** 17.0
**Damus:** `bb2eb904cc`
**Steps:**
1. Repost a note from another account (Account "B")
2. Mute user "B"
3. Check home page and your own profile page. Repost shows up with a muted box.
Fix
Reviewed-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
Summary
-------
This patch fixes the issue where the user might see notes from users that they have muted, if such note has been reposted or quoted.
Furthermore, this patch introduces some improvements on some of the associated views, making them more reusable.
Testing of the fix
------------------
**PASS**
**Device:** iPhone 14 Pro simulator
**iOS:** 17.0
**Damus:** This commit
**Test steps:**
1. Create two test accounts (if not created already). We will use test account "A". Test account "B" is an external test account
2. Make some notes from test account "B" (if non existent)
3. Switch to account "A"
4. Under test account "A", follow account "B"
5. Repost a note from account "B", and quote another note from account "B"
6. Access "account B"'s timeline. Repost and quoted note should all be visible. Layout should look as usual
7. Click on the reposted note. Should appear and it should look normal
8. Click on the note with the quote. Should appear and it should look normal
9. Click on the quoted note. Should appear and it should look normal
10. Now mute account "B"
12. Go back to account "A"'s timeline
13. Repost should appear, but the reposted content should be hidden behind a mute box. Clicking on show/hide should show or hide muted content
14. Note with quoted content should appear, but the quoted content should be hidden behind a mute box. Clicking on show/hide should work as expected
15. Make sure that the layout in steps 13 and 14 look good.
16. Click on the repost to access the thread view. Should be muted as expected.
17. Add a comment to the repost. Comment should appear even if the mute box hides the main note
18. Click on the note with quote to open its thread view. Comments should appear, main note should appear, but quoted content should be behind the mute box
19. Under account "B", add a comment to the quoted notes
20. Under account "A", check in the thread view that "B"'s reply is behind a mute box
21. Reply to the note with the quote. Check that the note appears correctly and that quoted content is behind the mute box (in the post composer view)
22. Find on Nostr a post where one of the replies contains a quoted note. Mute the user of the quoted content, and check that quoted content is now in a mute box
Smoke sanity test
-----------------
**PASS**
**Device:** iPhone 14 pro simulator
**iOS:** 16.4
**Test steps:** Browse a timeline filled with real notes and comments. Go through different notes and threads, mute some users, just to make sure nothing else appears obsviously broken.
Other notes
-----------
I removed this code:
```
.frame(maxWidth: .infinity, minHeight: PFP_SIZE)
```
from `EventShell`, because it was causing the layout to break on "threaded" style event view with muted quoted content (e.g. in a reply with quoted content).
The line of code dates back to `495859e07f`, but I am not sure why this line existed in the first place, or if removing it has any negative impact.
Closes: https://github.com/damus-io/damus/issues/1216
Changelog-Fixed: Hide quoted or reposted notes from people whom the user has muted. (#1216)
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Reviewed-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
Testing
-------
**PASS**
**Device:** iPhone 14 Pro simulator
**iOS:** 17.0
**Damus:** This commit
**Steps:**
1. Setup accounts "A" and "B" that you control. Account "A" will be on our device under test.
2. Post something
3. Make a reply using Account A (Reply 1)
4. Make a reply using Account B (Reply 2)
5. Make another reply using account A (Reply 3)
6. Order of replies should be (top to bottom): 1, 2, 3
7. Mute user B
8. Order of replies should be: 1, 3, 2
Performance check
-----------------
**Device:** iPhone 14 Pro simulator
**iOS:** 17.0
**Damus:** This commit
**Steps:**
1. Locally change the code and add a print statement right before the sorting begins. In that print statement, include the number of events that will be sorted
2. Run Damus and go to a busy thread (I found one with 45 replies)
3. Go to the thread, and monitor the logs.
4. Navigate a bit between replies and monitor logs.
**Results:** I only saw a few print statements being printed with each navigation action, which indicates that we are not constantly re-sorting this object (which would be inefficient). Therefore, it seems like performance/efficiency would not be a problem.
Changelog-Changed: Show muted thread replies at the bottom of the thread view (#1522)
Closes: https://github.com/damus-io/damus/issues/1522
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Reviewed-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
Send relay pool events to nostrdb as well
Whenever we send events to relays, make sure we send them to nostrdb
at the same time.
Changelog-Fixed: Fix profile not updating
Device: iPhone 13 mini (Physical device)
iOS: iOS 17.0.1
Remarks: Some entitlements removed locally to be able to build to device without access to development certificate
Steps
-----
1. Go to the home timeline view.
2. Click on a profile on any post
3. Swipe back to the home timeline view (Do not press "back" button)
4. Click on that same profile again
5. Scroll down the profile
6. Make sure that toolbar looks good (Does not have a white background)
Results: Swiping back from profile does not cause any issues. View layout of the custom navbar looks good
Changelog-Fixed: Fix small graphical toolbar bug when scrolling profiles
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Signed-off-by: William Casarin <jb55@jb55.com>
Changelog-Fixed: Fix localization issues and export strings for translation
Signed-off-by: Terry Yiu <git@tyiu.xyz>
Signed-off-by: William Casarin <jb55@jb55.com>
On iOS 17.0, swiping back from a view that uses
`.navigationBarHidden(true)` caused the `NavigationStack` view to
freeze. This fixes the issue by creating a custom toolbar using
`.toolbar` instead.
Issue reproduction steps
------------------------
I found a very good clue to reproduce this issue from
[https://damus.io/note162rt4fctxepnj9cdtr9a82k7jtw3e33hj742ejly3q84tkwsfars4k9glr](https://damus.io/note162rt4fctxepnj9cdtr9a82k7jtw3e33hj742ejly3q84tkwsfars4k9glr)
**Device:** iPhone 13 mini (Physical device)
**iOS:** 17.0.1
**Damus:** 1.6 (18) 4377cf28ef
**Steps:**
1. Go to the home timeline view.
2. Click on a profile on any post
3. Swipe back to the home timeline view (Do not press "back" button)
4. Click on that same profile again
**Ideal behaviour:** On step 4, you should be taken to the profile view
**Actual behaviour:** The whole timeline view, top bar, etc seems to "freeze" and no longer respond.
Root causing investigation
--------------------------
I attempted various things until I could narrow it down. Here is a
summary of what I discovered:
1. First I attempted to investigate where the deadlock would live, by
analyzing the thread states in the debugger. However:
1. I did not find much differences between the thread states of a
normal app running and the app running after the issue
2. **I noticed that the tab bar at the bottom was still working, so
unless those views are running on different threads, it might not
have been a deadlock**
3. NostrDB ingested and writer threads seemed to be waiting on a
mutex most of the time I paused execution, but that also happened
under normal conditions
4. The crux of what made this difficult is that most of the UI
related threads were in assembly, which was harder to interpret.
However, the top of the stack in those threads were usually
`mach_msg_trap`, which I believe is just the debugger
interrupting execution. Below it, there were usually normal
assembly instructions being run, such as `mov` and `ldp`
instructions _(Move value and load a pair of registers)_, and
stepping through some of those seemed to move the program
counter. So I believe that the threads are running
5. Running `thread info` on some of the threads (e.g. main) revealed
that it seemed to be waiting on `mach_msg2_trap`, which again I
believe is just the debugger pausing execution.
2. **After some more testing, I realized that swiping back only breaks
when swiping back from the `ProfileView`, but not other views**
2. I tried to check if the issue was incorrect hashing of `Router`
objects: `NavigationStack` uses `NavigationPath`, which needs a
collection of hashable elements. I thought that if hashing was done
incorrectly, the NavigationStack might have issues managing views.
But that did not seem to be it either.
1. I tried experimenting with the hashing logic for the Profile
router. No changes
2. I tried purposefully messing up with the hashing logic of a good,
working view by adding random numbers into the hash. No issues on
swiping out of that view either.
3. That lead me to the possibility that the issue is within the
`ProfileView` body. I commented parts of the code out and tested each
portion of it in a binary search fashion, and narrowed it down a
specific line:
```
.navigationBarHidden(true)
```
Whenever I remove this line or set this to `false`, the freezing no
longer occurs. According to the Apple developer docs, this is
deprecated:
[https://developer.apple.com/documentation/swiftui/view/navigationbarhidden(_:)](https://developer.apple.com/documentation/swiftui/view/navigationbarhidden(_:))
I tried to replace it with its newer replacement: `.toolbar(.hidden,
for: .automatic)`, but that also causes the freeze.
So, just removing that line fixes the freeze, however it breaks the
layout by showing the unwanted back button.
Fix
---
I was able to fix it by implementing the custom toolbar under `.toolbar`
modifier, and hiding the back button (as opposed to the whole nav bar)
Testing of the fix
------------------
**PASS**
**Device:** iPhone 13 mini (Physical device)
**iOS:** iOS 17.0.1
**Damus:** This commit
**Special remarks:** Some entitlements removed locally to be able to
build to device without access to development certificate
**Test steps:** Same as reproduction steps
**Results:** Swiping back from profile does not cause any issues. View
layout of the custom navbar is unaltered in appearance.
iOS 16 smoke test
-----------------
**PASS**
**Device:** iPhone 14 Pro simulator
**iOS:** 16.4
**Damus:** This commit
**Special remarks:** Same as test above
**Test steps:** Same as reproduction steps. However here we are not
checking the freezing (as it was not reproducible in the simulator). We
are checking that the changes did not break navigation, nor layout, nor
caused any build issues.
**Results:** Working as expected
Closes: https://github.com/damus-io/damus/issues/1449
Changelog-Fixed: Fix UI freeze after swiping back from profile (#1449)
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Signed-off-by: William Casarin <jb55@jb55.com>
This adds profiles to nostrdb
- Remove in-memory Profiles caches, nostrdb is as fast as an in-memory cache
- Remove ProfileDatabase and just use nostrdb directly
Changelog-Changed: Use nostrdb for profiles
When users view who a certain person follows, now they will see an extra
tab to see the hashtags that they follow.
This new tab contains a list of followed hashtags, each of which
includes an option to follow/unfollow the hashtag, as well as the
ability to visit the hashtag timeline
Testing
**iOS:** 17.0 (iPhone 14 Pro Simulator)
**Damus:** (This commit)
**Test steps:**
1. Go to search view, search for a couple of hashtags: #apple, #orange, #kiwi
2. Go to the test accounts own profile via the drawer menu
3. Click on "Following". Make sure there are two tabs now.
4. Scroll down, switch tabs between "People" and "Hashtags". Make sure that scrolling and switching tabs work
5. Unfollow and follow a user. Make sure that this still works
6. Make sure that #apple, #orange, #kiwi hashtags are visible under the "Hashtags" tab
7. Unfollow "#kiwi". Check that the button label now switches from "Unfollow" to "Follow"
8. Click on "#kiwi". Make sure that it takes you to the page where posts with that hashtag appears
9. Go to @jb55's profile
10. Click on "Following"
11. Ensure that there is a "Hashtags" tab
12. Check that @jb55's followed hashtags are shown (not your own)
13. Follow one of the same hashtags as @jb55's
14. Go back to your own profile and go to your own following view again.
15. Make sure that this newly added tag is present on the list, and that #kiwi is not.
Closes: https://github.com/damus-io/damus/issues/606
Changelog-Added: Add followed hashtags to your following list
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Reviewed-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
This simplifies our content filters so that it is a bit more flexible
for future additions.
Fixes: 0957cc896cc8 ("Add "Do not show #nsfw tagged posts" setting")
This commit adds a setting where the user can choose to hide notes with
a #nsfw hashtag. This setting was implemented to allow users to filter
out adult or other unsafe content.
I moved the code logic for content filtering into a new file, and
defined a protocol for content filters. Although the logic is still
simple, this might help in developing a flexible API in case we have
more complex filtering needs in the future.
I also modified the name of the "Appearance" setting to "Appearance and
filters", to make it easier for users to intuitively find this setting.
(Note: Re-translations of this string might be necessary)
**PASS**
**iOS:**
- iOS 17.0 (iPhone 14 Pro)
**Damus:** (This commit)
**Steps:**
1. Follow another account that you control (Account B)
2. On account B, post a note saying "#test this is a test". This note should show up on the home feed.
3. On account B, post a note saying "#nsfw this is a test". This note should NOT show up on the home feed
4. Go to settings and disable the NSFW filter. Go back to the home view. The #nsfw post should now show up.
5. Close app and reopen. NSFW post should still show up (i.e. Setting should be persistent)
6. Unfollow account B
7. Close app and reopen.
8. Follow the "#grownostr" hashtag
9. Turn on the NSFW filter
10. On account B, post a note saying "#grownostr this is a test". This note should show up on the home view.
11. On account B, post a note saying "#grownostr #nsfw this is a test". This note should NOT show up.
12. Double-check the "notes and replies" tab. Note should NOT show up there either.
12. Turn off NSFW filter
13. Note from step 11 should now show up.
14. Go to Universe view and find a post with a hashtag. Remember where the post is.
14. Locally change the tag keyword from "nsfw" to that hashtag (Note: I had to test this way because my posts were not showing up in the Universe view)
15. Turn off the filter. Check post is there, in the Universe view.
16. Turn on the filter. Check post is no longer there in the Universe view. (Check the neighboring posts are the same, to make sure)
17. Bring back the code to its normal state.
18. Search for "#nsfw". Make sure that #nsfw appears (I believe this is ok, because it means the person is purposefully searching for it)
Closes: https://github.com/damus-io/damus/issues/1412
Changelog-Added: Add "Do not show #nsfw tagged posts" setting
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Signed-off-by: William Casarin <jb55@jb55.com>
This uses a simpler variant that doesn't require a library. It is also
much faster and doesn't cause a delay when you open the relay view.
Not sure why I needed to touch other parts of the code to make the build
work. Probably xcode beta thing?
Changelog-Changed: Increase size of the hitbox on note ellipsis button
Closes: https://github.com/damus-io/damus/issues/1454
Signed-off-by: Daniel D’Aquino <daniel@daquino.me>
Signed-off-by: William Casarin <jb55@jb55.com>
