New issue
Advanced search Search tips
Starred by 9 users

Issue metadata

Status: Fixed
Owner:
Closed: Mar 30
Cc:



Sign in to add a comment

chromedriver sendKeys iframeWithExtensionSource

Reported by markus.h...@gmail.com, Mar 8

Issue description

Issue Description:
https://bugs.chromium.org/p/chromedriver/issues/detail?id=1819#c29 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 
https://github.com/markus-hartung-avira/selenium-iframe-bug/tree/send-keys-extension-frame

npm i
node test/main.js

 
screenshot-1.png
47.7 KB View Download
This is affecting our automation as well. Hoping for a fast resolution to this one after waiting so long for the last fix.
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.


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

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.  
jaybos.. do you also running node Javascript test? Whatever you are running please share with us so we could run it on our side.

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.  
I'm facing the same issue.
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 https://github.com/markus-hartung-avira/selenium-iframe-bug/tree/send-keys-extension-frame
driver.log
88.0 KB View Download
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
shutdown

Screen shot as well is attached.

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


Issue_2303.png
31.6 KB View Download
You have to run the branch sent-keys-extension-frame. Sorry, maybe I should have mentioned it more explicitly.
Yes, I cloned that branch (screenshot is attached ).

I cloned the project from https://github.com/markus-hartung-avira/selenium-iframe-bug.git then run 'node test/main.js.'





github_for_issue2303.png
82.7 KB View Download
Still looks like you executed the "master" branch. Did you run "git checkout send-keys-extension-frame" after cloning the repository?
If it doesn't look like the first screenshot I attached then it's not running the right branch.
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'));
...

Issue2303_2.png
23.9 KB View Download
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.





screenshot-3.png
44.4 KB View Download
screenshot-2.png
31.0 KB View Download
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

driver.log
154 KB View Download
Status: Untriaged (was: Unconfirmed)
Screen shot is attached
Issue2303.png
24.4 KB View Download
Your reproduction still seems wrong, did you try with the updated branch?
Any update on this?
Cc: johnchen@chromium.org
The issue is escalated to the next level for investigation.

Project Member

Comment 23 by johnchen@chromium.org, Mar 30

Cc: -johnchen@chromium.org
Labels: -Needs-Feedback Pri-1
Owner: johnchen@chromium.org
Status: Assigned (was: Untriaged)
I'm taking a look.
Project Member

Comment 24 by johnchen@chromium.org, Mar 30

Cc: johnchen@chromium.org
Owner: dgozman@chromium.org
Dmitry: There is an issue with dispatching synthetic keyboard events to OOPIF, similar to the mouse event bug you fixed with https://chromium-review.googlesource.com/947470. 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.
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.
Project Member

Comment 26 by johnchen@chromium.org, Mar 30

Owner: johnchen@chromium.org
Status: Fixed (was: Assigned)
Confirmed that keyboard events are dispatched to focused frame in Chrome 66 and above. This issue has been fixed by https://crrev.com/540419.

Chrome 66 is already available in beta channel, and is expected to be released in stable channel in about half a month.
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!
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