Since recently, editing the description takes two clicks instead of just one. The first click turns the content into a textbox, but it remains unfocused until I click it again.
Issue
Server Setup Information:
- Did you test in newest Wekan?: yes
- For new Wekan install, did you configure root-url correctly so Wekan cards open correctly? yes
- Wekan version: 4.49
- Meteor version: 2.0-beta.4
- Node version: 12.19.0
- MongoDB version: 3.2.22
- Operating System: Ubuntu 20.04
- Deployment Method: snap
- Http frontend if any: Apache
- What webbrowser version are you using? Both Firefox 82.0.2 and Chrome 86.0.4240.183 equally affected.
- If using Snap, what does show command
sudo snap logs wekan.wekan? nothing
Problem description:
Sorry for not providing animation, as peek doesn’t support Wayland. The steps below should be sufficient though.
Steps to reproduce:
- Open a card
- Click on the description once
What I expect to happen:
For the description to have focus (i.e. cursor, to be able to type)
What happens instead:
The description textbox remains unfocused and I can not type into it
Console log contents
site.webmanifest:1 GET https://my-domain.com/site.webmanifest 404 (Not Found)
site.webmanifest:1 Manifest: Line: 1, column: 1, Syntax error.
A bad HTTP response code (404) was received when fetching the script.
mZLgcqMWYXM4o7dmL:1 Uncaught (in promise) TypeError: Failed to register a ServiceWorker for scope ('https://my-domain.com/') with script ('https://my-domain.com/pwa-service-worker.js'): A bad HTTP response code (404) was received when fetching the script.
It seems to refer to to paths in the domain root, whereas my root-url has the path https://my-domain.com/kan. Not sure if that’s related to the issue or not.
I noticed my mongodb.log has grown pretty large:
root@battra:~# ls -lh /var/snap/wekan/common/mongodb.log
-rw-r--r-- 1 root root 3,1G touko 4 21:14 /var/snap/wekan/common/mongodb.log
The first lines in the log are timestamped 2018-03-02T16:39:44.754+0200.
Should the log rotate automatically, but doesn’t for some reason? Alternatively, should I truncate it manually (and if so, how)? I have no use for the logs apart from the occasional bug reports here, so even losing all of it is fine.
There are no related mongodb settings keys AFAICS. (And sorry if this is unrelated to snap packaging, it was just a guess on my part.)
Server Setup Information:
- Wekan version: 2.65
- Operating System: Ubuntu 16.04
- Deployment Method: snap
- Http frontend if any: Apache 2.4
(This came up for me in Wekan issue #1389)
When I try to install the snap (in Ubuntu 16.04), it gets stuck in Run configure hook of "wekan" snap if present. At this time Wekan service is already up and running, but snapd gives up on the configuration after a (built-in) 5 minute timeout and undoes the installation. (I initially thought the Node process was misbehaving, but I no longer think that’s the case here.)
Wekan snap issue #10 seems like the same problem. I enabled snap debugging as mentioned there, and will attach the result of grep snapd from during the installation attempt here.
While the service is up during the configuration phase, it produces journal log entries as usual and I’m attaching the relevant lines here.
I’ve tried purging and reinstalling snapd, disabling IPv6, turning off Apache and any other services that might be in the way (though none of them have caused issues previously), rebuilding the snap with my previous settings built in but none of it has made any difference.
In addition to my main server, I’ve since reproduced this on my desktop machine, and failed to reproduce it on another desktop and a VM with a fairly clean Ubuntu 16.04 install. The only difference between the reproducing and non-reproducing systems I’ve so far found is an Apparmor denial in /var/log/kern.log:
apparmor="DENIED" operation="open" profile="snap.wekan.mongodb" name="/sys/block/" pid=9478 comm="mongod" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
The systems where Apparmor denies mongodb’s access to /sys/block get stuck at the configure hook, whereas systems that don’t report a denial finish the configuration (and installation) successfully.
I haven’t done any customization of Apparmor rules on any of these that I can remember; it’s pretty much dark arts to me which is why I’ve avoided touching it.