STR: Run https://github.com/bebef1987/gaia-ui-tests/blob/a52da48c17d93d04b5e6720e5452aafa77e2f1b3/gaiatest/tests/cost_control/test_cost_control_ftu.py The cost control app contains some iframes in it so basically if: We are in : <Base frame > <cost contol iframe> <ftu iframe> and we run self.marionette.get_active_frame() we get the HTMLElement of the current active frame if we go to the base frame self.marionette..switch_to_frame() and then try to return to the previously found active frame the element we get a error that the element is not found. ====================================================================== ERROR: test_cost_control_ftu (test_cost_control_ftu.TestCostControlFTU) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bebe/.virtualenvs/gaia/local/lib/python2.7/site-packages/marionette_client-0.5.36-py2.7.egg/marionette/marionette_test.py", line 132, in run testMethod() File "/home/bebe/gaia/gaia-ui-tests/gaiatest/tests/cost_control/test_cost_control_ftu.py", line 22, in test_cost_control_ftu ftu_step2.select_reset_report_value('Weekly') File "/home/bebe/gaia/gaia-ui-tests/gaiatest/apps/cost_control/regions/ftu_step2.py", line 24, in select_reset_report_value self.select(value) File "/home/bebe/gaia/gaia-ui-tests/gaiatest/apps/base.py", line 141, in select self.marionette.switch_to_frame(frame) File "/home/bebe/.virtualenvs/gaia/local/lib/python2.7/site-packages/marionette_client-0.5.36-py2.7.egg/marionette/marionette.py", line 527, in switch_to_frame response = self._send_message('switchToFrame', 'ok', element=frame.id, focus=focus) File "/home/bebe/.virtualenvs/gaia/local/lib/python2.7/site-packages/marionette_client-0.5.36-py2.7.egg/marionette/marionette.py", line 352, in _send_message self._handle_error(response) File "/home/bebe/.virtualenvs/gaia/local/lib/python2.7/site-packages/marionette_client-0.5.36-py2.7.egg/marionette/marionette.py", line 375, in _handle_error raise NoSuchFrameException(message=message, status=status, stacktrace=stacktrace) TEST-UNEXPECTED-FAIL | test_cost_control_ftu.py TestCostControlFTU.test_cost_control_ftu | NoSuchFrameException: Unable to locate frame: undefined ---------------------------------------------------------------------- Ran 1 test in 52.210s FAILED (errors=1)

We debugged a little bit and Marionette is definitely returning *a* frame from that method. Any attempt to probe the HTMLElement to check if it is the correct frame (eg tag_name, get_attribute('src') ) results in a StaleElementException. Out of ideas for the moment.

(In reply to Zac C (:zac) from comment #1) > We debugged a little bit and Marionette is definitely returning *a* frame > from that method. > > Any attempt to probe the HTMLElement to check if it is the correct frame (eg > tag_name, get_attribute('src') ) results in a StaleElementException. > > Out of ideas for the moment. This means the frame is out-of-process.

One of the things to understand about get_active_frame is that it returns a frame reference that is valid only from the current frame context. If you have a stack of frames like: <Base frame > <cost contol iframe> <ftu iframe> and you're in the <ftu iframe> when you call get_active_frame, the frame reference that's returned is only valid from <cost control iframe>, not <Base frame>. That is, you can't directly switch from <Base frame> to <ftu frame>; instead you need to first switch from <Base frame> to <cost control frame>, and then from there to <ftu frame>. This assumes that those frames are really nested; if <cost control iframe> and <ftu iframe> are sibling frames in the HTML, then this doesn't apply and the code you linked in this bug would be expected to work. If these frames are nested, it may be that we'd want to add some logic to automagically find descendant frames by iterating through all the intermediate frames.

Yes these are nested frames, the former scenario you described. We get this scenario quite often - Browser tabs, Cost Control FTU (this case), even the Prod Marketplace app is nested and the way B2G deals with system interactions we are switching back to the System app and then need to go back to the nested frame occasionally.

(In reply to Zac C (:zac) from comment #1) > We debugged a little bit and Marionette is definitely returning *a* frame > from that method. > > Any attempt to probe the HTMLElement to check if it is the correct frame (eg > tag_name, get_attribute('src') ) results in a StaleElementException. > > Out of ideas for the moment. So what this *probably* means is that the HTML structure is something like this: <html> <-- top-level "frame" <iframe id="costcontrol"> <iframe id="ftu"> </iframe> </iframe> </html> The frame reference you have is probably for "ftu", which is only visible when you're in the frame "costcontrol". If you're at the top-level frame, "ftu" is totally invisible, since everything inside "costcontrol" is sort of a black box until you switch into it. (It's also likely that either "costcontrol" or "ftu" is out-of-process.)

I think we can make switch_to_frame smarter, so that if you pass it an element reference that isn't in the current frame's context, it can iterate through intermediate frames in order to find the right one.

Fixing this is probably dependent on bug 779284, which mdas is working on right now, since it affects the same bits of code.

Smarter would be gooder!

(In reply to Jonathan Griffin (:jgriffin) from comment #6) > I think we can make switch_to_frame smarter, so that if you pass it an > element reference that isn't in the current frame's context, it can iterate > through intermediate frames in order to find the right one. This is not WebDriver behaviour so could impact the way that do things when we start running conformance tests. (Note if we want to get it changed we can propose it to the WG but I dont think people will go for it)

We could always make this conditional on an optional parameter which would default to False (i.e., recursive=False).

Closing out B2G related bugs. If these still happen and are valuable, please reopen with details again and how this affects Desktop/Fennec