New issue
Advanced search Search tips
Starred by 9 users

Issue metadata

Status: Fixed
Closed: Mar 2018

Sign in to add a comment

Issue 2303: chromedriver sendKeys iframeWithExtensionSource

Reported by, Mar 8 2018

Issue description

Issue Description: was fixed and we can switch to extension sources again, however when I try to sendKeys to an input field the field remains empty, the focus actually moves to the field but it remains empty.

Steps to reproduce:
An example automation test can be found at

npm i
node test/main.js
47.7 KB View Download

Comment 1 by, Mar 8 2018

This is affecting our automation as well. Hoping for a fast resolution to this one after waiting so long for the last fix.

Comment 2 by, Mar 8 2018

Labels: Needs-Feedback
Have you tried with the latest versions of Chromedriver and Chrome?

On which OS platform you are running. Which version of Chromedriver and Chrome you were running?

Please share your repro code and attach the Chromedriver verbose log file to this bug.

Comment 3 by, Mar 8 2018

I'll try to run the github code you pointed out to see if I get a repro.

Comment 4 by, Mar 8 2018

I did not originally report the bug, but I am experiencing the issue using exactly as described. I am using Chrome: 65.0.3325.146  and  ChromeDriver: 2.36

We have a chrome extension and we're trying to type text into a textbox. sendKeys moves the focus to the field, but never actually inputs the text.

Comment 5 by, Mar 8 2018

jaybos.. do you also running node Javascript test? Whatever you are running please share with us so we could run it on our side.

Comment 6 by, Mar 9 2018

unfortunately, I cannot share our code. Company policy. Sorry.

We are running java and groovy. It is a simple test, however, just try to type text into any text field in a chrome extension. The text field is in am iframe on the extension.

Comment 7 by, Mar 12 2018

I'm facing the same issue.

Comment 8 by, Mar 12 2018

I tested this with chromedriver version 2.36.0 and Google Chrome Version 65.0.3325.124 (Official Build) beta (64-bit) on Mac and with Google Chrome Version 65.0.3325.146 (Official Build) (64-bit) on Windows

I attached the driver logs

As already mentioned you can run the example from
88.0 KB View Download

Comment 9 by, Mar 12 2018

markus... , I run your pointed code and test run as expected.

Here is the console log:
$ node test/main.js
start server
server started
found element normalSrc
switch done: normalSrc
found element extensionSrc
switch done: extensionSrc
found element normalSrcAddedByExtension
switch done: normalSrcAddedByExtension
found element extensionSrcAddedByExtension
switch done: extensionSrcAddedByExtension

Screen shot as well is attached.

Please let me know what should I modify in this code to get a repro of this issue.
31.6 KB View Download

Comment 10 by, Mar 12 2018

You have to run the branch sent-keys-extension-frame. Sorry, maybe I should have mentioned it more explicitly.

Comment 11 by, Mar 12 2018

Yes, I cloned that branch (screenshot is attached ).

I cloned the project from then run 'node test/main.js.'
82.7 KB View Download

Comment 12 by, Mar 13 2018

Still looks like you executed the "master" branch. Did you run "git checkout send-keys-extension-frame" after cloning the repository?

Comment 13 by, Mar 13 2018

If it doesn't look like the first screenshot I attached then it's not running the right branch.

Comment 14 by, Mar 13 2018

Basically the frame was not focused on the extension iframe but it was in normal frame ( attached screenshot). 

I just changed the prototype of typeSomething() to function typeSomething(msg) and the following was in startServer():
  .then(() => driver.get('http://localhost:8080/index.html'))
  .then(() => switchToFrame('normalSrc'))
  .then(typeSomething('In normal frame'))
  .then(() => switchToFrame('extensionSrc'))
  .then(typeSomething('In extension frame'));
23.9 KB View Download

Comment 15 by, Mar 14 2018

There are two of issues with your modifications:
- the switch to frame function will return to the default context before resolving
- you are invoking typeSomething immediately instead of passing it as a callback to then, so the order of when it is typing is screwed up

I pushed a small modification to the branch with what you intended to do and attached screenshots.
44.4 KB View Download

Comment 16 by, Mar 14 2018

31.0 KB View Download

Comment 17 by, Mar 14 2018

Thank you for your updates.

I was able to reproduce the issue.
Chromedriver log file is attached.

From chromedriver logs I see FindEelement and TypeElement IDs are different:

[INFO] Done waiting for pending navigations. Status: ok
[INFO] RESPONSE FindElement {
   "ELEMENT": "0.3912639588521365-2"
[INFO] COMMAND TypeElement {
   "id": "0.3912639588521365-1",
   "text": "I was here: In extension frame",
   "value": [ "I", " ", "w", "a", "s", " ", "h", "e", "r", "e", ":", " ", "I", "n", " ", "e", "x", "t", "e", "..." ]

Here are the console logs:

start server
server started
typing I was here: In normal frame
typing I was here: top
typing I was here: In extension frame
found element normalSrc
switch done: normalSrc
typing I was here: normalSrc
found element extensionSrc
switch done: extensionSrc
typing I was here: extensionSrc
154 KB View Download

Comment 18 by, Mar 14 2018

Status: Untriaged (was: Unconfirmed)

Comment 19 by, Mar 14 2018

Screen shot is attached
24.4 KB View Download

Comment 20 by, Mar 20 2018

Your reproduction still seems wrong, did you try with the updated branch?

Comment 21 by, Mar 30 2018

Any update on this?

Comment 22 by, Mar 30 2018

The issue is escalated to the next level for investigation.

Comment 23 by, Mar 30 2018

Project Member
Labels: -Needs-Feedback Pri-1
Status: Assigned (was: Untriaged)
I'm taking a look.

Comment 24 by, Mar 30 2018

Project Member
Dmitry: There is an issue with dispatching synthetic keyboard events to OOPIF, similar to the mouse event bug you fixed with When a text input in an OPPIF has focus, Input.dispatchKeyEvent command doesn't get routed to the OPPIF, and the synthetic events are lost. Do you think these events should be routed in the same way as the mouse events? Alternatively, I can use Target.sendMessageToTarget to explicitly send the events to the OOPIF.

Comment 25 by, Mar 30 2018

I believe I made keyboard events go to focused frame, even with OOPIFs. Could you please try to call "iframe.focus()" on the frame before dispatching a keyboard event there? This should mirror how the real users interact with the page.

Comment 26 by, Mar 30 2018

Project Member
Status: Fixed (was: Assigned)
Confirmed that keyboard events are dispatched to focused frame in Chrome 66 and above. This issue has been fixed by

Chrome 66 is already available in beta channel, and is expected to be released in stable channel in about half a month.

Comment 27 by, Apr 2 2018

Thanks for the info! I've downloaded the beta version of chrome 66 and confirmed that the issue I've been seeing is solved! Hopefully it is resolved for all on this thread!

Comment 28 by, Apr 3 2018

I can confirm that is fixed on Chrome Version 66.0.3359.66 (Official Build) beta (64-bit) on Mac

Sign in to add a comment