Avainsanana Firefox

Hardware-accelerated video decoding (VA-API) broken in Firefox 79 (Wayland)

31. heinäkuuta 2020 klo 17.12
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Firefox, Twitch, Wayland, YouTube

After updating Firefox from 78 to 79, hardware-accelerated video decoding no longer works properly in Wayland: streaming video gets cut off with an error message from the service.

== Steps to reproduce ==
1. Follow the steps in [1] to enable VA-API.
2. Open a Youtube/Twitch video (for instance https://www.twitch.tv/rifftrax), press play

== What I expect to happen ==
For the video be played without issues (as it did with Firefox 78).

== What happens ==
After playing for a while (anything from just a few seconds to a couple of minutes), the video stops and is replaced by a service-specific error message, such as error #3000 (in case of Twitch) or (Youtube). Even when playing, the video also flickers green. After reloading the tab, the video again plays for a few seconds before the error message reappears.

== Other info ==
A fix is apparently already in the works upstream [2].

* [1] https://mastransky.wordpress.com/2020/06/03/firefox-on-fedora-finally-gets-va-api-on-wayland/
* [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1645671

Vastaa viestiin sen kontekstissa (Launchpad)

Unmuting Twitch video pauses playback, when media.autoplay.enabled.user-gestures-needed=false, media.autoplay.default=1

24. huhtikuuta 2020 klo 16.35
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Firefox, Twitch

With `media.autoplay.enabled.user-gestures-needed` set to false and `media.autoplay.default` set to 1 (block audio), which is the default (and other autoplay-related settings in their defaults as well), a Twitch video can only be either paused or playing muted; unmuting the video pauses it and vice versa.

== Steps to reproduce ==
1. Open about:config
2. Search for autoplay in the settings
3. Set media.autoplay.enabled.user-gestures-needed to false
4. Set media.autoplay.default to 1
5. Open a Twitch VOD, for instance https://www.twitch.tv/videos/280106033
6. Try to unmute the video

== What happens ==
The video is unmuted, but also paused

== What I expect to happen ==
For the video to continue playing, unmuted

Vastaa viestiin sen kontekstissa (Launchpad)

I’m able to reproduce this when I set media.autoplay.enabled.user-gestures-needed to false

24. huhtikuuta 2020 klo 16.27
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitch

I’m able to reproduce this when I set media.autoplay.enabled.user-gestures-needed to false; if set to true (which is the default), unmuting does not pause the video.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

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)

Here are the banner settings

5. marraskuuta 2019 klo 13.08
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Firefox, Mattermost

Hi @amyblais, thanks for taking a look!

Here are the banner settings:

# grep -i banner config.json 
        "EnablePreviewModeBanner": true,
        "EnableBanner": false,
        "BannerText": "",
        "BannerColor": "#f2a93b",
        "BannerTextColor": "#333333",
        "AllowBannerDismissal": true

I should also mention that I’ve previously enabled Developer Mode ("EnableDeveloper": true), but I’m not sure it’s related, since the notification in this issue has the normal blue background, not a purple one.

The issue reappeared today for the other affected user, then kept disappearing and reappearing under testing, but we were unable to pin down any specific reason. Their browser console (Firefox) only has this:

websocket connecting to wss://[redacted]/api/v4/websocket websocket_client.jsx:35:20

and the server log meanwhile only has this line repeated:

mlog/log.go:174	{"name":"TypeError","message":"NetworkError when attempting to fetch resource.","stack":""}	{"path": "/api/v4/logs", "request_id": "g8wwo8yu57djmkipjxjxn7hy3y", "ip_addr": "[redacted]", "user_id": "[redacted]", "method": "POST", "err_where": "client", "http_code": 0, "err_details": ""}

(where user_id is the one for the affected user.)

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)

Yep, retrying does work

19. maaliskuuta 2019 klo 19.54
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Firefox

Yep, retrying does work.

I’ve now reported this to Mozilla and linked to it. Thanks, Olivier!

Vastaa viestiin sen kontekstissa (Launchpad)

(My) original report on Launchpad

19. maaliskuuta 2019 klo 19.53
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Tom's Hardware

(My) original report on Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1820514

Any page under https://forums.tomshardware.com/ seems to trigger this, but I have yet to come across other sites that do. Pages can even be saved from the main Tom’s Hardware domain (https://www.tomshardware.com/) without issues.

A workaround discovered by Olivier Tilloy: clicking retry in the download manager completes the save.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

« Uudempia - Vanhempia »