Issue metadata
Sign in to add a comment
|
chrome.runtime.sendMessage in a chrome webdriver hangs and causes chrome 70 to crash
Reported by
nicholas...@readytalk.com,
Sep 28
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.35 Safari/537.36 Steps to reproduce the problem: Does this seem like the right steps? I’m going to attach that simple test I copied to you, the sauce_browsers with just sl_chrome & sl_chrome_beta, and the webdrive_l.js 1. Set up Karma to run the test and set singleRun to false to keep them tests running. We have them running at localhost:9876. The single test should pass on chrome 69 but will often timeout on chrome 70. 2. Install the chrome 70 webdriver: http://chromedriver.chromium.org/ 3. In another terminal, run `node webdriver_l.js`. If set up right, this should open chrome 70 environment with the screen sharing extension injected. 4. connect to the tests server that should still be running locally. https://localhost:9876 5. The injected extensionId should be the same. Call `chrome.runtime.sendMessage('jnnakpdljmpbeegkackpadhhajomhdom', {getStream: true }, (r) => {console.log(r) } );` in the consul. Usually, 1/5 of the calls will cause the browser to stop responding and crash. What is the expected behavior? The expected behavior is for `chrome.runtime.sendMessage` to respond with a message rather then never responding and causing the browser to crash. What went wrong? we are running into an issue with just windows machines when calling chrome.runtime.sendMessage() in a chrome webrdriver when doing a binary injection of a screen share permission extension. Calling sendMessages fails to respond and the chrome 70 crashes Did this work before? Yes 69 Does this work in other browsers? N/A Chrome version: 70.0.3538.35 Channel: beta OS Version: Windows 10 Flash Version: Sometimes, the call will be fine and respond. It seems to fail about 1/4 of the time.
,
Oct 1
nicholas.pampe@ Thanks for the issue... As per comment #0, It seems to be related to chrome webdriver. Hence adding 'TE-NeedsTriageHelp' label and requesting the appropriate team to look into the issue and help in further triaging. Thanks..!
,
Oct 1
Sounds good. Let me know if an additional information is needed.
,
Oct 3
Can you provide crash IDs (available in chrome://crashes)
,
Oct 3
,
Oct 3
,
Oct 4
I'll work on getting the crash ID's. I'm finding launching the webdriver and getting the report a bit more tricky then I first though but should be a simple flag to pass in.
,
Oct 4
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 17
apologies for the late response. I have tried to capture the crash IDs but have run into issues. I've followed steps on how/where the crash reports are written. https://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug In addition, I made sure to add the arg `--enable-crash-reporter` for crash reporting. When checking in chrome://crashes the response is always that disabled. I did find that the file locations where different and set to: `%LOCALAPPDATA%\Temp\<LaucherId>\UserData` rather than `%LOCALAPPDATA%\Google\Chrome\User Data`. Each time we launch through selenium, the LauncherId is generated and the new dir path is created. My understanding is the chrome://crashes checks the files under `%LOCALAPPDATA%\Google\`. Since the set up is pointing to the Temp dir, getting the crashId from the browser doesn't work. The good news is the Local State file exists in these directories. Thus, I'm fairly certain the crashId's should be reported to these temp directories and should be accurate. Where I'm stuck though is the behavior during the crash. When calling chrome.runtime.sendMessage() I see the browser fail to respond and never generate the crash report. The window hangs forever without responding or ever writing to any files. The only way to close the browser is to force close and, from what we can tell, still doesn't write the crash report. I am including the Local State after running through the steps to cause the crash in hopes that it provides information, but again, I'm not convinced we captured the right info. Cheers! |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by phanindra.mandapaka@chromium.org
, Sep 30