Expected behaviour

Selecting ”open main dialog” from the client menu brings up the main dialog.

Actual behaviour

Selecting ”open main dialog” from the client menu either does not bring up the main dialog, or brings it up only to have it disappear almost immediately. The location of the main dialog, when it does pop up, also seems random: sometimes it pops up in the top left corner of the scereen, sometimes at the center of the screen, sometimes right where the tray menu is.

If I’m quick enough to bring the mouse cursor over the main dialog when it pops up, the window seems to stay, until I take the cursor out of it, at which point the window disappears.

The settings window does still open as normal when selected, and works without issues.

Steps to reproduce

1. Select ”open main dialog” from the client (”tray”) menu

Client configuration

Client version: 3.0.0-20200821.171045.ff175088a-1.0~focal1

Operating system: Ubuntu 20.04, Wayland

OS language: Finnish

Qt version used by client package (Linux only, see also Settings dialog): Don’t know where to find that. The settings dialog only says ”Version 3.0.0 (Ubuntu)” AFAICT.

Client package (From Nextcloud or distro) (Linux only): Don’t understand the question.

Installation path of client: /usr/bin/nextcloud

Logs

The client debug log from the time of trying to open the main dialog shows this:

2020-08-28 19:50:04:856 [ debug nextcloud.gui.systray ] [ OCC::Systray::computeWindowReferencePoint ]:  screenRect: QRect(0,0 2560x1440)
2020-08-28 19:50:04:856 [ debug nextcloud.gui.systray ] [ OCC::Systray::computeWindowReferencePoint ]:  taskbarRect: QRect(0,0 2560x32)
2020-08-28 19:50:04:856 [ debug nextcloud.gui.systray ] [ OCC::Systray::computeWindowReferencePoint ]:  taskbarScreenEdge: OCC::Systray::TaskBarPosition::Top
2020-08-28 19:50:04:856 [ debug nextcloud.gui.systray ] [ OCC::Systray::computeWindowReferencePoint ]:  trayIconCenter: QPoint(73,507)
2020-08-28 19:50:04:856 [ debug nextcloud.gui.systray ] [ OCC::Systray::computeWindowPosition ]:        taskbarScreenEdge: OCC::Systray::TaskBarPosition::Top
2020-08-28 19:50:04:856 [ debug nextcloud.gui.systray ] [ OCC::Systray::computeWindowPosition ]:        screenRect: QRect(0,0 2560x1440)
2020-08-28 19:50:04:856 [ debug nextcloud.gui.systray ] [ OCC::Systray::computeWindowPosition ]:        windowRect (reference) QRect(-127,36 401x511)
2020-08-28 19:50:04:856 [ debug nextcloud.gui.systray ] [ OCC::Systray::computeWindowPosition ]:        windowRect (adjusted ) QRect(4,36 401x511)
2020-08-28 19:50:04:859 [ warning default ]:    qrc:/qml/src/gui/tray/UserLine.qml:46: TypeError: Type error
2020-08-28 19:50:04:861 [ warning default ]:    qrc:/qml/src/gui/tray/UserLine.qml:46: TypeError: Type error
2020-08-28 19:50:04:863 [ warning default ]:    qrc:/qml/src/gui/tray/UserLine.qml:46: TypeError: Type error
2020-08-28 19:50:04:865 [ warning default ]:    qrc:/qml/src/gui/tray/UserLine.qml:46: TypeError: Type error
2020-08-28 19:50:04:868 [ info nextcloud.sync.accessmanager ]:  2 "" "https://(MY SERVER URL)/ocs/v2.php/apps/notifications/api/v2/notifications?format=json" has X-Request-ID "b0e242bb-588d-455f-a53d-066d8d0b9f42"
2020-08-28 19:50:04:868 [ debug nextcloud.sync.cookiejar ]      [ OCC::CookieJar::cookiesForUrl ]:      (REDACTED)
2020-08-28 19:50:04:869 [ info nextcloud.sync.networkjob ]:     OCC::JsonApiJob created for "https://(MY SERVER URL)" + "ocs/v2.php/apps/notifications/api/v2/notifications" "OCC::ServerNotificationHandler"
2020-08-28 19:50:04:886 [ warning default ]:    qrc:/qml/src/gui/tray/Window.qml:473:17: QML MouseArea: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
2020-08-28 19:50:04:886 [ warning default ]:    qrc:/qml/src/gui/tray/Window.qml:496:17: QML Image: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
2020-08-28 19:50:04:886 [ warning default ]:    qrc:/qml/src/gui/tray/Window.qml:510:17: QML Column: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
2020-08-28 19:50:04:886 [ warning default ]:    qrc:/qml/src/gui/tray/Window.qml:547:17: QML Button: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
2020-08-28 19:50:04:886 [ warning default ]:    qrc:/qml/src/gui/tray/Window.qml:487: ReferenceError: hovered is not defined

