Zedstrian

A minor graphical bug, but thought I'd still make note of it.

It's a distinct bug from the one affecting the Lemmy Explorer loading icon that I posted above a few days ago, as this one seems to affect all loading icons.

Typically, if you tap on a post's image, there is a quick animation that scales the image up from its current location on the screen until it fills the screen completely.

For some reason, sometimes when the post image is tapped on very quickly after the post is loaded, the animation is skipped.

It doesn't seem to occur consistently, but in recording it for the GIF below, it occurred on my fourth loading of the post, each time quickly repeatedly tapping on the post image as soon as it appeared. The GIF itself consists of the third and fourth of those loadings, with the third having the normal animation and the fourth lacking it.

As the difference is harder to see at low frame rates, I tried uploading a high frame rate GIF to no avail, so if needed I can share the original video file via different means.

While scrolling through my curated community list in Lemmy Explorer, I noticed that error messages do not disappear until scrolling finishes, or if the user switches the direction they're scrolling in.

Below I've included examples of how an error message is displayed without and with scrolling. While I scrolled through the feed quickly to keep the GIF short enough to be able to upload it directly to Lemmy, testing indicated that as long as scrolling continues uninterrupted, the error message remains on the screen.

Without scrolling:

With scrolling:

Edit: The same principle seems to apply to loading icons, though since they disappear after scrolling down, it only applies when scrolling up:

If a comment has text that's recognized as a URL, the system auto-generates a link preview for it. As the link preview of the updated comment doesn't replace existing ones, it's possible to repeatedly duplicate link previews via successive edits to the same comment. The view returns to normal once the page is reloaded.

The GIF below demonstrates the bug:

In maintaining my Lemmy blocklist, I noticed that I was unable to block the [email protected] community, despite it seemingly existing if I look for it on lemmy.world directly.

As it doesn't load when accessed via this instance (lemmy.dbzer0.com/c/[email protected]), has it been defederated?

Another obscure glitch with blocking and unblocking.

To make the glitch occur, go to a community, then go to one of its posts, and go to the same community again from the link on that post. If you block or unblock that community and then press the Back button at the top left twice, the original community screen you started on will retain the original blocked/unblocked action, rather than the updated one.

I put a GIF illustrating the menu saying "Block" rather than "Unblock", but testing indicated that the reverse case can also make the menu say "Unblock" rather than "Block".

Before downloading a shortcut to convert my screen recordings to GIF format for my last bug report, I tried uploading the original videos directly. Rather than getting an error for what I assume is video uploads not being supported, or perhaps the 10.5MB video being too large, I received the following error message:

Not sure if it's a glitch, or just an unclear error message, but I'd thought I'd try to be as descriptive as possible.

Edit: The issue has since also occurred with a 7.2MB, 33 second GIF. If it helps narrow down the cause, the issue did not occur when I uploaded a 23 second re-recorded version of the video that ended up being 5.7MB after converted into GIF format.

Don't usually write long posts or comments, but saw this occurring with my last bug report post, and subsequently tested every formatting option to make a comprehensive bug report. I recorded an example of each for demonstration purposes, included below.

Code block:

Formatted line:

Lemmy emoji:

Spoiler formatting:

Last space character on a line:

While marking text with the strikethrough or subscript options, several visual glitches seem to occur that are inconsistent with other formatting options and with how the final text is displayed.

Firstly, the strikethrough preview at times affects the tildes characters, unlike what occurs for previewing bold or italic formatting. This isn't always the case for some reason though, as occurs if I try marking the word 'formatting' in the first paragraph with strikethrough formatting. In that case (as illustrated below), the second set of tildes are not stricken through, along with the 'ing' of 'formatting'.

Another glitch that occurs is that the text appears small when marked with strikethrough formatting in the formatting, seemingly due to the use of a single tilde character for subscript formatting, as is visible in the image above.

Something else that can occur is the strikethrough formatting impacting not just the word and the tildes characters next to it, but several words afterwards as well, such as is the case if I apply it to the first use of the word 'formatting' in the second paragraph above, as illustrated below.

The same occurs for subscript and superscript formatting, as demonstrated below.

Something that affects both strikethrough and subscript formatting (along with superscript formatting) is that their effects are displayed on the edit screen even without closing tilde character(s), as such:

As far as I can tell, the glitches above don't appear to impact bold, italic, or code formatting.

In reviewing my prior comments, I saw that a quote I had included in one of my comments looked odd, and realized that I had forgotten to put a blank line between the quote and my reply to it, as such:

Assuming the intended behavior is for the quote to continue until there's a blank line to end it (I'd think a line break character ending it would make more sense, myself, even though I think a comment looks better with a space between quoted text and non-quoted text, but I assume there's a predefined means by which Lemmy clients are meant to display them), the preview formatting should highlight the full text that ends up being formatted as a quote.

Testing the same behavior with the heading formatting results in the intended behavior, with the heading formatting cutting off with a line break, though I'm not sure if headings are meant to function in the same way or not.

In reference to the community Subscribe, Favorite, and Block actions accessible via the three dot icon to the right of the community name at the top of the screen, the Favorite/Unfavorite actions function normally on community feed pages, but don't switch to the opposite action when tapped as the other two actions do, or as Favorite itself does do when attempting the same from one of that community's post pages.

Note that the Favorite action can be manually updated on the community feed screen either by leaving the screen and returning to it, or adjusting the Block or Subscribe setting after adjusting the Favorite setting.

When a community isn't blocked, the feed refresh swipe action works as normal, with the loading icon animation lasting for less than a second before disappearing.

If the same is done with the page of a community you just blocked, the loading icon will continue until switching tabs and returning, at which point the loading icon disappears.