New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 702107 link

Starred by 7 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Headless: Rendering hangs for several sites

Reported by xivans1...@gmail.com, Mar 16 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/56.0.2924.76 Chrome/56.0.2924.76 Safari/537.36

Steps to reproduce the problem:
1. Run Chromium in headless mode (~/chrome-linux/chrome --headless --disable-gpu --no-sandbox --remote-debugging-port=9222)
2. Navigate to http://localhost:9222 in non-headless browser and click to 'about:blank' link (observe - "chrome-devtools-frontend.appspot.com" opened)
3. In opened app enter http://goga.pro and press 'refresh' button near textbox

What is the expected behavior?
Site from step 3 should be rendered in "chrome-devtools-frontend.appspot.com" after some time.

What went wrong?
Nothing happens. 
After some time "Tab is inactive" message appears.

Also please note that everything works fine in same Chromium binary without headless flag.

When i'm trying to navigate to same site with Chrome Debugging Protocol (e.g. websocket based API) i can observe that no events are triggered after first 'Network.requestWillBeSent'.

Here is websocket session dump:
>| {"method":"Page.enable","id":1}
<| {"id":1,"result":{}}
>| {"method":"Network.enable","id":2}
<| {"id":2,"result":{}}
>| {"method":"Console.enable","id":3}
<| {"id":3,"result":{}}
>| {"params":{"userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"},"method":"Network.setUserAgentOverride","id":4}
<| {"id":4,"result":{}}
>| {"params":{"headers":{"Accept-Language":"ru-RU"}},"method":"Network.setExtraHTTPHeaders","id":5}
<| {"id":5,"result":{}}
>| {"params":{"url":"https://goga.pro/"},"method":"Page.navigate","id":6}
<| {"method":"Page.frameStartedLoading","params":{"frameId":"9076.1"}}
<| {"method":"Network.requestWillBeSent","params":{"requestId":"9076.1","frameId":"9076.1","loaderId":"9076.1","documentURL":"https://goga.pro/","request":{"url":"https://goga.pro/","method":"GET","headers":{"Accept-Language":"ru-RU","Upgrade-Insecure-Requests":"1","User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"},"mixedContentType":"none","initialPriority":"VeryHigh","referrerPolicy":"no-referrer-when-downgrade"},"timestamp":1465848.184602,"wallTime":1489651688.04825,"initiator":{"type":"other"},"type":"Document"}}
<| {"id":6,"result":{"frameId":"9076.1"}}

... the end, no further messages...

Did this work before? N/A 

Chrome version: 59.0.3044.0  Channel: n/a
OS Version: 4.4.0-64-generic
Flash Version:
 
Labels: Proj-Headless
Can someone from the Headless team triage this?
Labels: Needs-Triage-M59
Components: -Platform>DevTools
Summary: Headless: Rendering hangs for several sites (was: Proj-Headless: Rendering hangs for several sites)
I have figured out what's going on, it was related some kind of invalid SSL cert error (it became obvious after i have turned on Security domain notifications).

Still don't know why same binary opens this site without any SSL errors in regular (non-headless) mode.

Someone, please close this. 
Cc: msrchandra@chromium.org
Labels: Needs-Feedback
Could some from Headless team please update the issue according to Comment# 4.
Thanks in Advance.
I confirm a similar problem with the urls:
- https://www.lemonde.fr/
- http://www.lemonde.fr/

The https version contain some mixed http content and therefore raises SSL errors, which is normal, but that somehow prevent the page from loading in headless mode. The http page works fine in headless mode.
Owner: sushkov@chromium.org
Status: Assigned (was: Unconfirmed)
I'll have a look. I can repro it so seems like a real issue worth fixing.
This problem is caused by the Headless Browser Client not handling SSL certificate errors correctly (currently we do nothing). I have made a simple first-pass fix in CL: https://codereview.chromium.org/2853763004
Project Member

Comment 9 by bugdroid1@chromium.org, May 9 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd9f2947de07f272f69edea9da56309d5790701d

commit fd9f2947de07f272f69edea9da56309d5790701d
Author: sushkov <sushkov@chromium.org>
Date: Tue May 09 04:34:36 2017

added the allowcertificateerror method to the headless browser client so that it can handle certificate errors in headless mode, instead of just stalling

BUG=702107

Review-Url: https://codereview.chromium.org/2853763004
Cr-Commit-Position: refs/heads/master@{#470209}

[modify] https://crrev.com/fd9f2947de07f272f69edea9da56309d5790701d/headless/lib/browser/headless_content_browser_client.cc
[modify] https://crrev.com/fd9f2947de07f272f69edea9da56309d5790701d/headless/lib/browser/headless_content_browser_client.h
[modify] https://crrev.com/fd9f2947de07f272f69edea9da56309d5790701d/headless/lib/headless_web_contents_browsertest.cc

Just to make sure, https://codereview.chromium.org/2853763004 reject certificate errors, right? (I see CERTIFICATE_REQUEST_RESULT_TYPE_DENY.)
Correct, the decision is that by default we deny on error. If you want a different behaviour (such as ignoring an SSL error and continuing), recently we added a DevTools protocol for handling certificate errors (https://codereview.chromium.org/2639203003/). With this you would be able to override the default deny behaviour.
Components: Internals>Headless

Sign in to add a comment