I’m having trouble editing a text field because it is inside an iframe. I already used the switch to frame function and it seems to switch to the frame but when I tried to edit the object inside, the test fails. I also tried to use the spy web to locate the right xpath to use but no help at all.
Here’s how my iFrame looks like (highlighted in blue):
Can you show us the console log when the test fails. In your script I see you’re clicking on the object inside the iframe. Does the test fail at that step ?
The error says that iframe is null. Can you open the console on Chrome (or your browser) and execute the document.querySelector(’…’) that retrieves the iframe object.
We need to creep forward step by step. A moving target is harder to hit so try not to change the code until we nail this problem down.
First, a statement from me: You are using TinyMCE (https://www.tiny.cloud/). It appears what you are trying to do is not something a user would ever need to do. But maybe I’ve misunderstood. Please make a statement as to what you’re trying to do from a user’s perspective. Please, don’t ignore this step!
Next…
Is your page being served from the same domain as the document residing in the iframe?
1.1 If it’s NOT, then you’re going to be out of luck.
The code you’re using was posted by me on another thread untested. Change the doc assignment in the JavaScript string to this:
After clicking on the ‘Insert Attribute’, have to scroll down to the part where the parameters ‘Hello’, Title(ID) etc have to be added. As per the Katalog logs, I am able to switch to the iFrame using the ‘switchToFrame’ and also able to scroll down to the element. However, this is where I get stuck and not able to append the text to the element.
Yes, The page in question is being served from the same domain as the document residing in the iframe
I have already changed that and it still throws an error
There is an API documented at TinyMCE | Command identifiers (search for mceInsertContent) which you can use from JavaScript to update the editor. You should use that to help position the cursor. If you don’t, you’ll need very specific and hence very fragile selectors to access the editor content.
If you prefer to ignore that and continue on your current path, take my example and modify it to use your paths and selectors. Do it ALL from JavaScript. Test Objects are NOT your friends here.
@ThanhTo appreciete for summoning me, altough is not exactly my area of expertise. @saumil.sah i hate screenshots, even if the legend say ‘a pic may speak more than a thousand words’. kindly try to post code as … formated code.
my guess here is … mhm. you are using a string, triple quotes, when you define the js query. however inside the selector there are some nice characters, like hasthag. groovy may be triky here.i have a feeling such characters may have to be escaped. but without a reproducible code i cannot dig more,so i let this to @Russ_Thomas. he is the master of js voodoo
True if he was using """ stuff """ ← that’s a GString (groovy-string). But he’s using ''' stuff ''' containing single quotes, a plain old string so there should be no issue with #, $, whatever.
I will try to summarize the directions provided by the answers here.
First, @hpulsford’s mentioned StackOverflow is interesting. Since you already successfully retrieved the iframe in the console by your code, the StackOverflow points to the possibility that the iframe is not available (t to be interacted) yet at the time Katalon executes that step. This suggests that you should add a long delay, instead of 3 maybe 10 seconds to ensure that everything is already static, and then try to execute the javascript.
Another direction involves your original script:
This throws ElementNotInteractableException: Element is not reachable by keyboard. This just popped in my head, but if you were able to scroll to it, then maybe you can add a Click on it. My guess is the Click can focus on that object and after that the setText should work.
What we need here is a methodical, step-by-step approach.
Sorry, but I disagree. The iframe and its content is addressable on the demo website, so anything that claims the contentWindow is null or other issues, is/are a distraction. Best left to one side (or forgotten completely).
Again, I disagree. The most recent “moving target” error is iframe is null. Dealing with issues inside a null object is pretty pointless - agreed?
Once @saumil.sah has proved the browser console can be used to alter the content of the tinyMCE instance, then we can rebuild the test case, but not before.
Like I said, step-by-step. Either that, or I’m ducking out (too many moving targets, as I said before).
Will have a look on it and update soon