Zedstrian

In using the 'Controversial' sorting option for my All feed, I found that it was consistently only able to load a limited number of posts before erroring out.

Edit: After testing in Safari via the regular Lemmy client, the same behavior occurring seems to indicate that it's a bug with Lemmy itself, rather than Arctic specifically.

Edit: Confirmed with the Lemmy developers that it had indeed been a bug in the backend, but has already been resolved in a development version of the software testable on voyager.lemmy.ml.

While I've made use of title and domain filters for a few weeks now to filter out unwanted posts from communities I otherwise don't want to block, I noticed today that if you press the 'Add Filter' button for Title, Domain, Community Name, or Username filters, but leave the filter blank, all posts will be hidden.

In the case of Domain filters, oddly up to three recent non-URL posts seem to be able to appear when a Domain filter is blanked out, but not all non-URL posts in general.

For some reason, the same problem doesn't seem to occur when blanking out a Content filter, as far as I can tell.

Here's is a demonstration of the glitch, using a blank Community Name filter:

Most people probably wouldn't notice it, but the gap between 'Search' and 'TRENDING COMMUNITIES' is inconsistent.

I marked the initial height of it with a line in the example GIF below. It gets shorter after tapping the search bar and exiting out of it, and then taller after the page is refreshed.

In the 'Content' section of the Settings page, 'Embeded Crossposts' should be 'Embedded Crossposts'.

Not a bug per-se, but thought I'd make a note of it all the same.

In recording the example videos for my prior bug report, I at one point accidentally entered 'Stean' instead of 'Steam' into the search box, subsequently re-recording the video to correct the typo.

Since then, however, when I enter the word 'Steam' into the search box, conduct the search, and then tap on the search box again to edit the query, it selects the word and suggests a reversion to 'Stean', rather than placing the blinking cursor after Steam to let me edit the text as normal. The issue persists after restarting the app.

After some trial and error of figuring out how I had triggered the glitch in the first place, I replicated it with the word 'Worry' and its typo 'Worrt' for the example GIF below. If it helps in determining the cause, the glitch does not seem to apply to words beyond a certain length, as my initial idea of 'examples' and 'examplez' did not trigger the glitch, nor did 'tomatoes' and 'tomatoez'.

In perusing the Lemmy community list, I've noticed several times the dormant [email protected] community mentioning a consolidation with [email protected]. As the latter instance has since gone offline, I inquired with the [email protected] moderator about switching the consolidation to one of the other two active Ukraine communities.

I was subsequently informed that the change had indeed already been made, but that the version of the community on lemmy.dbzer0.com didn't reflect it. As the updated version is visible on both the original lemmy.ca page, as well as the lemmy.world version of it, is there a reason our version of it is out of date?

Edit: Seems that subscribing to the community to federate it updated it successfully.

Normally, the search tool takes the input query, applies it to the search type selected (Community/Comment/Post/User), and outputs the corresponding results. The user then has the option of switching to another one of the three tabs to repeat the search with a different search type. This functioning normally is demonstrated in the first GIF below:

If the user switches to a different tab before the search completes, however, the search is unable to be applied to the newest tab. Tapping on the search box and pressing enter also doesn't enable the query to be processed in this case, without at least removing or adding a character to it first.

The first example is quickly switching tabs before the initial search is able to load:

The second example is switching tabs after having completed the initial search and quickly returning to the original one:

The third example is switching tabs after having completed the initial search and quickly switching again to a different one:

If you open Lemmy Explorer and tap on the search bar before the community list loads, neither the community count nor the communities themselves will appear until you either enter something into the search bar or cancel the search.

While I'm saving most of my feature requests for after I'm done bug hunting, I thought that extending the same level of searchability to Mbin and Piefed communities would increase the number of communities users have easy access to, along with making it more likely that those communities get new Lemmy users to join.

Of the two, I'd guess that Mbin would be the easier one to implement currently, given that Lemmy Explorer on lemmyverse.net indexes them in a similar manner to Lemmy communities.

If the functionality were implemented, ideally the Mbin and Piefed communities would be searchable via the current Lemmy Explorer tool, perhaps with a filter option to toggle the listing of communities from any of the three services on or off.

Having curated my Lemmy Explorer list to specifically exclude subjects beyond my interests, I don't usually make use of the 'Random Community' button. After just tapping it a few times in a row, however, I noticed that it seemed to be drawing community names from a tiny subset of the 933 communities that I haven't blocked.

People with shorter block lists than me are likely to have a greater degree of variation from the randomizer. That aside, of the hundreds of options it should have been able to choose from, the randomizer only selected the following nine communities during my extensive testing of it:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

Entries near the start of the list were chosen more frequently than those towards the end of it, for some reason.

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.