Open Bug 1365886 Opened 3 years ago Updated 1 year ago

Add support for Actions in chrome scope


(Testing :: Marionette, enhancement, P5)

Version 3


(Not tracked)


(Reporter: automatedtester, Unassigned)


(Blocks 4 open bugs)


It would be good to add the actions support to Chrome eventually.

Original request in
Summary: Add Actions support to Chrome → Add support for Actions in chrome scope
I raised the request on GitHub.

I'd like to take a stab at implementing, and have setup the development environment, following the instructions (more or less) at

Could I get some mentorship in terms of which  files (or zipcode there of) that I should start looking at to implement?


chase  at
Maja, can you mentor this bug?
Flags: needinfo?(mjzffr)
You're welcome to take a look. I think the main reason we haven't implemented this yet is that we haven't yet thought about how to maintain and possibly share state (seen elements, input state, inputs to cancel) between driver.js and listener.js.

The main entry-point for actions is here: and this is where you should handle the case of chrome scope. The other actions-related functions below are the legacy actions implementation -- ignore them. 

The corresponding content-scope actions code is in listener.js: and

I think ato might have some opinions regarding how to extend actions to work in chrome scope (it should be an "extension command" I guess) and how it should work.
Flags: needinfo?(mjzffr) → needinfo?(ato)
First of all, I don’t know if there is a pressing need for actions in chrome context: we mostly get by with the high-level Element Click and Element Send Keys commands to interact with XUL elements at the moment.  I can see how having actions available might be useful to write more sophisticated Firefox UI interaction tests, but it’s not clear to me if we have anyone lined up to write such tests?

For keyboard input, the current implementation in testing/marionette/action.js should work fine also for chrome space.  It ends up calling down to testing/marionette/event.js, our synthetic interaction module, which Element Send Keys also uses.  This might be the easiest thing to do first.

For mouse interaction I’m unsure if the same assumptions about the location of the cursor that we make for content context will be valid for chrome.  Specifically we need to handle the case where a chrome context mouse click ends up interacting with web content/the viewport.  Not sure how we should handle this, but maybe an error could be returned.

When the mouse is moved over the browser, we also potentially could end up causing DOM events to be triggered in content context, which isn’t desired but may be a natural consequence.

When it comes to shared state, I don’t think we would have to share the known web element cache between chrome and content, but it’s a bit of an open question whether input state, inputs to cancel, and generally any state associated with the individual pointer sources.

If we do want to share this state, I would suggest standing up a service in chrome context (testing/marionette/driver.js), much like our cookie service (testing/marionette/cookie.js), to keep all this information.  This means our current content implementation of actions needs to change to use this service.
Flags: needinfo?(ato)
OS: Unspecified → All
Hardware: Unspecified → All
Priority: P4 → P5
You need to log in before you can comment on or make changes to this bug.