Issue metadata
Sign in to add a comment
|
Chrome crashes when use send_keys from chromedriver with enabled DCHECKs
Reported by
matthew...@yandex-team.ru,
Apr 15 2016
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/601.4.4 (KHTML, like Gecko) Version/9.0.3 Safari/601.4.4
Steps to reproduce the problem:
1. Build debug version of chrome and launch it with selenium webdriver
2. Open chrome://settings in it
3. Try to enter value to search bar:
def try_to_search(browser):
input_element = browser.find_element_by_xpath('//input[@id="search-field"]')
input_element.send_keys('12345')
What is the expected behavior?
What went wrong?
DCHECK fires within the following back trace:
* thread #1: tid = 0x1261218, 0x0000000119816236 libbase.dylib`base::debug::BreakDebugger() + 38 at debugger_posix.cc:249, name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
* frame #0: 0x0000000119816236 libbase.dylib`base::debug::BreakDebugger() + 38 at debugger_posix.cc:249
frame #1: 0x00000001198a4ffc libbase.dylib`logging::LogMessage::~LogMessage(this=0x00007fff55af02a0) + 3388 at logging.cc:735
frame #2: 0x00000001198a1c43 libbase.dylib`logging::LogMessage::~LogMessage(this=0x00007fff55af02a0) + 35 at logging.cc:515
frame #3: 0x000000010d92b059 libchrome_main_dll.dylib`+[BrowserWindowUtils shouldHandleKeyboardEvent:](self=0x0000000112e26a88, _cmd="shouldHandleKeyboardEvent:", event=0x00007fff55af10a0) + 329 at browser_window_utils.mm:39
frame #4: 0x000000010d8ff764 libchrome_main_dll.dylib`BrowserWindowCocoa::PreHandleKeyboardEvent(this=0x00007ff6b1e794f0, event=0x00007fff55af10a0, is_keyboard_shortcut=0x00007fff55af07af) + 132 at browser_window_cocoa.mm:703
frame #5: 0x000000010dd2b67a libchrome_main_dll.dylib`Browser::PreHandleKeyboardEvent(this=0x00007ff6b1cb3f30, source=0x00007ff6b387c600, event=0x00007fff55af10a0, is_keyboard_shortcut=0x00007fff55af07af) + 154 at browser.cc:1248
frame #6: 0x000000010dd2b6f2 libchrome_main_dll.dylib`non-virtual thunk to Browser::PreHandleKeyboardEvent(this=0x00007ff6b1cb3f30, source=0x00007ff6b387c600, event=0x00007fff55af10a0, is_keyboard_shortcut=0x00007fff55af07af) + 66 at browser.cc:1239
frame #7: 0x000000011ee3aa40 libcontent.dylib`content::WebContentsImpl::PreHandleKeyboardEvent(this=0x00007ff6b387c600, event=0x00007fff55af10a0, is_keyboard_shortcut=0x00007fff55af07af) + 128 at web_contents_impl.cc:1663
frame #8: 0x000000011ee3aaac libcontent.dylib`non-virtual thunk to content::WebContentsImpl::PreHandleKeyboardEvent(this=0x00007ff6b387c600, event=0x00007fff55af10a0, is_keyboard_shortcut=0x00007fff55af07af) + 60 at web_contents_impl.cc:1659
frame #9: 0x000000011e9f1962 libcontent.dylib`content::RenderWidgetHostImpl::ForwardKeyboardEvent(this=0x00007ff6b3645e60, key_event=0x00007fff55af10a0) + 786 at render_widget_host_impl.cc:1154
frame #10: 0x000000011dedfc4d libcontent.dylib`content::devtools::input::InputHandler::DispatchKeyEvent(this=0x00007ff6b379fcf0, type="rawKeyDown", modifiers=0x00007fff55af217c, timestamp=0x0000000000000000, text="", unmodified_text="", key_identifier="", code="", key="", windows_virtual_key_code=0x00007fff55af204c, native_virtual_key_code=0x00007fff55af202c, auto_repeat=0x0000000000000000, is_keypad=0x0000000000000000, is_system_key=0x0000000000000000) + 4445 at input_handler.cc:226
frame #11: 0x000000011da378c4 libcontent.dylib`content::DevToolsProtocolDispatcher::OnInputDispatchKeyEvent(this=0x00007ff6b379fe80, command_id=(call_id = 49, session_id = 1), params=unique_ptr<base::DictionaryValue, std::__1::default_delete<base::DictionaryValue> > @ 0x00007fff55af23f8) + 8196 at devtools_protocol_dispatcher.cc:1159
Did this work before? N/A
Chrome version: 52.0.2708.0 Channel: n/a
OS Version: OS X 10.11.3
Flash Version: Shockwave Flash 20.0 r0
,
Apr 19 2016
I believe it's not a recent regression. And unfortunately I can't perform a bisect due to DCHECK, that don't hit in builds available for bisect. I believe chromium's debug build shouldn't hit DCHECKs while work with selenium. So either selenium's(or any other generated event) should be handled using separate path, or common code path should be aware of missing OS event. The third option is to generate OS event while generating keyboard events. Also DCHECK is in mac only code, so I think it's mac only bug that wouldn't repro on other platforms and therefore should be fixed.
,
Apr 19 2016
The point of Selenium is to drive Chrome as if a real user is taking actions. If this DCHECK is not being hit by real users on debug builds, then it sounds like Selenium is not correctly sending events to Chrome on OS X.
,
Apr 20 2016
Selenium sends events to chrome using devtools protocol[1], and that's where the bug is, I think. 1. https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/devtools/protocol/input_handler.cc&q=input_handler.cc&sq=package:chromium&type=cs&l=154
,
Apr 20 2016
Thank you for providing more feedback. Adding requester "erikchen@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 20 2016
Ah, I see. If you want to send a patch removing the DCHECK, I will lgtm it. +rsesek, as an owner of chrome/browser/ui/cocoa/.
,
Apr 22 2016
,
Jun 1 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 13 2016
This issue has been moved once and is lower than Pri-1. Removing the milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 15 2016
I believe it was fixed in 627221 Could someone close it as duplicate?
,
Jul 19 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by erikc...@chromium.org
, Apr 18 2016