Issue metadata
Sign in to add a comment
|
CORB blocks google activeview from working properly when called from tpc.googlesyndication.com
Reported by
pmccann....@gmail.com,
Jul 2
|
||||||||||||||||||||||
Issue descriptionChrome Version : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36 URLs (if applicable) : https://damndelicious.net/2014/04/11/garlic-butter-shrimp/ What steps will reproduce the problem? (1) User chrome to go to the site (2) Open the console and observe the CORB errors to securepubads.g.doubleclick.net What is the expected result? There are no blocked calls from inside a safeframe using the vu function on doubleclick activeview. What happens instead? eg <script>vu("https://securepubads.g.doubleclick.net/pcs/view?xai\u003dAKAOjstOUWj00AfaHHNUiWJdW3MRDzC0cPjqyF9KcoVaF0CDBUDFD3Gg4jXEhCsoTgkmLcICg88PCg2SHCzGEeEpCPsY0BCpllrmNVL4tO2f-cjjrQ7KcNRjlRWDaKtq2dpfho4tEwgrFMrtyfPIz55N_UTh_84RMpld9PVf5DV2CSnvV1plDDC4DIQuq8gUkIDj-yT3aufSG0AQQChGXwGDelB46kxUwyGany-CJ-f8eF0GCO7Gxo-8dXryd6y0ZuA3Xf4ZBTpBtXYKmQvnMS3XKoLlOwfPVPYKVvreSXcvYQ\u0026sai\u003dAMfl-YR--bgRy912Q1rnCk7Dfz-HgnP8wA9N_XkbOu1wr40QOSvewjS0T3uDmRG4-4rQLsLeU6lDennSucmFDA70Ik0ZzTMQeS_HV8ioqtmXPmRrd6kSuSO9Rkjy-WA\u0026sig\u003dCg0ArKJSzNyl0gNLVE4zEAE\u0026urlfix\u003d1\u0026adurl\u003d") </script> is blocked by CORB because the mime type is text/html. It seems the google web server may be responding with the wrong mime type. Perhaps Chrome could not implement CORS for google calls from tpc.googlesyndication.com that are to other doubleclick domains. Please provide any additional information below. Attach a screenshot if possible.
,
Jul 3
Interesting, I get at least a dozen CORB errors to google domains on every load and I can reproduce on a few hundred sites. eg attached load of https://thestir.cafemom.com/parenting_news/212666/viral-fathers-day-shoot-gomes?ct=slider_2
,
Jul 6
Thanks for the report. I'll try to take a look now that I'm back, but the first thing to note is that a lot of the CORB warning messages are red herrings because they're only blocking responses that were empty or errors to begin with, and thus couldn't affect the page's behavior. That's fixed in Chrome 69 by the change in issue 844178 , where we simply don't show the warning message for empty responses anymore. If there are other functional problems with the site with Site Isolation enabled, we're interested in figuring out why. Are you seeing any behavior problems or just the warning messages? Can you try visiting the site in Chrome Canary and see if the warnings are gone? Thanks!
,
Jul 6
I tried visiting https://damndelicious.net/2014/04/11/garlic-butter-shrimp/ in Chrome Beta 68.0.3440.42 and saw lots of CORB warnings, but in Chrome Canary 69.0.3483.0 only one CORB warning was left: https://example.com/?google_gid=CAESENv119x6wj88rIZHujOVRAs&google_cver=1&google_push=AHNF13K2rGnBLIhrHTTgZGvHlhsAdLu1cG1WQpkqdUpnDRwk That looks like a bug in the site (in cookie_push.html)-- the response from example.com is generic and doesn't seem to be something the site would actually depend on. Maybe the "example.com" part was meant to be replaced with something else in the page's source? I also tried visiting https://thestir.cafemom.com/parenting_news/212666/viral-fathers-day-shoot-gomes in both Chrome 68 and Chrome 69. Again, there were lots of warnings in 68 but only one in 69: https://s.amazon-adsystem.com/x/19cb1bfc173dcb98ccec That one is actually an HTML file: ---- HTTP/1.1 200 OK Server: Server Date: Fri, 06 Jul 2018 18:04:31 GMT Content-Type: text/html;charset=ISO-8859-1 Content-Length: 177 Connection: keep-alive Cache-Control: max-age=0, no-cache, no-store, private, must-revalidate, s-maxage=0 Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT p3p: policyref="https://www.amazon.com/w3c/p3p.xml", CP="PSAo PSDo OUR SAM OTR DSP COR" Set-Cookie: ad-id=A1gKj5qmvEQsjky4GIi4sZc; Domain=.amazon-adsystem.com; Expires=Mon, 01-Apr-2019 18:04:31 GMT; Path=/ Set-Cookie: ad-privacy=0; Domain=.amazon-adsystem.com; Expires=Mon, 01-Apr-2019 18:04:31 GMT; Path=/ Vary: Accept-Encoding,User-Agent Content-Encoding: gzip <html><body style="background-color:transparent"> <iframe width="1" height="1" frameborder="0" marginwidth="0" marginheight="0" src="//s.amazon-adsystem.com/v3/pr?exlist=ox&fv=1.0&a=cm&cm3ppd=1"></iframe> </body></html> ---- However, it's being requested from an <img> tag (from an iframe at https://us-u.openx.net/w/1.0/pd?plm=6&ph=6585c845-3352-4cde-9ab7-778c3d7b7585&gdpr=0): ---- <html> <head> <title>Pixels</title> </head> <body> <img src="https://c1.adform.net/serving/cookie/match?party=22"> <img src="https://pixel.quantserve.com/pixel/p-25CIknq_eSg16.gif?idmatch=0&gdpr=0"> <img src="https://x.bidswitch.net/sync?ssp=openx"> <img src="https://ib.adnxs.com/getuid?https://us-u.openx.net/w/1.0/sd?id=537072399&val=$UID"> <img src="https://s.amazon-adsystem.com/x/19cb1bfc173dcb98ccec"> <img src="https://pixel.advertising.com/ups/55981/sync?uid=8ff09946-bfbc-0fbe-09f2-ea3fc22bb874&_origin=1"> </body> </html> ---- Thus, it doesn't matter either way whether it's blocked-- the <img> tag can't process the HTML, so there's no difference if the response is blocked. It's also a bit odd that the site is requesting that HTML file from an image tag, but it doesn't seem like a big problem. Let me know if there are other functional problems you're observing, but otherwise I'm inclined to close this as resolved (since the extra warnings for empty responses are gone in Chrome 69). Hope that helps.
,
Jul 9
The NextAction date has arrived: 2018-07-09
,
Jul 9
Closing bug per comment 4, since the warnings for empty responses are gone in Chrome 69. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by alex...@chromium.org
, Jul 2Owner: creis@chromium.org
Status: Assigned (was: Unconfirmed)