I want to debug a local dev environment issue potentially caused by CORB in Chrome 74. I want to see if - when I swith off CORB - the issue goes away.
The according Google developer docs say that
You can confirm if a problem is due to CORB by temporarily disabling it, by starting Chrome with the following command line flag:
--disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating
However, if I run
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating --user-data-dir="C:/ChromeDevSession"
Chrome still shows CORB warnings and blocks according requests.
If you take a look at mentioned in the docs feature tracking page you will find link to tracking bug. The last commit in that bug actually refers to revision where this feature is enabled by default and is no more controlled from outside through command line (at least using mentioned in the question flags).
But there is interesting piece of code added :
// --disable-web-security also disables Cross-Origin Read Blocking (CORB).
if (base::CommandLine::ForCurrentProcess()->HasSwitch(
switches::kDisableWebSecurity)) {
params->is_corb_enabled = false;
return;
}
Hopefully in 74 version it still exist. So if you OK with all consequences just add
--disable-web-security instead.
By the way in latest sources you will not find it anymore. So with never version of chromium you will not be able to disable it.
Related
The Problem
A few Chrome releases ago, Chrome deprecated a feature allowing for synchronous XHR during page dismissal. After several business complained of unforeseen impacts to business, they decided to default the behavior in Chrome 80 and allow for temporary workaround up until Chrome 82.
It seems that after upgrading to Chrome/ChromeDriver 78, we are seeing behavior in our application that is consistent with sync XHR on unload event being blocked. This behavior is only when ChromeDriver opens Chrome, I cannot reproduce when opening Chrome manually. This occurs even when no ChromeOptions are specified when opening Driver. While in ChromeDriver generated Chrome window, I navigate to chrome:\\flags and search for the #allow-sync-xhr-in-page-dismissal flag, I see it's set to 'default'. Upon setting to 'Enabled', our issue goes away. However, when I check this flag in my manually launched Chrome window, it's also set to 'default'.
My Question
Why does it seem behavior is different when launching via ChromeDriver vs. a manually opened Chrome session?
What is the correct way to force ChromeDriver to set the #allow-sync-xhr-in-page-dismissal to enabled via ChromeOptions?
To answer question 2:
chromeOptions.AddArgument("--enable-features=AllowSyncXHRInPageDismissal");
I'm trying to test some features in a production environment, and to achieve this I'm using Google Chrome overrides, that basically allows you to substitute a remote file with a local file.
It sometimes works, but after a couple of reloads it stops working and all the requests start failing, receiving this error in console:
Pay attention: I'm not talking of the full page warning that you see when you access an untrusted website, which has the same error code. I'm talking about the error in console which makes the website unusable.
I say this because I tried googling the error and I only see articles about the warning, that you can easily skip. This is a different subject.
What I tried so far, without success is:
Start chrome with the --ignore-certificate-errors flag
Enabling the allow-insecure-localhost flag in chrome://flags
But they didn't help. How can I tell Chrome to ignore the (inexistent) certificate?
Thank you
Edit
I add an image of my override configuration:
to-override is my local folder. Then I just clicked on a file in the source tab and selected save for override. I found the file in my local folder and I changed it. Changes are applied the first time, but on refresh everything stops working and all the requests fail.
My Chrome version is
71.0.3578.98 - stable - 64 bit
I want to use Chrome browser in headless mode to produce images (PNG, JPEG) out of SVG graphic. Code works in normal interactive mode, but I have problems to use it in headless mode.
My main problem is that headless Chrome exits before drawing of HTML page is completed. As I understand, if I start Chrome with following arguments:
chromium --headless http://myserver.org
It exits together with document.onload event. But at this moment not all data fetched from the server (I using XMLHttpRequest) and therefore drawing is not complete.
I found workaround if I start chrome with debugging port enabled like:
chromium --headless --remote-debugging-port=7777 http://myserver.org
But this is not that I want, especially when I do not have privileges to open http ports on the node. Is there possibility to let Chrome running longer with other flags? I check a lot of them, but did not found appropriate one. Or is there any other methods to postpone exit of the headless Chrome?
You could try this answer https://stackoverflow.com/a/46424041/4830701
Copy pasted here for reference
Use the binary /opt/google/chrome/chrome directly not google-chrome which points to bash script /usr/bin/google-chrome.
Taken from comments in
https://developers.google.com/web/updates/2017/04/headless-chrome#screenshots
I'm trying to decrypt SSL packages with Wireshark as described here. I have already created a SSLKEYLOGFILE System and User variable and the log file. I have restarted my computer (running Windows 10), and opened https urls with Chrome and Firefox, but none write to the ssl log file. My Chrome version is 56.0.2924.87 (64-bit) and my Firefox version is 51.0.1 (32-bit). Any idea how can I make any of the two browsers write to that file? Or is there any way to get the SSL key to be able to decrypt SSL packages in Wireshark?
You are doing something wrong. Tested on version 58 & you do not need to reboot. To activate either:
set environment variable e.g. SSLKEYLOGFILE to %USERPROFILE%\sslkeysENV.pms
run chrome with argument e.g.:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ssl-key-log-file=%USERPROFILE%\sslkeysARG.pms
With Firefox the features seems to be disabled by default and is only available in debug builds. With Chrome this might have been vanished by switching the underlying SSL engine from NSS (which implemented this feature and is also used in Firefox) to BoringSSL (which maybe does not have this feature).
Update: according to #Lekensteyn (see comment) the feature is again available in current Firefox and Chrome builds.
I have solved it!
You MUST be sure chrome totally be closed. And then reopen a fresh new chrome instance.
Chrome has a default options let chrome run in background enabled.
Double check your taskbar of windows or processes lists to make sure there's no chrome instance exists.
That's why --ssl-key-log-file don't working, chrome stills alive after you click exit button.
Try Firefox Developer edition, the above mentioned feature is turned on by default. I tested yesterday only.
Some antiviruses (like Avast) inject the SSLKEYLOGFILE environment variable into well-known processes like firefox.exe and chrome.exe. If you rename the browser executable file and launch that, then the environment variable won't be overridden.
Try to close your current browsing session, it behave like you just add a new path to PATH, only work from the new session and so on.
Besides what they have already pointed out, I want to show three points that may help. These are tips for Linux (CentOS)
Make sure the file that related to SSLKEYLOGFILE can be written and read, to make sure you can use:
chmod -R 777 sslkey.txt
Make sure your Firefox or Chrome is opened under the same user with the file mentioned, for example under root.
Find some useful comments here
I know how to enable chrome's crash reporting interactively:
Menu > Settings > Show advanced settings > Tick "Automatically send usage statistics and crash reports to Google"
However, I'm using chrome in an automated testing setup where we set a new --user-data-dir for each run (so there are no persisted settings, we just get the defaults). Chrome is crashing occasionally (running our javascript/html application) and I would like to be able to report these crashes.
I thought I could add --enable-crash-reporter (according to the List of Chromium Command Line Switches), but that doesn't seem to do anything. (We already pass --enable-logging and a couple other flags on the command line.)
I have a test that triggered an "Aw, Snap":
But if I download the user-data-dir for that run and and point chrome at it, and then visit chrome://crashes, it says crash dumps are not enabled.
(The chrome_debug.log does not say anything about the Aw-Snap either.)
We're running chrome under Xvfb on Debian. We're driving chrome via the direct webdriver (from Protractor).
According to the "crashpad with content shell" docs, the steps for using crashpad with content shell (a stripped down version of Chrome):
Create some directory for your crash dumps to go to (the docs suggest tmp/crashes on Linux and Mac, %TEMP%\crashes on Windows, and /data/local/tmp/crashes on Android)
Start Chrome with --enable-crash-reporter --crash-dumps-dir=<your_dump_dir> (looks like you got half of this)
So I'd try adding the --crash-dumps-dir flag.