Meanwhile, in syslog from the time:

Aug 28 19:50:04 saegusa gnome-shell[4105]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x4200016 specified for 0x4200014.
Aug 28 19:50:31 saegusa gnome-shell[4105]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x4200016 specified for 0x4200014.
Aug 28 19:50:35 saegusa gnome-shell[4105]: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x4200016 specified for 0x4200014.
Aug 28 19:50:47 saegusa kernel: [17841.949249] nextcloud[55212]: segfault at ffffffffffffffff ip 00007f2b3b765671 sp 00007ffe18796c78 error 5 in libgobject-2.0.so.0.6400.3[7f2b3b737000+36000]
Aug 28 19:50:47 saegusa kernel: [17841.949258] Code: b5 2c 02 00 48 8b 34 d8 eb b6 66 66 2e 0f 1f 84 00 00

Having shot myself in the foot by rewriting already pushed history, it occurred to me that perhaps I could have the commits list in interactive rebase reflect the commits’ push status in color. If lines of commits that I’ve already pushed to a remote were colored red (or any sufficiently differentiating color), I might actually notice when I’m about to screw up again.

To illustrate what I mean, here’s a mockup I made. This is what it would look like if this was my commit history, and 8b0ce7b was the last commit I had already pushed to a remote:

I have no previous experience in modifying syntax highlighting code, and I have no idea if what I’m suggesting is even possible with vim, so I figured I’d open this request first in case it’s a silly idea, or conversely, if you deem this useful enough to implement yourself.

For future reference, this was probably Ubuntu bug #1875558 (”libproxy1-plugin-gsettings triggers a lot of warnings”).

This is still an issue.

@denish-kanabar For undeleteable cards, see #2613 and a workaround in the comments.

Comments can no longer be updated, as pressing the Edit button just reverts the comment back to what it was prior to editing. Both rich and non-rich editor are affected.

Server Setup Information:

• Wekan version: 3.89
• Operating System: Ubuntu 16.04
• Deployment Method: snap
• Http frontend if any: Apache
• Web browser: both Chrome and Firefox affected

Steps to reproduce

1. Add a comment to a card.
2. Click the edit link to start editing the comment, make some changes.
3. Click the Edit button.

What I expect to happen
For the comment to reflect the changes made when editing.

What happens instead
The comment content reverts back to what it was prior to editing.

Logs
Nothing in browser console log, nothing related in server log.

Folders for auto upload? I have Camera twice (/storage/emulated/0/DCIM/Camera; once for pictures, the other for videos), OpenCamera (/storage/emulated/0/DCIM/OpenCamera) and Screenshots (/storage/emulated/0/DCIM/Screenshots).

(I only tried OpenCamera briefly, recently, and have since uninstalled it. The issue at hand was present already back when I first got this phone and installed Nextcloud on it, last July.)

I’ve always had auto upload enabled until now, so can’t say whether it’s dependent on that. I could try disabling it next time the issue re-emerges; as dictated by Murphy’s law, I was unable to trigger it just now that I intentionally tried to.

Oh, and I am running Beta (so currently 3.11.0 RC4) of the Nextcloud app. Can’t remember when I enrolled in.

I presume updating an existing installation is just a matter of replacing the existing files with files from the new release, but as this isn’t made explicit in the readme, I’m just a bit apprehensive about going ahead with it.

Problem description
Using ctrl-v to paste content into a comment causes the view to scroll back horizontally so that if the card was already at the right edge of the view, it seemingly pops out of view. This happens when using Firefox; Chrome seems unaffected.

I’m currently unable to test whether the non-rich editor is affected due to #2967, and also, as I was exclusively using non-rich editor prior to this, I can’t say if this occurred with the 3.85 refresh or whether it was here with the rich editor even before.

Server Setup Information

• Wekan version: 3.85
• Operating System: Ubuntu 16.04 (19.10 in another test VM)
• Deployment Method: snap
• What webbrowser version? Firefox 74.0, Chrome 80.0.3987.149

Logs contain nothing related to this AFAICT.

Steps to reproduce

1. Copy something to clipboard
2. Have a board with enough lists to fill the view horizontally, or contract the browser window to have one list at the right edge
3. Open a card from the rightmost list
4. Select the comment field, press ctrl-v

Demo
Here I’m first typing something, then pasting below it (using ctrl-v) to cause the unwanted scrolling to occur.

After today’s snap refresh to 3.85, rich editor is used for comments despite richer-card-comment-editor being set to false. Yesterday this was still working, and I didn’t change the settings, so it’s something to do with the latest refresh.

Server Setup Information:

• Wekan version: 3.85
• Operating System: Ubuntu 16.04 (19.10 in another test VM)
• Deployment Method: snap
• What webbrowser version? Firefox 74.0, Chrome 80.0.3987.149

Problem description:
(Nothing related in any logs)