Closed requiredregistration closed 10 years ago
I try the above steps, and I didn't need to go into the http://chromium-behind-the-scene
scope. A recipe for Youtube with which video can play:
https%3A%2F%2Fwww.youtube.com%0A%09white
list%0A%09%09*%20apis.google.com%0A%09%0
9*%20googlevideo.com%0A%09%09*%20ytimg.c
om%0A%09%09*%20youtube.com%0A%09%09image
%20*%0A%09%09stylesheet%20*%0A%09blackli
st%0A%09%09*%20*%0A
now, by accessing the matrix for behind-the-scene requests and allowing youtube.com, google.com, ytimg.com
I can't make sense of this. Are you saying all the requests for the Youtube page ended up being reported in the http://chromium-behind-the-scene
matrix? What is your browser? Version? OS?
Is it possible you have an extension which downloads or otherwise intercepts the Youtube video? Net requests from extensions will be reported in the http://chromium-behind-the-scene
scope.
i checked your recipe before i click new issue.
yes, that's what i'm saying. the domains had to be allowed there too.
chromium 34.0.1788.0 (244965) windows xp service pack 3
no, i don't have an extension of that kind.
You think this could be related: https://code.google.com/p/chromium/issues/detail?id=332481 ?
Excerpt:
Youtube and adblock plus does not work anymore. Just blackscreen and audio
yes. it's your extension, that, or both.
it's your extension, that, or both.
I see...
Ok so I will flesh out what is going on technically here. If any one else can help investigate, that would be great, because I just can't reproduce what is reported here.
For every call to onBeforeRequest by Chromium engine, the details.tabId
value will be set to the tab id from where the request originate. When tab id is -1, this means the request originate from no particular tab. These are identified as Chromium-behind-the-scene requests by HTTPSB.
Requests which originate from tabs should normally never be reported as being out of tab. So far from what I have observed since the beginning of this project is that it may happen exceptionally, but not normally. So that the fact that it happens here seemingly for all requests on the Youtube page is absolutely abnormal, that is, unless something changed in the beta (or is it dev?) version of chromium (v34 as I can see above).
Since for now I will stick to test and debug stable version of chromium, this bug will have to wait for someone to come with some help or constructive information in assisting investigate it.
ok, i did some more testing with the latest stable google chrome 32.0.1700.76.
it is both, your extension and the NPAPI (Netscape Plugin Application Programming Interface) implementation (and/or the flash player plug-in) in chromium and chromium-based web browsers.
Edit...
ok, i did some more testing with the latest stable google chrome 32.0.1700.76
And? It worked? (at first I read it as "not working either", now unsure re-reading it)
first of all, make sure that the flash player for PPAPI (Pepper Plugin API) is disabled (it is the flash player plug-in bundled with chrome), and enable the one for NPAPI. if you see only the PPAPI one, you have to download the flash player for NPAPI from adobe's website. my guess is that you have it already.
to disable the PPAPI one and to enable the NPAPI one, go to chrome://plugins/, click details, disable the flash player for PPAPI and enable the one for NPAPI.
test with this, http://www.dailymotion.com/video/x17xiu6_how-to-be-quiet-around-a-bison_animals
go to the behind-the-scene matrix and you'll see.
ps: a lot of papi :P
edit: the flash player plug-in for PPAPI is not bundled with chromium. chromium uses the NPAPI one if it is found installed.
Clean install of Chromium Version 34.0.1789.0 with only HTTPSB installed. I didn't have to go to http://chromium-behind-the-scene to allow anything for the video to start playing for me.
Ok, I could reproduce it using the above steps by @requiredregistration.
So essentially a change in the browser is breaking extensions which rely on the fact that plug-ins net traffic was reported as web page net traffic, while now it is reported as behind-the-scene net traffic in newer iterations of chromium (as per http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html).
This breaks Adblock Plus (https://code.google.com/p/chromium/issues/detail?id=332481), which ignores (unlike HTTPSB) behind-the-scene requests. But this also breaks HTTPSB because it makes no sense for a user to have to create rules in the behind-the-scene scope in order for a web page to work properly.
Now I will investigate if and how this could be worked around. If ever there is no workaround, users will have to use rules in the behind-the-scene scope as a workaround, which sucks really.
I didn't have to go to http://chromium-behind-the-scene to allow anything for the video to start playing for me.
@my-password-is-password: Is it possible this was HTML5 video? The problem reported here wouldn't affect HTML5 video/audio (my understanding).
From the GIF you posted, I infer this was the video your were playing: http://www.youtube.com/watch?v=Klk40_AwvPA? If so, this one is HTML5 (you can quickly confirm with right-click on the video).
The youtube video I watch was HTML5. My bad.
@my-password-is-password : Just curious, how did you make the animated GIF? I am trying to find tricks for creating that kind of animation as easy and fast as possible. The video of HTTPSB I created was really tedious to create.
Its called GifCam. Its free and you can download at http://blog.bahraniapps.com/?page_id=21
The download link , http://www.bahraniapps.com/apps/gifcam/gifcam.php, is below Version 3.1 which is the latest.
Well I looked at the net traffic to see if a workaround is possible, and I fear it is not. Details of a typical request linked to the plugin object when onBeforeRequest
is called:
details: Object
frameId: -1
method: "GET"
parentFrameId: -1
requestId: "2521"
tabId: -1
timeStamp: 1389893540579.161
type: "object"
url: "http://static1.dmcdn.net/flash/dmplayerv4/dmplayer-prod-compressed.swf.v958ed97f10a4ef759"
I had hoped to investigate the use of parentFrameId
to infer the tab from which the request originate, but this one field is also neutered. This essentially means a workaround is becoming more difficult, if possible at all.
The only thing left which might be usable is the URL of the request -- the "path" part: if this can be matched to the DOM in one of the tab, then there might be a way to guess the tab from which the request originates.
Looking up something in the DOM of all opened web pages is not something which can be done when onBeforeRequest
is called. There would need a prebuild map of plugin-related URLs to tab ids, which can be quickly looked-up at onBeforeRequest
time. Hackugly..
The issue has been marked "fixed" by Chromium people: https://code.google.com/p/chromium/issues/detail?id=332481. I will close this bug anyway, as it is a confirmed Chromium issue, not an issue with this extension.
http://chromium-behind-the-scene
andafter the reload caused by the scope creation, the
swf
file which is the video player/playback control applet for the flash player is still being blocked even though theyoutube.com
,ytimg.com
,google.com
domains and their subdomains have been allowed (theswf
file is downloaded from thes.ytimg.com
subdomain).now, by accessing the matrix for behind-the-scene requests and allowing
youtube.com
,google.com
,ytimg.com
, and reloading the youtube tab. theswf
file will be downloaded, the video file will start being downloaded, and then playback will start.[reformatted by @gorhill for clarity]