Avainsanana Chrome

”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

Summary

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
empty

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: Github
Avainsanat: Chrome, Firefox, Gnome, Nextcloud, 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 (Github)

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)

This is apparently caused by something not in Chromium itself

19. helmikuuta 2012 klo 20.14
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Chrome, Chromium, Epiphany, Firefox

This is apparently caused by something not in Chromium itself: it’s not reproducible in a VM running Oneiric, with 17.0.963.26 from ppa:chromium-daily/dev nor with Chrome 17.0.96356. It *is* reproducible in Precise with the latter too, but not reproducible with Firefox nor Epiphany. In Precise with Chromium 17, it’s reproducible with a temporary profile and a guest login also.

Vastaa viestiin sen kontekstissa (Launchpad)

Ei ”Poista synkronoidut tiedot Googlen hallintapaneelista” -valintaa

8. joulukuuta 2011 klo 18.01
Sijainti: Muut: Google Chrome -ohjeet
Avainsanat: Chrome, Chromium, Google

Henkilökohtainen sisältö -välilehden Synkronointi-osiossa ei ole ”Poista synkronoidut tiedot Googlen hallintapaneelista” -valintaa (Chromium 15 ja 17, Chrome 16).

Vastaa viestiin sen kontekstissa (Google Chrome -ohjeet)