You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It works. Click Element finds the element in the Iframe but I need to recall the keyword Select Frame. This is a test I am converting from Selenium1. In S1 it worked well when calling Select Frame once, then executing keywords in the frame then Unselect Frame when finished.
I also did some tests with Log Source which should logs and returns the entire html source of the current page or frame. Log Source displays the Iframe source only if called immediately after Select Frame.
In conclusion, I thought that all keywords would be executed on the Iframe after Select Frame keyword until you call Unselect Frame. However, it does not seem to be the case. I am not sure if this a bug or if I am missing something. Thanks
I had the exact same problem. After some experiments my conclusions were:
To use "Page Should Contain" we don't need to select the frame, this keyword will check text on all frames.
If we use "Page Should Contain" after selecting a frame, it will be like we unselect it, keywords to interact with elements on the frame ("Input text", "Click", etc) will not work.
If we use the keywords "Current Frame Contains" or "Frame Should Contain" instead of "Page Should Contain" we will not have such problem.
I've never found any documentation stating that, when using "Page Should Contain", there will be am implicit "Unselect Frame".
If it's not a bug, then it might be useful to include this on the documentation.
we should be able to restore the frame context.
Note the JavaScript is different because "return window.frameElement" causes IEDriverServer 2.32.0 to crash if not in an IFrame.
Initial experimentation shows promise.
What do you think, @emanlove?
I have two concerns. First will changing the behaviour upset too many existing tests? It might be a change for the better or it might be too disruptive. I'm leaning towards making the change and restoring the frame context but it is an issue I thought that should be discussed. Second is it possible to also return either the original frame context or the current context at the end of the method? I'm concerned that end user can't see the result of frame_elem and thus the context which we choose to switch too. This hidden context change could be more of an issue then the current operation. Just a thought...
In my application, a remote console session(similar to a putty session to a linux box) loads in the HTML page as an iframe. In my automation script, I am trying to enter some text into the iframe i.e. password of the device to login and to check if I can enter some text into it. I tried using keywords "Select Frame" and then "Input Text" to the xpath is failing throwing error "did not match any elements". Can someone please help ?
Better place to this kind of questions is the Robot Framework user group [1]. But in any case, before someone can help you, knowing more about the problem is required.
The full stack trace. You get this when you increase the loglevel to trace.
Versions: Python/Jython, Selenium2Library, selenium and browser.
If it is possible, demonstrate the problem with runnable example.
If point 3 is not possible, share small portion of the keywords you did use.
There has not been activity for this issue for long time and we are planning to close the old issues if they are not anymore valid ones. If you feel that this is still valid issue, could you send an update. If update is not received in a month, we will assume that this is not anymore an issues and we will close this issue.
Activity
joao-carloto commentedon Aug 6, 2013
I had the exact same problem. After some experiments my conclusions were:
I've never found any documentation stating that, when using "Page Should Contain", there will be am implicit "Unselect Frame".
If it's not a bug, then it might be useful to include this on the documentation.
ombre42 commentedon Aug 6, 2013
I believe this could be fixed.
See the WebDriver team's suggestion on fetching the current frame
If we do something along the lines of:
we should be able to restore the frame context.
Note the JavaScript is different because "return window.frameElement" causes IEDriverServer 2.32.0 to crash if not in an IFrame.
Initial experimentation shows promise.
What do you think, @emanlove?
emanlove commentedon Aug 15, 2013
I have two concerns. First will changing the behaviour upset too many existing tests? It might be a change for the better or it might be too disruptive. I'm leaning towards making the change and restoring the frame context but it is an issue I thought that should be discussed. Second is it possible to also return either the original frame context or the current context at the end of the method? I'm concerned that end user can't see the result of frame_elem and thus the context which we choose to switch too. This hidden context change could be more of an issue then the current operation. Just a thought...
ADHARMALINGAM commentedon Oct 21, 2015
In my application, a remote console session(similar to a putty session to a linux box) loads in the HTML page as an iframe. In my automation script, I am trying to enter some text into the iframe i.e. password of the device to login and to check if I can enter some text into it. I tried using keywords "Select Frame" and then "Input Text" to the xpath is failing throwing error "did not match any elements". Can someone please help ?
aaltat commentedon Oct 21, 2015
Better place to this kind of questions is the Robot Framework user group [1]. But in any case, before someone can help you, knowing more about the problem is required.
[1]https://groups.google.com/forum/m/#!forum/robotframework-users
aaltat commentedon May 23, 2016
There has not been activity for this issue for long time and we are planning to close the old issues if they are not anymore valid ones. If you feel that this is still valid issue, could you send an update. If update is not received in a month, we will assume that this is not anymore an issues and we will close this issue.
aaltat commentedon Aug 30, 2017
Closing due inactivity.
pekkaklarck commentedon Oct 18, 2017
IMHO this is a very valid problem. Nowadays covered by #959.