Avainsanana Chrome

Description textbox unfocused after click, have to click twice to start editing

9. marraskuuta 2020 klo 16.14
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Apache, Chrome, Firefox, MongoDB, Snap, Ubuntu, Wayland, Wekan

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.


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:

  1. Open a card
  2. 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.

Vastaa viestiin sen kontekstissa (Github)

Ctrl-v in comment field (rich editor) scrolls the view, hiding the card (when using Firefox)

24. maaliskuuta 2020 klo 10.48
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Firefox, Wekan

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

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

Peek 2020-03-24 10-08

Vastaa viestiin sen kontekstissa (Github)

Rich editor in place despite richer-card-comment-editor = false

24. maaliskuuta 2020 klo 10.32
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Firefox, Wekan

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)


Vastaa viestiin sen kontekstissa (Github)

Can’t get ”connection lost” alert to go away once it starts

2. maaliskuuta 2020 klo 17.01
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Gonimo, Ubuntu

I’m testing Gonimo in anticipation of real-word deployment, and so far everything else seems to work as expected, but for some reason I can’t get the ”connection lost” alert to go away once it starts, even after the connection is re-established (as indicated by the video stream resuming). The red overlay (with ”connection lost!”) keeps flashing over the video stream, and the alarm sound keeps ringing no matter what I do in-tab. The only workaround I’ve come up with is refreshing the tab (F5).

In case this is environment-related, my laptop has Ubuntu 20.04 with Chrome 80.0.3987.116, my Android phone has Chrome 80.0.3987.119, and I’ve tested both ways (both as either the baby or the parent). I haven’t tested the Android app yet to see if it’s any different.

Vastaa viestiin sen kontekstissa (Github)

”A new version of Mattermost is available” notification remains after selecting to ”Refresh the app now”

4. marraskuuta 2019 klo 16.52
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Firefox, Mattermost


Selecting the ”Refresh the app now” link from update notification doesn’t make the notification go away.

Steps to reproduce

Have MM server updated to latest release. Open an existing session of the web app in Firefox. See the refresh prompt, select ”Refresh the app now”.

Expected behavior

Web page is refreshed, the notification goes away.

Observed behavior (that appears unintentional)

Web page is refreshed, but the update notification is still there, still prompting to refresh.

Verbose version

With some of the most recent updates (perhaps 5.16 and newer), the ”Refresh the app now” link in the update notification (”A new version of Mattermost is available”) on the web app did not make that notification go away for myself and another user. The link did cause a refresh of the page content, but the notification persisted. Meanwhile the version being reported by ”About Mattermost” was the correct (5.16.2).

Ctrl+shift+r or other hard refresh attempts did not have an effect, but logging out and then back in to the site finally did make the notification go away.

We’re both Firefox users, and due to the nature of the issue it was difficult to tell if this was browser-specific, but a fresh login using Chrome (while the previous session in Firefox still showed the notification) did not bring up the notification in the new session.

The issue, though irritatingly persistent while it lasted, was still relatively ephemeral, and now that it’s gone, I wouldn’t know how to reproduce it before the next server update. That said, I’ll happily provide more details if I can.

Vastaa viestiin sen kontekstissa (Github)

Checklist item gets overwritten by previous item when selecting another item with mouse

20. toukokuuta 2019 klo 17.28
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Firefox, Snap, Wekan

When a checklist item is in edit mode (through the specific steps below), selecting another item for editing does not take the previous item out of edit mode, and upon selecting a third item (or pressing enter) causes the second item to be overwritten by whatever content is in the first selected item.

Server Setup Information:

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

Problem description:

Steps to reproduce

  1. Have a card with a checklist with 4 (or more) items with contents A, B, C, D (and so on):
  2. Select item A with LBM
  3. Select item B with LBM
  4. Select item C with LBM
  5. Select item D with LBM

What happens
At step 4, when C opens for editing, B remains in edit mode. At step 5, contents of C are overwritten by contents of B (that is, ”C” becomes a ”B”).

What I expect to happen
At step 4, for B to leave edit mode, and at step 5, the contents of C to remain as they are.

