Opened on 08/21/2014 at 06:32:36 AM
Closed on 09/21/2017 at 04:02:35 AM
#1254 closed change (rejected)
YouTube - whitelist channels / authors
| Reported by: | Gingerbread Man | Assignee: | |
|---|---|---|---|
| Priority: | P4 | Milestone: | |
| Module: | Platform | Keywords: | |
| Cc: | mapx, greiner, trev, sebastian, arthur, haran.yakir@gmail.com | Blocked By: | |
| Blocking: | Platform: | Chrome | |
| Ready: | no | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): | |||
Description
It's not currently possible to whitelist specific YouTube channels since any given video URL doesn't contain information about the author of the video: this information is only available on the page itself.
- AdBlock can do this since version 2.6.33.
- This feature has been requested since at least January 2013, in a thread that currently spans 4 pages.
- Apparently one of the developers said on Twitter that this feature is being considered.
Attachments (0)
Change History (9)
comment:1 Changed on 08/21/2014 at 06:53:34 AM by mapx
- Cc mapx added
comment:2 Changed on 08/21/2014 at 09:13:02 AM by The Binary Son
comment:3 Changed on 08/29/2014 at 09:39:57 PM by trev
- Resolution set to duplicate
- Status changed from new to closed
This is a duplicate of #163. The problem is that implementing this in Chrome without side-effects like triggering a page reload doesn't seem possible.
comment:4 Changed on 08/29/2014 at 09:43:14 PM by trev
- Cc greiner added
- Component changed from Unknown to Platform
- Platform changed from Unknown to Chrome
- Priority changed from P5 to P4
- Ready set
- Resolution duplicate deleted
- Status changed from closed to reopened
Argh, #163 isn't public - I guess we'll resolve it as a duplicate of this issue then.
comment:5 Changed on 09/04/2014 at 05:26:28 PM by trev
- Cc trev sebastian arthur added
Moving comments over from #163.
trev:
The way I see it, in Firefox and Safari we can get the author ID from the document synchronously, the problem is only Chrome. Reloading the page if necessary is always an option (AdBlock seems to get away with it). Since we apparently cannot prevent the player from starting too early, the ideal solution should be reinitiating the player instead of reloading the entire page. Question is whether this is doable in a way that won't break with the next YouTube change.
sebastian:
I agree with Wladimr. I think it is possible to reinitiate the player. However, you would have to rely on YouTube's internal JavaScript APIs, and IMO it is very likely that this code would break rather often when YouTube does changes. Also we probably might want to whitelist not only videos ads. So I guess reloading the page once after getting the channel from the DOM is the best we can do.
greiner:
Yes, I'd also not want to have any implementation-specific code in there for the player.
However, I'm not a fan of the idea that we have to completely reload every page that turns out to be whitelisted.
We could reduce the impact of that first load by prefetching the initial request for such pages with a synchronous XHR that would allow us to delay the actual page load until we know whether to whitelist it or not. It would only add one additional request across the board.
sebastian:
I don't think that blocking the entire background page with a synchronous XHR is a suitable solution.
However, if we use a MutationObserver to get the channel as soon as the parser sees it, we might not have to reload the page at all.
comment:6 Changed on 09/04/2014 at 05:28:51 PM by trev
@sebastian: greiner already tried the approach with MutationObserver, in his tests it didn't work reliably enough (~50% of the cases from what I remember, and probably very much dependent on hardware).
comment:7 Changed on 09/08/2014 at 09:44:32 AM by greiner
I did some digging into the IRC logs. Here's a short summary of my findings from June 11:
- We can get the <html> tag before the ad request.
- The chance of getting the author info before the ad request using setTimeout(0) or MutationObservers was about 2/3 (depending on the page).
- We'd either need to block the thread until we know whether to block the video ad or have an asynchronous way of blocking resources.
comment:8 Changed on 10/21/2014 at 01:21:20 PM by arthur
- Cc haran.yakir@gmail.com added
comment:9 Changed on 09/21/2017 at 04:02:35 AM by sebastian
- Ready unset
- Resolution set to rejected
- Status changed from reopened to closed
- Tester set to Unknown
I'm closing this issue for now. We didn't make any progress in 3 years, and we don't have the capacities to move this forward any time soon. This issues isn't even ready to be worked on, which alone would take some effort to resolve, if we'd even find a feasible solution at all.
The technical solutions considered in this issue, turned out either unreliable or have negative implications on the user experience. Moreover, we'd rely on the volatile structure and behavior of the YouTube website, which would put us into a situation where we'd have to keep up with changes on their end, which can turn into a significant permanent effort. With YouTube having turned into a single page web app, the situation likely have become even more complicated.
However, we might (or might not) revisit this feature, at some point in the future.
I'm very interested in this as well, and have been trying to work with folks on workarounds, but it's becoming VERY frustrating - PLEASE ADDRESS!!!!!