Avainsanana Firefox

Here’s the updated steps to reproduce

28. huhtikuuta 2021 klo 14.05
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Launchpad, Twitch

Steps to reproduce

  1. Open about:config
  2. Search for autoplay in the settings
  3. Set media.autoplay.default to 1 (”Block Audio”, which is the default)
  4. Set media.autoplay.blocking_policy to 2
  5. Open a Twitch VOD, for instance https://www.twitch.tv/videos/280106033
  6. Try to unmute the video (either by clicking Twitch player’s speaker control button, or by dragging the accompanying volume slider)

What I expect to happen

For the audio to be unmuted.

What happens instead

The audio remains muted, and the volume control/indicator remains in the muted position.


I’m unmotivated to report this to Twitch, as I’m unsure about the precise meaning of media.autoplay.blocking_policy, and I currently don’t use the non-working value for it myself. Feel free to downprioritize this as you see fit, unless the original reporter is still affected. Here’s my downstream report over at Launchpad though, just for reference. (I’ll update it too.)

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Does not appear to have been fixed by Firefox 88

26. huhtikuuta 2021 klo 18.45
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitch

Hi Alex!

It does not appear to have been fully fixed by Firefox 88 for me at least, although the conditions have changed slightly, and the remaining broken behavior is now slightly different too.

First, to update my note above: media.autoplay.enabled.user-gestures-needed has been superseded by media.autoplay.blocking_policy, and setting the latter to 2 is now required to trigger the issue (as it manifests presently); with the setting at either 0 or 1 I haven’t been able to reproduce any variation of the issue.

Now, the video doesn’t get paused anymore, but the unmuting also does not work: clicking the muted indicator just always resets it back to muted, instead of actually unmuting.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

I haven’t seen this since Ubuntu-distributed Firefox was updated to 84

20. joulukuuta 2020 klo 12.12
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitter, Ubuntu

For me this seems to have resolved itself since Ubuntu-distributed Firefox was updated to 84, though for all I know, it may have just coincided with some change implemented at Twitter’s end.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Twitter tabs don’t load in Firefox when set as home

13. joulukuuta 2020 klo 16.37
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitter, Ubuntu

I’m affected by this too, in Ubuntu 20.04 with Firefox 83.0+build2-0ubuntu0.20.04.1.

Tested nightly (85.0a1.en-US.linux-x86_64) with a clean profile, and the issue remains.

Steps to reproduce

  1. Start nightly with ./firefox -no-remote -profilemanager
  2. Create a new profile, select it and click Start Nightly
  3. Open these three tabs (replacing the first-run tabs currently open):
  1. Open preferences, set Home to Custom URLs…, select ”Use current pages”
  2. Close the window
  3. Start nightly again with ./firefox -no-remote -profilemanager, select the previously created profile

What happens

None of the three tabs load any content. The firefox process also doesn’t end after closing this window with the non-working tabs, I have to Ctrl-C out of it.

Further info

Upon subsequent starts, Nightly does appear to correctly load the tabs, whereas for my main Twitter profile and FF 83.0 no amount of restarts seems to help; instead I have to open another tab and open m.twitter.com in it, then click on the home button to have the home tabs load (and close the first, still stuck set of home tabs).

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

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.

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:

  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)

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

Demo
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)

screenshot

Vastaa viestiin sen kontekstissa (Github)

Vanhempia »