Summary

A ”Mark read” choice in push notifications about new messages, as seen in many IM apps, would be handy in Mattermost Mobile too. Currently the message can only be marked read by tapping the message to open the app (which is slow).

Environment Information

• Device Name: Samsung Galaxy A9
• OS Version: Android 10
• Mattermost App Version: 2.11.0
• Mattermost Server Version: 9.3.0

Steps to reproduce

1. Receive a message notification on the Android app.
2. Pull down the notifications.
3. Expand the received notification.

Expected behavior

Have a ”Mark read” option underneath the expanded notification.

Observed behavior

No ”Mark read” option, only ”Reply”.

I was on my Android device, saving URLs pointing to individual comments in threads at Ubiquiti’s Unifi forums, but later returning to them on my desktop realized that the hash (fragment) portion had been dropped, so that the URLs only pointed to the opening post. Hence, just one link (pointing to the first post) had been saved. This is pretty useless for threads spanning multiple pages, where finding an individual comment is tough without the exact link.

Here’s a (random) example of a URL pointing to the second comment on the third page of one thread. Sharing it from any of Android, iPhone or desktop results in a link pointing to the first post instead.

== System information ==
Ubuntu 23.10, up to date before today’s updates.

== Steps to reproduce (WIP) ==
0. have a group of packages that are kept back from updating, plus some that aren’t (screenshot demonstration attached) below
1. open update-manager
2. (try to) open the kept group, click on their (unchecked) checkboxes
3. do the same for some of the other, non-kept packages
4. repeat 2.-3. for a while

== What happens ==
Update-manager becomes unresponsive, then eventually segfaults:

update-manager[3292]: segfault at 30 ip 00007fc0718b4c41 sp 00007ffc2cca6a68 error 4 in libgobject-2.0.so.0.7800.0[7fc071889000+34000] likely on CPU 4 (core 0, socket 0)

== Other info ==
I’ve marked the steps above WIP because these are the conditions under which I found this today, but I haven’t yet tried narrowing them down, because of course I have little control over which updates are available. (For instance, the kept packages might just be a red herring.)

I initially tried to report the crash file with ubuntu-bug, but despite asking preliminary questions, in the end it never opened a browser to complete the report. I’ll try apport-collect next, but if that fails too, I’ll just attach the crash file here manually.

Sounds good to me!

To correct myself, it looks like the default for the WP plugin is to federate the full content, whereas I’ve opted to just use the excerpt, so assuming most other users don’t change the default, their followers do get the full post content inside the app. I don’t know if that still includes the link back to the blog, but then it’s less of an issue if the link doesn’t go to a browser (even though the reloading behavior may still look a bit confusing).

Thank you for the workaround!

I can see the appeal of staying inside the app, and would usually prefer it myself too, but cases like this do challenge the usefulness of that model.

FWIW, I’ve not come across posts from other sites exhibiting this yet, but then again I’m not following many WP blogs, and I suspect the issue could be prevalent there, as my settings for the ActivityPub plugin are pretty much at defaults.

I’m using the ActivityPub plugin to enable following posts from my WordPress blog. The posts federate as excerpts with a URL pointing to the full post on my site.

Tapping on that URL in the Android app only causes it to reload the post (excerpt) inside the app, instead of opening the URL in either webview or a browser as I’d expect it to.

The (official) IOS app does open the URL a browser, as does Firefox on the desktop, which is why I suspect the Android app being at fault here.

I don’t know of a way to link my blog here it so that it opens in the app (which is a bit ironic), but here’s a deck link to the federated posts on mastodon.social. My personal Mastodon account is on mastodon.social.

Both my Android phone and Android tablet are affected, both are on Mastodon version 2.2.1. The phone is running Android 10 (with Samsung’s One UI 2.0), the tablet is on Android 11 (One UI 3.1).

Below is a screen recording from the Android phone exhibiting the issue: the first tap of the URL opens the federated note in single view, and subsequent taps then just reload that same view.

I just tested uploading from the Nextcloud app, and it is similarly affected: no conflict dialog is shown and the existing file gets overwritten.

Steps to reproduce

1. Have a PDF file with the name ”ä.pdf” (sic) in your Nextcloud.
2. Have a different PDF file with the same name on your IOS device (Files app).
3. Choose to share the file from your IOS device to Nextcloud.
4. Select the folder where ”ä.pdf” already exists.
5. Upload.

Expected behaviour

Get a dialog to choose how to deal with the filename conflict.

Actual behaviour

No dialog. The the existing file is silently overwritten by the newly shared file.

Logs

Nothing in server logs, but here’s the app log (at the default level).

Reasoning or why should it be changed/implemented?

The issue leads to data loss. I discovered this when I realized that saving bills from my banking app by sharing them to my Nextcloud had been doing this for who knows how long. (My electricity bills have the service provider name, ”Oulun Energia Sähköverkko Oy” in their filename.)

Environment data

iOS version: 17.0.3

Nextcloud iOS app version: ”Nextcloud Liquid for iOS 4.9.1.0”

Server operating system:

Web server: Apache 2.4.41

Database: MySQL/MariaDB 10.3.38

PHP version: 8.2

Nextcloud version: 27.1.3.2

Miscellaneous

• This is not reproducible on Android (with my server), which is why I’m pretty sure the fault lies with the IOS app.
• Also not reproducible on IOS with filenames with ASCII-only names (FWICT); this general case was apparently fixed when first reported as Upload via Share Menu Silently Overwrites Existing Files #1737.

Summary

As of this writing, push proxy v5.25.0 was released 5 days ago, but the published assets on Github only include the source code.

Steps to reproduce

As per documentation,

wget https://github.com/mattermost/mattermost-push-proxy/releases/download/v5.25.0/mattermost-push-proxy.tar.gz

Expected behavior

Receive mattermost-push-proxy.tar.gz

Observed behavior (that appears unintentional)

404 Not Found

I have the same issue. I’m doing this in a Linux container (Ubuntu 20.04 inside Ubuntu 20.04), but like matthaios-easy-bi, I’m using npm run build:android to build (as per documentation). This has worked up until 2.0, but with 2.1 it always fails due to non-existent org.webrtc. Manually running npm install prior to npm run build:android makes no difference, nor does node node_modules/react-native-webrtc/tools/downloadWebRTC.js (although it does seemingly download the package successfully).

Here’s excerpts from the build output.