Selective Blocking of JWplayer by Site
I would like to block some sites (entire domains) from injecting JWPlayer iframes while I'm trying to read the site. (The Hill, https://thehill.com, is particularly annoying with this.) However, I need to see content that some other sites embed in JWPlayer, so I can't use the nuclear option of blocking the cdn for jwplayer in my hosts file.
Are there any settings or add-ons available that allow by-domain blocking of JWPlayer? (I don't care if it's a "whitelist" or "blacklist" approach, so long as I can manually determine which sites play and which don't.)
Όλες οι απαντήσεις (9)
See if this helps. https://addons.mozilla.org/en-US/firefox/search/?q=block+JWPlayer
Sorry, not helpful (I should have mentioned that I'd already done that search). HTML5 autoplay is already blocked in my installation, and the very point of JWPlayer is to evade it (which it does quite successfully); none of the other suggested add-ons do so either.
It is usually possible to hide such content via code in userContent.css (only extensions can block it) via a @-moz-document domain(thehill.com){}
Can you post a link to a publicly accessible page (i.e. no authentication or signing on required) where you see this player.?
In reverse order:
The Hill does not require any authentication or sign-on. Just select any story from its front page (it's a "newspaper" with constantly changing, and frequently-but-unpredictably expiring, content, which is why I didn't provide a direct link). The Hill is far from the only offender here; I suggested it as an example precisely because it doesn't require authentication or sign-on.
And I'm not sure that solution will work, because sometimes there is other content that one might want to see (such as PDFs embedded on the page). If I understand the userContent.css suggestion correctly, that would block any external document/link from displaying/playing. The fundamental problem is that JWPlayer operates through a Javascript injection, so I'm not sure that even the userContent.css entry would help in the first place without breaking something else.
I was hoping that either I'd missed something in a setting inside of Firefox, or that someone had developed an extension that wasn't well indexed that handled this.
You can hide specific content with the right selector. I looked at some pages and none show a media player for me, so either I'm not getting media content or it is blocked for me via the auto-play settings. A page that has such a player would help.
You can look at these prefs on the the about:config page to see what settings work for you to block autoplay.
- media.autoplay.default = 5 [0:allow;1:blockAudible;2:Prompt;5:blockAll]
- media.autoplay.blocking_policy = 2
- media.autoplay.allow-extension-background-pages = false
- media.autoplay.block-event.enabled = true
You can open the about:config page via the location/address bar. You can accept the warning and click "I accept the risk!" to continue.
(1) I'm withholding "solved the problem" for further testing; one setting in particular seemed to help... but that just points out another problem.
(2) I had already manually made all of these setting several versions back (I'm not afraid of about:config, I've been a Firefox user since single-digit version numbers). Something in between changed ...blocking_policy from 2 back to 0, without any grey-out or other notice in Settings. There are a lot of moving parts in a complex piece of software like Firefox, so this might have been an unintentional "fix" for a different problem; it's impossible to tell, especially since I can't determine when the change was made or by what (update, extension, whatever). It just wasn't me manually going in and changing the item.
And that's the additional problem. Settings purportedly allows one to block autoplay. It doesn't change this particular about:config setting. When I noted this several versions back (I think it was version 87), developers blew it off with the expectation that if I really expected it to block things of course I'd have to monkey with about:config. My reply that "Then you need a better label for the Setting so that people know that they'll have to do so, such as 'Limit Autoplay' instead of 'Block Autoplay' " got only crickets.
...aaaaand with further testing this was not a solution. After a browser restart, I went back to The Hill and the JWPlayer window was popping up and playing, just not with audio. Similar at other sites.
Is this the problem where there is a video at the top of the article, and when you scroll down past it, it pops into the margin and sticks there as you move around in the article? That isn't a new frame; it's the same frame with new position rules for the element with class="player-position". You can prevent it from moving by overriding the position change rule. However, I don't know whether that will keep it silent. To give it a test:
@-moz-document url-prefix(https://thehill.com/){ /* Prevent video repositioning (9/23/2021) */ .player-minimize:not(.sticky-disabled) .player-position { position: static !important; } }
(That's for either a userContent.css file or a Stylus userstyle.)
It's sort of between the two... because the video doesn't stay in the margin when paging down, but overlaps well into the actual text on The Hill (The Hill is a 3-column design), and pops to the lower right-hand corner (well over a third of the way from the margin) on other sites. cor-el's suggestion at least shut it up... but it's still taking up screen real-estate and bandwidth.
As an aside, it's even worse when scrolling using the keyboard than with a mouse/trackball, because when the short video ends and another tries to start, the player steal focus. That's a longstanding problem with Javascript injections not limited to JWPlayer, though...
What I really want — and it may not be possible — is a way to site-by-site prevent JWPlayer from instantiating at all unless I (and not some automated function on the site or script or anything else) intentionally invoke it.
(comes back a couple of minutes later) I'm afraid that userContent.css rule hung up my installation, I'll have to go through the rest of the userContent file and see if there's a conflict...