Server Setup Information:

• Wekan version: 1.53
• Deployment Method: snap (tracking stable)
• Operating System: Ubuntu 16.04
• Http frontend: Apache 2.4
• ROOT_URL environment variable https://my-domain.com/kan

Screen recording:

Steps to reproduce:

1. Create a card
2. Click on the comment field, enter ”some text”
3. Click on the description field
4. Close the card
5. Open the card
6. Try to delete the ”some text” comment draft, either by selecting and clearing out the text, or by posting the comment (by selecting ’Comment’)
7. Close the card, open it again

What happens:
The comment draft remains in the comment field. If you posted it at step 6 above, you now have the posted comment plus the same comment as draft.

What I expect to happen:
For the comment draft to have been deleted. If you skip step 3 (i.e. don’t click on the description field but close the card directly), the draft is deleted. While I’d actually prefer the draft to remain in this situation, this is slightly better than the undeleteable draft.

Web Console contents:
Upon closing the card at step 4, console shows this:

remove failed: Internal server error 9f30bda751070caba2631cd997a9c88102b36537.js:1:6261
insert failed: i@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:2640
t@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:2478
c.Collection.prototype[i]@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:89:6720
@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:111:4415
n/</i[n]@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:111:1717
set@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:385103
t@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:165991
inlinedform.js/<@https://my-domain.com/kan/9f30bda751070caba2631cd997a9c88102b36537.js?meteor_js_resource=true:299:375381
9f30bda751070caba2631cd997a9c88102b36537.js:1:6261

Other info

• I’d rate this Severity:Inconvenient
• There is at least one way to delete the draft: after clearing out the text, click the description field, then close the card. This again results in the above errors being reported in the console, but opening the card reveals that the draft is now gone.
• This is slightly reminiscient of issue #1287 (also reported by me way back when), though my guess would be that these are completely unrelated, and I’m only making the link here just in case the solutions happen to be similar (as both deal with drafts and saving).
• I’m attaching snap logs output from today (while testing this), although the events there do not seem to coincide with the draft problem (just card deletion).

All of my devices are affected by this, or something very similar. My server is running Ubuntu 16.06 with Nextcloud 14.0.1 (in a subdirectory). Here’s logs from my

• Nexus 5X (Android 8.0.1 @ Oct 2018 level patches)
• Moto G (2013 model, LineageOS 14.1 / Android 7.1.2)
• Samsung Galaxy Tab 4 (SM-T530, Android 5.0.2. @ Jan 2017 level)

I trimmed them down to (what appears to me as) the essential, filtered out some noise and replaced my username and the server hostname.

Steps to reproduce:

1. (On desktop) Create a new subdirectory under the sync directory, add two JPEG files into it. Wait for changes to sync.
2. (On mobile) Open Nextcloud, select the newly created directory, switch to grid view.

Replace instruction using ln -s to enable Apache site to use a2ensite instead in Debian and derivatives. Closes #884.

Under Apache Web server configuration, there’s a prompt to create a symlink to enable the newly created site:

ln -s /etc/apache2/sites-available/nextcloud.conf /etc/apache2/sites-enabled/nextcloud.conf

As the instructions in this section are written for Debian, Ubuntu, and their derivatives, a2ensite should be used instead:

a2ensite nextcloud.conf

The commands are currently functionally equivalent (AFAIK), but should this change sometime, the latter would be more future proof, besides being much shorter and easier to type.

Additionally, immediately following the ln -s there is a section about Additional Apache configurations, which correctly instructs the use of a2enmod to create the symlinks. Replacing ln -s with a2ensitewould thus harmonize the two sections.

All right. Thanks, Jeremy!

Okay, did it! https://gitlab.gnome.org/GNOME/gnome-terminal/issues/30

Some years back (2013/2014 maybe?) the ’New Window’ and ’New Tab’ menu items were combined into a single ’New Terminal’ item.

This apparently met with resistance from users, so Fedora and recently also Ubuntu have chosen to build Gnome terminal with DISUNIFY_NEW_TERMINAL_SECTION to restore the old behavior.

This unfortunately leaves users of those distros, like myself, who actually prefer the simplicity of ’New Terminal’, with no practical way to restore that functionality (beyond rebuilding the package with the compile-time switch reverted).

After hearing me out, the Ubuntu maintainer suggested I file a bug here, asking to turn the compile-time option into a Gsetting so that the behavior could be more easily adjusted per user preferences.

So that is what I’m asking here.

Jeremy: If this is indeed the popular choice then I fully respect that. I just wanted to voice my disgruntlement, since I feel the way this was set by upstream is much simpler. Sorry for being late with it, didn’t realize this was getting overridden before the change already came into effect.

The plugin refers to $post->post_type before testing it exists, which triggers an error for WP’s built-in (though hidden-by-default since forever) ”link” post type. The error appears quite harmless, as it doesn’t seem to interfere with the link editor’s functionality in any way.

Setup

• Simple Tags version 2.4.7
• WP version 4.9.8
• PHP version 5.6.33

Steps to reproduce

1. Set WP_DEBUG on (define as true)
2. Enable WordPress’ link manager (add_filter( 'pre_option_link_manager_enabled', '__return_true' );),
3. Go to Links > Add New

What happens

Simple Tags’ Settings box in the sidebar shows the following notices:

Notice: Undefined property: stdClass::$post_type in [path to wp]/wp-content/plugins/simple-tags/inc/class.admin.post.php on line 46
Notice: Undefined property: stdClass::$post_type in [path to wp]/wp-content/plugins/simple-tags/inc/class.admin.post.php on line 54

Alright, from my brief testing it would seem this does not reproduce under Wayland.

My recipe above appears to be quite sensitive to details: I have a test user with a clean desktop (with little more customization apart from the extension), and there the recipe works just as written. On the other hand, with my main user account it doesn’t. To clarify: while the steps listed above fail to reproduce the issue with my main account, my main account does manifest the issue too; just not with those exact steps.

My main account starts up the Signal desktop client, Nextcloud client and some other stuff upon login, but so far I haven’t found which of those (if any) causes this difference.

I was, however, able to reproduce the ”see-through hole” effect under both accounts: instead of maximizing Gnome terminal (in step 3), I tile it to cover the left half of my screen, then start up Chrome/Firefox, tile itover the terminal window (i.e. to also cover the left half of the screen), before turning the display off and on again. Firefox then also manifests the hole, as does Gnome terminal when brought back to foreground from below. (Chrome does not manifest the hole, but then again Chrome has always appeared oblivious to the extension here.)

I should mention that I’m leaving the display off for about 4-5 seconds before turning it back on again. I’m not sure if that makes any difference, I’m just doing to to be sure that the ”I’m off” signal has time to propagate back to the system.