I’m testing Gonimo in anticipation of real-word deployment, and so far everything else seems to work as expected, but for some reason I can’t get the ”connection lost” alert to go away once it starts, even after the connection is re-established (as indicated by the video stream resuming). The red overlay (with ”connection lost!”) keeps flashing over the video stream, and the alarm sound keeps ringing no matter what I do in-tab. The only workaround I’ve come up with is refreshing the tab (F5).

In case this is environment-related, my laptop has Ubuntu 20.04 with Chrome 80.0.3987.116, my Android phone has Chrome 80.0.3987.119, and I’ve tested both ways (both as either the baby or the parent). I haven’t tested the Android app yet to see if it’s any different.

I think I’ve (accidentally) found a reliable way to reproduce this:

1. Have a card with a checklist
2. From the card’s hamburger menu, select More -> Delete, but don’t touch the (”Delete card?”) confirmation prompt!
3. With the card deletion confirmation prompt still visible, delete the checklist (choose Delete from the checklist title, then confirm the checklist deletion)
4. Now select Delete from the (still lingering) card deletion prompt

Boom! The card (and the board) is now undeletable.

@amyblais No subpath, just the plain domain.

Your service keeps asking me to verify my e-mail address over and over again. When I open the verification link from the email, the verification succeeds and the yellow notification goes away, but when I return to the site the next day, the notification has reappeared and I have to go through the whole process again. This has been going on for weeks if not months.

I found one Community Forum thread with the same issue, but the ”solution” there just tells the affected user to contact support. https://github.community/t5/How-to-use-Git-and-GitHub/Continual-repeated-requirement-to-verify-email-address-for-users/td-p/18085

Hi @amyblais, thanks for taking a look!

Here are the banner settings:

# grep -i banner config.json 
        "EnablePreviewModeBanner": true,
        "EnableBanner": false,
        "BannerText": "",
        "BannerColor": "#f2a93b",
        "BannerTextColor": "#333333",
        "AllowBannerDismissal": true

I should also mention that I’ve previously enabled Developer Mode ("EnableDeveloper": true), but I’m not sure it’s related, since the notification in this issue has the normal blue background, not a purple one.

The issue reappeared today for the other affected user, then kept disappearing and reappearing under testing, but we were unable to pin down any specific reason. Their browser console (Firefox) only has this:

websocket connecting to wss://[redacted]/api/v4/websocket websocket_client.jsx:35:20

and the server log meanwhile only has this line repeated:

mlog/log.go:174	{"name":"TypeError","message":"NetworkError when attempting to fetch resource.","stack":""}	{"path": "/api/v4/logs", "request_id": "g8wwo8yu57djmkipjxjxn7hy3y", "ip_addr": "[redacted]", "user_id": "[redacted]", "method": "POST", "err_where": "client", "http_code": 0, "err_details": ""}

(where user_id is the one for the affected user.)

Summary

Selecting the ”Refresh the app now” link from update notification doesn’t make the notification go away.

Steps to reproduce

Have MM server updated to latest release. Open an existing session of the web app in Firefox. See the refresh prompt, select ”Refresh the app now”.

Expected behavior

Web page is refreshed, the notification goes away.

Observed behavior (that appears unintentional)

Web page is refreshed, but the update notification is still there, still prompting to refresh.

Verbose version

With some of the most recent updates (perhaps 5.16 and newer), the ”Refresh the app now” link in the update notification (”A new version of Mattermost is available”) on the web app did not make that notification go away for myself and another user. The link did cause a refresh of the page content, but the notification persisted. Meanwhile the version being reported by ”About Mattermost” was the correct (5.16.2).

Ctrl+shift+r or other hard refresh attempts did not have an effect, but logging out and then back in to the site finally did make the notification go away.

We’re both Firefox users, and due to the nature of the issue it was difficult to tell if this was browser-specific, but a fresh login using Chrome (while the previous session in Firefox still showed the notification) did not bring up the notification in the new session.

The issue, though irritatingly persistent while it lasted, was still relatively ephemeral, and now that it’s gone, I wouldn’t know how to reproduce it before the next server update. That said, I’ll happily provide more details if I can.

The git-annex page has a removal warning at the top (introduced here). It currently says ”Warning: GitLab has completely removed in GitLab 9.0 (2017/03/22).”

My guess is it’s actually supposed to say ”Git annex support has been completely removed in GitLab 9.0 (2017/03/22).”

Hi! I’ve been a happy Freecell player for years now, thanks for the nice app.

I recently got a new Samsung S5e tablet, which supports Android’s new split-screen mode, which is obviously very handy for multitasking. But unfortunately Freecell seems to be one of the few applications that do not support this mode: trying to do so just brings up Freecell (alone) with a ”Can’t use this app in Multi window view” message. (I’m attaching a screenshot.)

So I thought I’d send in this wishlist ticket for getting multi-window support in Freecell. I’d particularly like to be able to play videos on the one side while playing Freecell on the other.

I’m using yle-dl 20190614 with GNU Wget 1.19.4 in Ubuntu 18.04.

When trying to download this (and so far this is the only example I’ve come across): https://areena.yle.fi/1-50192791

Wget fails like this:

Resolving ylekaod-a.akamaihd.net (ylekaod-a.akamaihd.net)... 62.183.170.32, 62.183.170.35
Connecting to ylekaod-a.akamaihd.net (ylekaod-a.akamaihd.net)|62.183.170.32|:443... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

It tries a few more times, then gives up. I’m attaching a --verbose log (with LC_ALL=C).

Workaround

I took the wget command from –verbose output and added UA spoofing with -U 'Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.27 Safari/537.17', and with the resulting command I was able to download the file.

Happy to report that the proposed packages did fix the issue for me also. Thanks everyone!