Other notes

  • Reproducible in both Chrome and Firefox.
  • Curiously, this does not seem to affect the firstly selected item: in step 3 above, A leaves edit mode correctly and thus B doesn’t get overwritten by the contents of item A in step 4.
  • At step 5, instead of selecting item D, pressing enter has the same effect.

Browser console output

snap logs wekan.wekan
nothing related

Vastaa viestiin sen kontekstissa (Github)

Nope, Chrome manifests this too

15. joulukuuta 2018 klo 22.25
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Wekan

Nope, Chrome manifests this too:

peek 2018-12-15 22-19

Vastaa viestiin sen kontekstissa (Github)

Exception from Tracker afterFlush function: ReferenceError: Ps is not defined

15. joulukuuta 2018 klo 16.21
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Chrome, Firefox, Wekan

Server Setup Information:

  • Did you test in newest Wekan?: yes (current edge is 1.88, the same as stable)
  • For new Wekan install, did you configure root-url correctly? yes
  • Wekan version: 1.88
  • Operating System:
  • Deployment Method: snap
  • Http frontend: –
  • ROOT_URL environment variable: http://localhost

Problem description:
Since (at least) a few days back, my web console (in both Firefox and Chrome) is logging this error whenever I open a card. The same error is also logged for opening a board. Additionally, in the more compact view (when the browser window is small, as in the gif I’m attaching), expanding a list causes the same error, as does closing a card.

This doesn’t seem to affect any functionality AFAICT (although I did notice this while investigating why vertical scrolling within a card is suddenly very slow, but that is probably unrelated and possibly local).

The attached animation is from a fresh install with just the user account and one test card created.

Steps to reproduce:

  1. Open web console
  2. Open a card

What happens:
”Exception from Tracker afterFlush function”, ”ReferenceError: Ps is not defined”. Web console log attached.

If using Snap, output from sudo snap logs wekan.wekan
(Nothing during the error event)

Peek animation:
peek 2018-12-15 15-48

Vastaa viestiin sen kontekstissa (Github)

This does not reproduce under Wayland

6. elokuuta 2018 klo 17.06
Sijainti: Vianhallintajärjestelmät: Nextcloud
Avainsanat: Chrome, Firefox, Gnome, Signal, Wayland, Xorg

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.


Vastaa viestiin sen kontekstissa (Nextcloud)

Etusivun uutis- ja tapahtumaotsikkolinkit rikki

23. huhtikuuta 2017 klo 17.08
Sijainti: Muut: Oulun Palautepalvelu
Avainsanat: Chrome, Firefox, Oulu, saavutettavuus

Sivuston uudistuksen myötä etusivulla nyt olevien uutis-, ilmoitus- ja kuulutusotsikkolinkkien toiminnassa on jotain kummallista. Seuraavassa kuvailemani ongelma ilmenee välillä, välillä taas ei.

Jos valitsen esim. ”Omaishoidontuen ohjeet muuttuvat 1.5.2017 alkaen” -otsikon oikealla hiirennapilla, ja valitsen kontekstivalikon ”Avaa uuteen välilehteen” -toiminnon, uuteen välilehteen avautuu etusivu, ei linkattu artikkeli. Bugi ilmenee myös, jos kopioin artikkelin linkin leikepöydälle (saman kontekstivalikon kautta) ja liimaan sitten tuon kopioidun osoitteen toisen välilehden osoitepalkkiin (välilehdellä avautuu artikkelin sijasta etusivu). Tämä hankaloittaa artikkeleiden jakamista.

Suoraan vasemmalla hiirennapilla avattuina linkit tuntuisivat toimivan kuten odottaisinkin (samalla välilehdellä avautuu siis otsikkoon linkitetty artikkeli).

Onnistuin toisintamaan bugin Firefoxilla (53.0) ja Chromella (58.0.3029.81), mutta tosiaan vain hetkittäin; välillä linkit toimivat myös kontekstivalikon kautta kuten pitääkin, eli otsikkoon linkitetty osoite viittaa artikkeliin eikä etusivulle.

Vastaa viestiin sen kontekstissa (Oulun Palautepalvelu)

Vanhempia »