Closed Bug 889581 Opened 8 years ago Closed 4 years ago

Support for "sticky" frames so commands could always target a specific frame.

Categories

(Testing :: Marionette, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jlal, Unassigned)

References

Details

Switching between frames can get messy when dealing with three or more frames if you need to switch back and forth (lots of global state)...

A common case is in gaia testing where we typically have two or more frames.

- the system app
- app under test
- and possibly an activity, etc..

Ideally it would be useful to attach some "id" to each frame so we can target commands at the given frame and as long as those frames are still running it would target that one frame rather then the "current" frame in global space. I would expect an error to be thrown if that frame is no longer available.
Maybe something like this at the protocol level?

{ type: 'executeAsyncScript', value: '...', args: [], to: '0', session: '6-b2g', frame: 'myiframeonly' }
(In reply to James Lal [:lightsofapollo] from comment #1)
> Maybe something like this at the protocol level?
> 
> { type: 'executeAsyncScript', value: '...', args: [], to: '0', session:
> '6-b2g', frame: 'myiframeonly' }

This would be complicated to support in a webdriver-compatible manner.

What about letting the client do most of the work?

If we implement a get_active_frame() command per bug 855327 and let switch_to_frame() return a frame reference that could be used in future calls to switch_to_frame(), then -

scope.executeScript() could wrap something like:

let currentFrame = driver.getActiveFrame();
driver.switchToFrame(/* some frame reference defined by this scope */);
driver.executeScript(...);
driver.switchToFrame(currentFrame);
++ that would be a huge help getting the currentFrame would drastically simplify my use case anyway.
Cool, I think we can implement that soon-ish.
James, there is also this which gets the displayed app (but not necessarily the one that Marionette is attached to):
https://github.com/mozilla/gaia-ui-tests/blob/master/gaiatest/atoms/gaia_apps.js#L232

but often it's also useful to get the frame that Marionette is attached to aswell and bug 855327 would cover that case.
(In reply to Jonathan Griffin (:jgriffin) from comment #2)
> (In reply to James Lal [:lightsofapollo] from comment #1)
> > Maybe something like this at the protocol level?
> > 
> > { type: 'executeAsyncScript', value: '...', args: [], to: '0', session:
> > '6-b2g', frame: 'myiframeonly' }
> 
> This would be complicated to support in a webdriver-compatible manner.
> 

Agreed! I think having that information will cause a lot of trouble since we, and the webdriver project, assume that you know which document you want to be on. This forces the person writing marionette/webdriver code to code something deterministic.


NOTE: The following is just a gut feel

It feels like we are adding code to get around issues where the frames aren't named . I havent checked Gaia to back that statement up but we should be adding attributes to nodes to help with automation.

I dislike the idea of getActiveFrame since it removes the deterministic value of tests. If you clicked a link and it opened twitter I would hope you realised and used switch_to_* to move back to the original. This type of behaviour will be documented in WebDriver 1.1+ since it has to do with mobile intents.
I think the intent of getActiveFrame (correct me if I'm wrong, Zac) is to get a reference to the frame that is active for Marionette, not the frame that is "on top" of the UI.

So, if you clicked a link and it opened twitter, getActiveFrame() would still return the frame you were on before you clicked the link, not the twitter frame.

But I agree, a lot of this is workaround for the fact that the iframe elements in gaia don't always have predictable attributes that we can use for switching.  If they did, would we no longer need this?
Yes that's correct jgriffin, although I did post a snippet in comment #5 about getting the topmost/displayed frame Dave Hunt mostly made that as a workaround until bug 855327 is done.

We do reliably know and get the frame we want or Marionette should be on deterministically with hardcoded locators but we would like to do it a bit more tidily. Sometimes there can be 2 or 3 frames nested deep to the content you want and you have to traverse up before going back down again and you have to save or expose all of these references to each of those frames up and down the class structure you're using. Where we want to abstract these functions we can't keep or duplicate locators for frames so it helps to get it straight from Marionette.

This is a lot more complex use of frames than I came across in my time using WebDriver before Firefox OS so I think we may yet break into more new territory and use cases. For example because Marionette will still send commands to a frame even if it is completely obscured so we lose the ethos that WebDriver will only let you interact with visible elements. The current topmost frame might be a useful thing for Marionette to know and use even if it is not exposed at the API level.
We won't be supporting this feature
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.