-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make load-on-demand smarter for blocked large media elements #1390
Comments
Why not toggle Firefox's built-in preference |
That partially works, but I know YouTube makes efforts to start playback even if that setting is disabled, by using JS to start the player anyway. |
I want to look into this issue regardless, it's annoying sometimes to have to force a reload of all blocked media elements on a page just because the one we are interested in is behind invisible DOM elements. |
@gorhill this post is about the same issue as the title, but from a different angle so I'm not sure whether to open a new issue. Another way to improve the smarts of the "large-media block" process would be to allow large media loaded from the browser's cache. The use case is: I block large-media by default. I go to a website where I click on a few elements that I wish to see, so they get loaded. Later in the day, I come back to the website, but the large-media gets blocked again even though it would cause no network bandwidth to get it (browser would load it from its cache). In this scenario, blocking the large-media the 2nd time around does not yield the intended benefit (bandwidth reduction) and requires the user to repeat herself when she has already made her preference known. |
Related issues: - #1390 - #2334 The deadline to interactively load a specific media element has been extended from 2sec to 5sec. Clicking over a blocked large media element will cause uBO to lookup and handle all potentially blocked large elements at the cursor position. This should take care of being able to unblock media elements hidden under other DOM object. The CSS style applied to blocked large media elements has been fine tuned to improve interactivity. uBO will now remember the specific media elements which were unblocked and keep them exempted from being further blocked. This would be an issue when unblocking a video and then a bit later seeking to another point in the video, in which case uBO would again block network requests for that video.
URL from original post changed https://discourse.mozilla.org/t/support-ublock-origin/6746/18 |
The original video given as example is |
specific video url ? |
@gwarser this one |
@uBlock-user yes. Auto-play blocking works now in Firefox. But it's not static html video, so no-large-media does not work on it. |
Click to load does not work on videos. I first notices on Firefox NSFW I also tried on GfyCat |
On Firefox, uBO's click handler is never called when clicking the missing video, the browser eats the event. I need to find a way around this quirk. |
Closing as I can't find a reproducible case, it seems changes over time ended fixing this one. |
Background information @ Mozilla Discourse.
User wants to prevent auto-playback of video. Blocking large media elements could be used for this, but unfortunately the current load-on-demand code (which load blocked media elements with a click of the mouse) does not work if the blocked media element is not immediately under the mouse, i.e. if it is covered with other (invisible) DOM elements. uBO should be smarter and attempt to find any and all blocked media elements under the mouse, and load them (and possibly trigger playback for video/audio?)
The text was updated successfully, but these errors were encountered: