#42 WebWorker 'Strict' protection makes video playback unstable, sometimes broken
Closed: Duplicate a year ago by polcak. Opened 2 years ago by redeclipse.


Applying 'strict' setting for WebWorker protection makes video playback unstable, and sometimes outright breaks it on certain websites under certain circumstances. Applying 'medium' setting alleviates the issue. Tested on Linux + Firefox.


OS: Arch Linux, 5.17.1, x86_64
Browser: Firefox 99.0 64-bit with MOZ_ENABLE_WAYLAND=1 set.
JShelter Version: 0.9

Firefox also has hardware acceleration enabled. Running on Mesa 22.0.1.

How to reproduce

  1. Set WebWorker setting to 'strict' in JShelter. (On 'strict' by default on a "Recommended" shield level)
  2. Open any website with videos. Issue appears to be reproduced reliably on libredd.it (and other hosted instances). Youtube does not break immediately, and the issue happens after a few minutes there.
  3. Try to watch any video. For example, this one. (opens a post served via libredd.it, needs HLS to be enabled)

Expected result

Video plays back with JShelter protecting WebWorker on a 'strict' setting.

Actual result

On libredd.it: Video refuses to play back without any WebWorker related errors from JShelter or the playback-related errors from the website in the devtools console.

On Youtube: Video plays back for a good while, but breaks after the player either restarts or if user skips around the video too much.


Setting JShelter WebWorker setting to either 'medium' or 'unprotected' alleviates the issue.

Troubleshooting steps taken

  1. Disabling MOZ_ENABLE_WAYLAND=1 and running Firefox under XWayland.
  2. Running Firefox natively under X.
  3. Removing all other extensions apart from JShelter.
  4. Attempted to play videos under a clean Firefox profile with freshly installed JShelter.
  5. Disabling hardware acceleration in Firefox.

However none of these managed to alleviate the issue.

Additional information / notes

This issue only appears to affect media served via mp4 or other video + audio formats. Stuff like gifs appear to be unaffected.

Issue reported in issue 50. I wrote user doc for working through the issue in that issue as well.

Metadata Update from @polcak:
- Issue set to the milestone: NLNet evaluation

2 years ago

Metadata Update from @polcak:
- Issue unmarked as depending on: #43
- Issue set to the milestone: None (was: NLNet evaluation)

a year ago

This is a duplicate of #80. Steps to workaround in #50 and FAQ. Hopefully, #43 would ultimately resolve the issue.

Metadata Update from @polcak:
- Issue close_status updated to: Duplicate
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.