gorhill / uBlock

uBlock Origin - An efficient blocker for Chromium and Firefox. Fast and lean.
GNU General Public License v3.0
46.9k stars 3.13k forks source link

Interactive loading of large media elements is not working properly #3183

Closed gwarser closed 6 years ago

gwarser commented 6 years ago

Describe the issue

Looks like unblocking timeout for interactive loading of blocked elements is too short. Clicking on blocked element will not allow media element to load. I'm often forced to disable blocking using context menu or icon in UBO popup because of this. For some video elements this is even worse, because if autoplay is not specified, I must click twice - first to unblock, and then again, to start playback. Maybe UBO should set autoplay attribute for video elements in that case?

After more digging, I see that connection is active, and something is downloaded for ~10 seconds, 3Mbit/s but stops immediately after UBO blocks this video element again.

Any way, if I set timeout to 4000 in messaging.js#L1239 this seems to work, most of the time.


My pings are not so bad to 2s of current timeout be a problem:

$ ping niebezpiecznik.pl
PING niebezpiecznik.pl (104.31.9.183) 56(84) bytes of data.
64 bytes from 104.31.9.183: icmp_seq=1 ttl=58 time=579 ms <-- connection warming-up?
64 bytes from 104.31.9.183: icmp_seq=2 ttl=58 time=379 ms
64 bytes from 104.31.9.183: icmp_seq=3 ttl=58 time=339 ms
64 bytes from 104.31.9.183: icmp_seq=4 ttl=58 time=339 ms
64 bytes from 104.31.9.183: icmp_seq=5 ttl=58 time=314 ms
64 bytes from 104.31.9.183: icmp_seq=6 ttl=58 time=338 ms
64 bytes from 104.31.9.183: icmp_seq=7 ttl=58 time=318 ms
64 bytes from 104.31.9.183: icmp_seq=8 ttl=58 time=315 ms
^C
--- niebezpiecznik.pl ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7311ms
rtt min/avg/max/mdev = 314.730/365.703/579.585/83.216 ms

but if I execute this snippet of code using browser console (https://stackoverflow.com/a/14849420):

var sendDate = (new Date()).getTime();
$.ajax({
    //type: "GET", //with response body
    type: "HEAD", //only headers
    url: "/",
    success: function(){
        var receiveDate = (new Date()).getTime();
        console.log(receiveDate - sendDate);
    }
});

I can easily go above 2s. I tried right now, and I'm on the edge 1956.

One or more specific URLs where the issue occurs

https://niebezpiecznik.pl/post/bad-rabbit-czyli-atak-ulepszona-notpetya-ktory-zaszyfrowal-dane-na-ukrainie-w-rosji-oraz-w-polsce/ They moved video to YT.

Steps for anyone to reproduce the issue

Your settings

Your filter lists

Default + POL

gorhill commented 6 years ago

Duplicate of #2334?

gwarser commented 6 years ago

I'm not sure. On http://www.tomshardware.com/reviews/samsung-gear-vr-headset,4405.html I see UBO click event handler interfering with page own click handler. From description - looks similar. Maybe @yossizahn provided wrong example page to test on.

gorhill commented 6 years ago

He said the issue manifested when using a VPN -- thus quite probably caused by the 2-second limit.

gwarser commented 6 years ago

Weird thing is, I see something is downloaded for 10s maxing my 3Mbit connection, but UBO (or video element?) is not seeing this. Maybe it is related https://bugzilla.mozilla.org/show_bug.cgi?id=1364001 , media.cache_readahead_limit;60 - media will not start playing before 60s buffer will be full. If this is true, on slower connections this will be far worse. I must investigate further. And my example page is no longer useful - they changed player to YT :|

gwarser commented 6 years ago

First thing is - every page now uses <source> tag inside <video> tag, to specify multiple sources. UBO supports only <video src='xxx'>. Because of this, it's hard to find page to test this issue :)

Example: http://demos.flowplayer.org/videotest/minimal.html

gorhill commented 6 years ago

Marking as duplicate of #2334.