Issue metadata
Sign in to add a comment
|
domAutomationController event being killed by ServiceManager |
||||||||||||||||||||||||
Issue description
Chrome Version : 57.0.2987.98 (64-bit)
URLs (if applicable) : chrome://chrome-signin/?access_point=0&reason=0
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: n/a
Firefox: n/a
IE: n/a
What steps will reproduce the problem?
(1) Automated login via
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/signin/login_ui_test_utils.cc?l=174
(2) Email field is filled in.
(3) Password is filled in and sign in is clicked.
What is the expected result?
The user is signed in.
What happens instead?
The test hangs with the log:
[73914:775:0324/150629.083324:WARNING:CONSOLE(237)] "<webview>: The load has aborted with error -20: ERR_BLOCKED_BY_CLIENT.", source: extensions::webViewEvents (237)
Please provide any additional information below. Attach a screenshot if
possible.
,
Mar 24 2017
,
Mar 24 2017
Hey Mojo folks! We saw a regression in our sync specific tests that are not part of the main try bots, can view our waterfall at https://uberchromegw.corp.google.com/i/internal.client.kitchensync/waterfall . We're trying to figure out what went wrong. Tests started failing on Mar 23rd with the following log error: [16935:16975:0323/201041.803973:ERROR:service_manager.cc(480)] InterfaceProviderSpec prevented connection from: content_utility to: content_browser This happens as we try to run some javascript, https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/signin/login_ui_test_utils.cc?dr=CSs&l=267 , to close the sign in confirmation dialog, and then signal back using the domAutomationController. But no message ever comes back, our tests hang/fail, and our suspicion is that this prevention the ServiceManager is doing is killing over event. The last successful Linux build started Mar 22nd 19:32:24 GMT, and the first failure started at Mar 23rd 19:32:24 GMT. Now, if this is the wrong component, my apologies, hopefully this is at least close. I've glanced over https://cs.chromium.org/chromium/src/services/service_manager/README.md but still lacking understanding of what's going on here. All help is appreciated!
,
Mar 27 2017
Added TE-NeedsTriageHelp as it looks out of scope from TE end.
,
Mar 27 2017
Hi, Ken. Are you aware of any utility-related changes around that time? Thanks!
,
Apr 3 2017
Friendly ping?
,
Apr 5 2017
,
Apr 5 2017
Sorry, just got to look at this now: 1 - the error log is an innocuous red herring (and known issue) caused by memory profiling client code running in utility process setup, trying to reach an interface which the browser does not expose to utility processes. this has nothing to do with domAutomationController or your tests. 2 - AFAICT the service manager does not kill or in any way control the lifetime of anything relevant to domAutomationController, so this bug description is probably inaccurate It would help to do a bisect and figure out what CL actually broke this. The timing does seem to line up with r458954, which could mean that some related interface connection has been broken or has somehow become racy. Not sure who should take a look next (I'm OOO) but giving to skym@ for further triage/investigation.
,
Apr 7 2017
Thanks for the reply rockot@, really appreciate it, sorry to bug you while OOO. I think my summary in #3 was actually quite inaccurate, after more digging it doesn't seem like we're actually reaching the domAutomationController at all. I should have updated this bug, but I created new issue 709117 instead with a more clear description of the current symptoms. Currently trying to run the bisect tool but I seem to be doing something wrong. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by wylieb@chromium.org
, Mar 24 2017Labels: -Type-Bug -Pri-3 OS-Linux OS-Mac OS-Windows Pri-2 Type-Bug-Regression