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.

Currently experiencing this. `lsof /var/lib/dpkg/lock` shows only ”focal” as holding the lock. The same ”focal” process is also eating up all of the CPU. No dpkg or apt processes are listed by `ps` either.

After updating Firefox from 78 to 79, hardware-accelerated video decoding no longer works properly in Wayland: streaming video gets cut off with an error message from the service.

== Steps to reproduce ==
1. Follow the steps in [1] to enable VA-API.
2. Open a Youtube/Twitch video (for instance https://www.twitch.tv/rifftrax), press play

== What I expect to happen ==
For the video be played without issues (as it did with Firefox 78).

== What happens ==
After playing for a while (anything from just a few seconds to a couple of minutes), the video stops and is replaced by a service-specific error message, such as error #3000 (in case of Twitch) or (Youtube). Even when playing, the video also flickers green. After reloading the tab, the video again plays for a few seconds before the error message reappears.

== Other info ==
A fix is apparently already in the works upstream [2].

* [1] https://mastransky.wordpress.com/2020/06/03/firefox-on-fedora-finally-gets-va-api-on-wayland/
* [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1645671

I can confirm that 3.36.4-1ubuntu1~20.04.1 from -proposed fixed the issue (in Boxes) for me, i.e. the dialog text is now wrapped and hence entirely legible.

A fix has recently been committed upstream: https://salsa.debian.org/debian/ddclient/-/commit/82d99d1dfb0fb002a15e081fdc7ccf8f96215dc6

After doing manual dconf cleanup, I’ve been unable to reproduce the issue. That’s since posting the previous comment, so a few days now. So I think I’ll hold off on reporting this upstream for the time being, but I’ll go ahead and do that if the problem still manifests itself.

Thanks again, Daniel.

I removed all but Desktop Icons, Ubuntu AppIndicators and Ubuntu Dock, rebooted and then reproduced the issue. Luckily I’ve found one way to reproduce this, albeit somewhat convoluted and still a bit unreliable, involving Synaptic and window tiling. And as it doesn’t seem to trigger the issue when using another account, I’m now working through settings differences between the two in hopes of finding something crucial.

While doing so, I did discover that dconf-editor is similarly affected:

    touko 12 16:09:32 saegusa gnome-shell[8208]: WL: compositor bug: The compositor tried to use an object from one client in a 'wl_pointer.enter' for a different client.
    touko 12 16:09:32 saegusa gnome-shell[8208]: WL: error in client communication (pid 12364)
    touko 12 16:09:32 saegusa dconf-editor[12364]: Error reading events from display: Katkennut putki
    touko 12 16:09:32 saegusa boinc[2098]: No protocol specified
    touko 12 16:09:32 saegusa boinc[2098]: No protocol specified
    touko 12 16:09:33 saegusa boinc[2098]: No protocol specified
    touko 12 16:09:33 saegusa boinc[2098]: No protocol specified
    touko 12 16:09:34 saegusa gnome-shell[8208]: WL: compositor bug: The compositor tried to use an object from one client in a 'wl_pointer.enter' for a different client.
    touko 12 16:09:34 saegusa boinc[2098]: No protocol specified
    touko 12 16:09:34 saegusa boinc[2098]: No protocol specified
    touko 12 16:09:34 saegusa gnome-shell[8208]: WL: error in client communication (pid 12796)
    touko 12 16:09:34 saegusa gnome-terminal-[12796]: Error reading events from display: Katkennut putki
    touko 12 16:09:34 saegusa systemd[3569]: gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE
    touko 12 16:09:34 saegusa systemd[3569]: gnome-terminal-server.service: Failed with result 'exit-code'.
    touko 12 16:09:34 saegusa systemd[3569]: vte-spawn-da1941e8-60e5-48e5-868b-7348dd1158c7.scope: Succeeded.
    touko 12 16:09:34 saegusa gnome-shell[8208]: Error adding children to desktop: this.layout.get_child_at(...) is null
    touko 12 16:09:34 saegusa gnome-shell[8208]: Error adding children to desktop: this.layout.get_child_at(...) is null
    touko 12 16:09:34 saegusa gnome-shell[8208]: Error adding children to desktop: this.layout.get_child_at(...) is null
    touko 12 16:09:34 saegusa gnome-shell[8208]: Error adding children to desktop: this.layout.get_child_at(...) is null

Looks like dconf-editor did not exit with FAILURE, but the dconf-editor window did disappear just as Gnome terminal’s did.

Happened again:

May 11 17:05:50 saegusa gnome-shell[3619]: WL: compositor bug: The compositor tried to use an object from one client in a ’wl_pointer.enter’ for a different client.
May 11 17:05:50 saegusa gnome-shell[3619]: WL: error in client communication (pid 5170)
May 11 17:05:50 saegusa gnome-terminal-[5170]: Error reading events from display: Katkennut putki
May 11 17:05:50 saegusa systemd[3544]: gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE
May 11 17:05:50 saegusa systemd[3544]: gnome-terminal-server.service: Failed with result ’exit-code’.
May 11 17:05:50 saegusa systemd[3544]: vte-spawn-b269c64d-5376-49ec-83fc-9f4806ac4b30.scope: Succeeded.
May 11 17:05:50 saegusa systemd[3544]: vte-spawn-3294a176-7b32-4995-a11b-fe0fea8b07bc.scope: Succeeded.
May 11 17:05:50 saegusa systemd[3544]: vte-spawn-0b59afd0-1aed-4081-a7d1-801e7c405399.scope: Succeeded.
May 11 17:05:51 saegusa systemd[3544]: Started Application launched by gnome-shell.

But there’s still nothing in /var/crash, nor on the Error Tracker (aside from the aforementioned, unrelated crash from last week).

Turns out the online service was just a little slow to update, and there are in fact reports sent. But the only one post-20.04-upgrade is [1] from last week, which is a gnome-shell crash and IIRC, unrelated to the terminal issue here. It seemed to be triggered by something related to media files and Nautilus, and the logs from the time are different; I’m attaching them here. (I had separated gnome-shell logs out from the main syslog, but I’ve since reverted back to having everything in syslog.)

* [1] https://errors.ubuntu.com/oops/26828e26-8fc9-11ea-acd0-fa163e983629