Headless: Rendering hangs for several sites
Reported by
xivans1...@gmail.com,
Mar 16 2017
|
||||||
Issue descriptionUserAgent: 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:
,
Mar 21 2017
,
Mar 23 2017
,
Mar 29 2017
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.
,
Mar 30 2017
Could some from Headless team please update the issue according to Comment# 4. Thanks in Advance.
,
Apr 19 2017
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.
,
May 1 2017
I'll have a look. I can repro it so seems like a real issue worth fixing.
,
May 2 2017
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
,
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
,
May 9 2017
Just to make sure, https://codereview.chromium.org/2853763004 reject certificate errors, right? (I see CERTIFICATE_REQUEST_RESULT_TYPE_DENY.)
,
May 9 2017
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.
,
May 15 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by chenwilliam@chromium.org
, Mar 17 2017