Update on Firefox Support

[Steven Zaluk]

I was wondering if the development group would be able to give us an update on the status of FirefoxDriver/Marionette?  I saw a comment in one of the tickets open for an issue that starting with FF45, the FirefoxDriver will no longer work but at the same time Marionette will not be ready until well after FF45 is released.  I have noticed that FF has gone from being one of the best supported browsers to being one of the buggiest and I am very much looking forward to Marionette.

Thanks in advance for all the hard work you guys do in building and supporting this platform!  Your work is more appreciated than you can imagine.

--Steve

[Andreas Tolfsen]

Hello Steven!

On 1 January 2016 at 21:54, Steven Zaluk <sjz...@gmail.com> wrote:
> I was wondering if the development group would be able to give us an update
> on the status of FirefoxDriver/Marionette

We are adding W3C WebDriver spec compatibility to Marionette, and this
work is tracked in the
https://bugzilla.mozilla.org/show_bug.cgi?id=webdriver bug.

The progress of this work is slow mainly due to Gecko-specific
extension complexity and backwards compatibility concerns with
Mozilla’s existing body of tests.

Since the specification only exists in English prose, we are also
concurrently working on developing a test suite. Still, it is useful
if you report any issues you have using Marionette+wires as a backend
for your tests to generate visibility on what areas we should focus
on.

> I saw a comment in one of the
> tickets open for an issue that starting with FF45, the FirefoxDriver will no
> longer work but at the same time Marionette will not be ready until well
> after FF45 is released.

As far as I know, Firefox 45 introduces add-on signing that prevents
us from using FirefoxDriver with official, stable builds.
Furthermore, when multi-process Gecko (e10s or ‘Electrolysis’) rides
the trains, FirefoxDriver will in all likelihood stop working.

Due to the nature of WebDriver, and FirefoxDriver in particular, the
add-on will likely never be approved in add-on review because it
allows arbitrary script evaluation in privileged contexts.

It will however still be possible to use FirefoxDriver with Firefox 45
and later if you use Nightly or the Developer Edition builds.

[Steven Zaluk]

Thanks for the great info Andreas!  I look forward to using Marionette.  I will be glad to log any issues I see with it.

--Steve

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAL_dnaVYncqKnD0k01T6H_uDbsE7y5z5JeQPkxqkkA7huf7Gkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[David Stark]

Hi all,

For Selenium Builder, I'm faced with a related question. I've been tidying up Builder to be acceptable under the new add-on signing regime, and it's now been accepted. However, this came at the cost of removing support for local playback of tests.

I'd now like to re-add local playback, or at least a usable subset of it. Obviously, eval() is right out, but click() might be OK. Given the distinct non-readiness of Marionette, does anyone have a suggestion how to do this best? I don't want to re-implement things from scratch and introduce subtle semantic differences.

So the question is how much of Selenium I can cleanly use without including forbidden things like eval(). I'm looking into webdriver atoms, but perhaps I can use a higher-level interface?

- David

[Andreas Tolfsen]

On 6 January 2016 at 12:35, David Stark <zark...@gmail.com> wrote:
> I'd now like to re-add local playback, or at least a usable subset of it.
> Obviously, eval() is right out, but click() might be OK. Given the distinct
> non-readiness of Marionette, does anyone have a suggestion how to do this
> best? I don't want to re-implement things from scratch and introduce subtle
> semantic differences.
>
> So the question is how much of Selenium I can cleanly use without including
> forbidden things like eval(). I'm looking into webdriver atoms, but perhaps
> I can use a higher-level interface?

It’s not really clear to me how Builder works right now. Does it wrap
FirefoxDriver and call down to the command implementations internally
when it does playback?

I imagine that it is possible to embed atoms for WebDriver primitives
quite easily, but others that require browser/tab control and
cross-process communication will be more difficult, though I haven’t
thought hard about this.

One of the things we have discussed loosely with the Developer Tools
team here at Mozilla is exposing Marionette as a REPL (or something
more appropriate) in the debugger. This isn’t a far cry from exposing
the same interface to (privileged) extensions.

[David Stark]

On 06/01/16 14:41, Andreas Tolfsen wrote:

It’s not really clear to me how Builder works right now.  Does it wrap
FirefoxDriver and call down to the command implementations internally
when it does playback?

I imagine that it is possible to embed atoms for WebDriver primitives
quite easily, but others that require browser/tab control and
cross-process communication will be more difficult, though I haven’t
thought hard about this.

One of the things we have discussed loosely with the Developer Tools
team here at Mozilla is exposing Marionette as a REPL (or something
more appropriate) in the debugger.  This isn’t a far cry from exposing
the same interface to (privileged) extensions.

It wrapped the FirefoxDriver, yes. It literally just contained the addon that Webdriver installs in Firefox to manipulate it.  Sending messages to CommandProcessor to drive playback. This wasn't a great approach: a big blob of semi-opaque code that wasn't getting updated often enough. And as discussed, it contained a bunch of native code and eval() that wouldn't be accepted by Mozilla's new addon certification scheme.

So for Selenium Builder 3, I simply ripped it all out, along with all Selenium 1 support. This reduced code size by about 80% and means I now fully understand all of the code in the project, which is nice. But of course local playback is a really important feature for a test recording tool!

So now, I'm looking for the best way to locally execute at least basic commands like get and click in a way that are acceptable to the certification process. The internal format in Builder maps fairly closely to the JSON wire protocol, which is what it uses for remote playback, so it's really very similar to what FirefoxDriver needs to do.

Being able to talk to Marionette from a privileged extension would probably fit the bill, but as a stop-gap solution, using (a subset of) webdriver atoms might be the way forward? Of course I could just write my own code to do this all, but it would almost certainly introduce subtle semantic differences between local and remote playback.

Thanks for your interest,

- David

[Andreas Tolfsen]

I realised I missed out a word in my previous email. I meant to say:
“I imagine that it is possible to embed atoms for _some_ WebDriver
primitives quite easily”.

On 6 January 2016 at 15:45, David Stark <zark...@gmail.com> wrote:
> And as discussed, it contained a bunch of native code and eval() that wouldn't be
> accepted by Mozilla's new addon certification scheme.

I should add that I just have shallow knowledge of the new criteria
for signed extensions.

> So for Selenium Builder 3, I simply ripped it all out, along with all
> Selenium 1 support.

I’m very happy to hear that Selenium 1 support is phased out!

> So now, I'm looking for the best way to locally execute at least basic
> commands like get and click in a way that are acceptable to the
> certification process. The internal format in Builder maps fairly closely to
> the JSON wire protocol, which is what it uses for remote playback, so it's
> really very similar to what FirefoxDriver needs to do.

I think a naïve and simple FirefoxDriver implementation with a limited
feature set, using Selenium atoms for Click and some WebExtension
workarounds to implement Get could get you close.

But I should add that as the WebDriver standard increases in
complexity, such an implementation done purely in-content with use of
some extension privileges might both be a lot of work and likely
non-conformant ad infinitum due to the privileged nature of the
WebDriver.

For script evaluation in content, is sandboxing available to extensions?

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.Sandbox

> Being able to talk to Marionette from a privileged extension would probably
> fit the bill, but as a stop-gap solution, using (a subset of) webdriver
> atoms might be the way forward? Of course I could just write my own code to
> do this all, but it would almost certainly introduce subtle semantic
> differences between local and remote playback.

Yes, such a thing would be far into the future. You should be looking
at solutions that are immediately possible to achieve.