Yea, I’ll probably have to go with your earlier suggestion of logging into google account at the beginning of the test.
This isn’t a bad idea anyway. There’s a best practice in test automation that goes something like: Only automate stuff that is within scope of your AUT.
In other words, when your AUT involves third-party apps (which is the case here), you are not necessarily responsible for automating that third-party piece.
If it’s the ONLY input[type=email] element, yes, it’s fine.
Looking at your last screenshot of devtools showing the popup, try putting this in the devtools console:
document.querySelector("#identifierId").value = "farooqi"
Now, follow this carefully…
Make the webpage itself the target of devtools – in other words, click on the main page (but do NOT close the popup). Now relaunch devtools (F12) and put this in the console:
document.querySelector("#identifierId").value = "brandon"
What we’re trying to do here is figure out if the element is truly blocked by virtue of the fact it is inside a sub-document (~iframe).
Thank you @Russ_Thomas and @Brandon_Hein for all the help. I just tried to login to gmail manually when chrome is being controlled by an automated test software, and I was unable to log in there. So even if I am able to input the email address I won’t be able to continue.
I, also, found out that google itself doesn’t allow signing in using automated software.
https://support.google.com/accounts/answer/7675428?co=GENIE.Platform%3DAndroid&hl=en
I really appreciate you guys looking into this with me.
1 Like