Network.requestIntercepted does not intercept requests when chrome is started with a new user-data-dir for the first time
Reported by
jarrod.c...@gmail.com,
Sep 12 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36 Steps to reproduce the problem: This repo demonstrates the undesirable behavior: https://github.com/JarrodCTaylor/cri-request-interception What is the expected behavior? Requests should the intercepted when using a user-data-dir for the first time What went wrong? When attempting to run the code from https://github.com/cyrus-and/chrome-remote-interface/wiki/Intercept-and-block-requests-by-URL the first time chrome is started with a new user-data-dir Network.requestIntercepted doesn't intercept requests. If Chrome is stopped and started again with the same user-data-dir it works as expected. This only happens when not using the --headless flag. When used in conjunction with chrome-launcher it seems as though the code doesn't work as chrome-launcher creates a new user-data-dir every time. Here is a repo demonstrating this behavior: https://github.com/JarrodCTaylor/cri-request-interception Did this work before? N/A Chrome version: 61.0.3163.79 Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Sep 13 2017
,
Oct 10 2017
FYI allada this is a blocker for Lighthouse/Audits to move off of setBlockedURLs (https://github.com/GoogleChrome/lighthouse/issues/3516) if you could factor that in when prioritizing for fixit :)
,
Nov 16 2017
Indeed there is some oddness here. https://github.com/paulirish/cri-request-interception/blob/fixes/index.js is a repro where interception fails unless the *headless flag* is included. (usage user-data-dir doesn't appear to matter) I was, however, able to get https://github.com/GoogleChrome/puppeteer/blob/master/examples/block-images.js working with `headless:false`, which makes this even more mysterious.
,
Dec 13 2017
Network.requestIntercepted is experimental...
,
Dec 13 2017
@pfeldman, Not sure if this is the place to discuss this at all (if you can point me to an issue tracker to use instead, happy to take it there.) Network.requestIntercepted may be experimental, but this issue means that the experiment essentially can't be used by a whole class of people that are automating Chrome sessions. Is your recommendation to not use requestInterception, and to instead use setBlockedUrls? Request interception is far more powerful and useful in many situations, I'd really love to be able to adopt it.
,
Dec 20 2017
I'm going to reopen this as we'll need to reach one of the following conclusions: 1. the bug is fixed 1. the bug is not fixed and the protocol method is documented as broken Without either of these, developers are bound to sink many hours into debugging this frustrating scenario; something I, and others here, have already done. ------------ Additionally, this bug is now blocking a new Lighthouse audit contributed by Chrome Security: https://github.com/GoogleChrome/lighthouse/pull/3953/
,
Dec 20 2017
A few more notes on the details of this flaky behavior: In comment 4 I detailed a repro where the presence of --headless made interception work. However phulce@ and the original filer have seen interception fail with a brand new chrome profile, but succeed with a real users's default profile. It's currently unclear what the difference is in the two profile states. (And if DevTools overrides works on a completely fresh profile)
,
Jan 17 2018
Wanted to comment here before I opened another ticket, since this seems to be related. I'm using requestInterception within puppeteer and would like this feature to block certain redirects. Ticket here: https://github.com/GoogleChrome/puppeteer/issues/823 The last few comments talk about a possible solution being browser-wide requestInterception. Thanks!
,
Dec 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4c806b8b802c5bcd93831229bedd8164d8a68a26 commit 4c806b8b802c5bcd93831229bedd8164d8a68a26 Author: Andrey Kosyakov <caseq@chromium.org> Date: Fri Dec 28 20:17:50 2018 DevTools: enable only one DevToolsURLRequestInterceptor per BrowserContext Bug: 811385 , 764505 Change-Id: I924aa64f71b2012f21ce0dc7e309cf354bbeb6e4 Reviewed-on: https://chromium-review.googlesource.com/c/1391678 Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#619186} [modify] https://crrev.com/4c806b8b802c5bcd93831229bedd8164d8a68a26/content/browser/devtools/devtools_url_request_interceptor.cc [modify] https://crrev.com/4c806b8b802c5bcd93831229bedd8164d8a68a26/content/browser/devtools/devtools_url_request_interceptor.h [modify] https://crrev.com/4c806b8b802c5bcd93831229bedd8164d8a68a26/content/browser/storage_partition_impl_map.cc
,
Dec 28
,
Dec 29
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ligim...@chromium.org
, Sep 12 2017