What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

Gnome

WezTerm version

20220927-071112-9be05951

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

I’m running a standard Ubuntu 20.04 Gnome desktop, but with Wayland. Resizing of wezterm window is broken on this setup: selecting ”maximize” from the title bar context menu or dragging the window against the top or the sides of the screen doesn’t maximize/tile the window, but any resizing that does happen results in any text entered in the terminal thereafter to be get garbled. In this screenshot I’ve first entered wezterm --version before resizing, then dragged the window against the top, then entered wezterm --version again:

To Reproduce

1. Install your bog-standard Ubuntu 20.04 desktop in a VM and boot it up.
2. On the GDM login screen select ”Ubuntu on Wayland” from the bottom right menu, then log in.
3. Install wezterm.
4. Start wezterm.
5. Right-click wezterm’s title bar and select ”Maximize”.
6. Type something

Configuration

no config

Expected Behavior

After step 5, I expect the window to be maximized (i.e. to fill the desktop). After step 6, I expect to see what I typed.

Logs

no logs available

Anything else?

The issue is not present in an X11 session. Ubuntu 20.04 defaults to X11, but I’ve used it with Wayland exclusively since the release without issues. More specifically, I can’t remember seeing resizing issues similar to this with any other application.

I also have a laptop running Ubuntu 22.04 and Wayland, and there all resizing of the wezterm window works just as I’d expect (i.e. just as in any other application).

Hi @claucambra, I tested the appimage and the issue still reproduces.

Bug description

Using a path with umlauts as logDir causes an incorrectly encoded directory to be created and used as log directory, instead of the specified directory.

Steps to reproduce

1. Quit the client.
2. Edit nextcloud.cfg. Set logDir=/home/jani/Tänne (applying appropriately to your home directory)
3. Start the client.
4. ls /home/jani/Tänne

Expected behavior

A listing of new log files residing in /home/jani/Tänne.

Which files are affected by this bug

This question is unclear. The log files are the ones affected.

Operating system

Linux

Which version of the operating system you are running.

Ubuntu 20.04

Package

Distro package manager

Nextcloud Server version

24.0.4

Nextcloud Desktop Client version

3.5.4-20220806.084713.fea986309-1.0~focal1

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.4.2 to 3.4.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

•  Default internal user-backend
•  LDAP/ Active Directory
•  SSO – SAML
•  Other

Nextcloud Server logs

No response

Additional info

This bizarre and otherwise exhaustingly long issue form is lacking a ”What happens instead of my expected outcome” question, so I’m entering it here instead: there are no logs in the specified target directory (it doesn’t even exist if you’ve not created it beforehand). Instead, like in the ye olden days, there is now a directory called Tänne containing the logs. In nextcloud.cfg the path has been re-encoded as logDir=/home/jani/T\xc3\xa4nne/ which is apparently how it should be, since a similarly re-encoded value for a ...localPath with umlauts in the [accounts] section has been working just fine for as long as I can remember using it.

I’m affected by this. Storied from PBS appears the only one of my followed channels to exhibit this, though it may very well just be the only one with audio description tracks provided. For instance, this video has the first description at t=71 (”A huge orange eye opens”). As with Yuseldin’s example, the descriptive track is available, but not selected by default when I open the video in a browser.

Summary

I’m getting these unrequested emails from my self-hosted instance, with no apparent way to disable them. This is bad, bad behavior.

Steps to reproduce

Host an instance running Mattermost 6.6.1. Leave it ”collecting a bit of dust”.

Expected behavior

Not to get spammed with unwanted emails.

Observed behavior (that appears unintentional)

Summary

Keybase key for verifying the tar archive’s signature is missing.

Steps to reproduce

1. try to download https://keybase.io/mattermost/key.asc

Expected behavior

Get a public key to verify the tar archive’s signature.

Observed behavior (that appears unintentional)

404 not found

Yes, they’re dismissible. They can even be brought back on after that (with another tap), and then they do disappear on their own.

I’ve updated Android on the tablet since reporting this, it’s now running Android 11 with One UI 3.1, with no change in the behavior as reported.

I’ve also tested landscape, portrait and autorotate modes, all with the same result.

Hi @TacoTheDank! Yes, this is still reproducible with 0.22.1 and the steps above, plus a disabled ”Start main player in fullscreen”, which, if enabled, prevents the issue from triggering. (I’ll edit the report to add this.)

I normally have that option enabled, so this usually doesn’t affect me anymore, but it’s still there.

All right, thanks for responding anyway!

Subject of the issue

I’m getting a "title":"Please Wait... | Cloudflare" and "description":"Please enable cookies." from Resident Advisor’s podcast episode pages.

Steps to reproduce

curl -sL 'https://api.microlink.io/?url=https%3A%2F%2Fra.co%2Fpodcast%2F821'

Expected behaviour

Not sure what the description should be, but og:title is ”RA.821 Sunju Hargun ⟋ RA Podcast”, so I’d expect that for the title.

Actual behaviour

{
  "status":"success",
  "data":{
    "title":"Please Wait... | Cloudflare",
    "description":"Please enable cookies.",
    "lang":"en",
    "author":null,
    "publisher":"Amazon",
    "image":{
      "url":"https://ra.co/cdn-cgi/images/trace/managed/js/transparent.gif?ray=6e6278b6dae58c30",
      "type":"gif",
      "duration":0.1,
      "size":42,
      "height":1,
      "width":1,
      "duration_pretty":"100ms",
      "size_pretty":"42 B"
    },
    "date":"2022-03-03T12:45:50.000Z",
    "url":"https://ra.co/podcast/821",
    "logo":null
  },
  "statusCode":403,
  "headers":{
    "date":"Thu, 03 Mar 2022 12:45:50 GMT",
    "content-type":"text/html; charset=UTF-8",
    "cf-chl-bypass":"1",
    "permissions-policy":"accelerometer=(),autoplay=(),camera=(),clipboard-read=(),clipboard-write=(),fullscreen=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()",
    "cache-control":"private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0",
    "expires":"Thu, 01 Jan 1970 00:00:01 GMT",
    "x-frame-options":"SAMEORIGIN",
    "expect-ct":"max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\"",
    "set-cookie":"__cf_bm=5KE3AuPAXjTbtqg1orpJUhrCEm74SBvBFamivvHlWzk-1646311550-0-ATV5QxpiBmqa/YdWk1PqMtqR3dvdRyhnoC1vmjBc6/Vx+nDJU9je3vRWZ4TawNbqXf994S1qOAZ9v5WWtlWPCbbjskKZYXuIEV8+aaohm1vE; path=/; expires=Thu, 03-Mar-22 13:15:50 GMT; domain=.ra.co; HttpOnly; Secure; SameSite=None",
    "vary":"Accept-Encoding",
    "server":"cloudflare",
    "cf-ray":"6e6278b6dae58c30-EWR",
    "content-encoding":"gzip"
  }
}

Other info

Prior to discovering microlink.io I’ve used ad hoc hacks to fetch the titles, and had similar problems with the site then; they’re probably doing stupid things at their end, so I don’t know if this is fixable.

(Also, sorry if this wasn’t the right issue tracker, as I couldn’t figure out the canonical place for issues with just using the API from the command line.)