The default bug view has changed. See this FAQ.
Bug 670674 (selenium)

Selenium WebDriver integration

RESOLVED DUPLICATE of bug 721859

Status

()

Core
General
RESOLVED DUPLICATE of bug 721859
6 years ago
2 years ago

People

(Reporter: automatedtester, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
Selenium WebDriver is a browser automation framework that allows users to test their web apps in an automated fashion.

With their last release[1], which is there first stable release of the 2.x series, there were 2 browser vendors who have integrated WebDriver support into their browsers:

Opera[2]
Google Chrome[3]

WebDriver is signing up to the Web Testing IG in the W3C[4] in the hope that it can become a standard.

[1] http://seleniumhq.wordpress.com/2011/07/08/selenium-2-0/
[2] https://github.com/operasoftware/operadriver
[3] http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/chrome/test/webdriver/&type=cs
[4] www.w3.org/2011/05/testing-ig-charter.html
Alias: webdriver
Is this something that you think should be part of Gecko, or part of Firefox?

Comment 2

6 years ago
A good example of a difficulty we encounter with every release of Firefox is native events - each new security measure makes it more difficult to generate input events as the OS level. Since Firefox 4, binary XPCOM components have to be recompiled for each major version (every 3 months). It's a major feature for Selenium and is difficult to implement without support from the browser itself (the Chrome driver, being a part of the Chromium tree, can inject events directly into the browser's input queue).
Ideally, there would be a way to cooperate with the browser in a better way to generate these events. An XPCOM component to inject such events would be very helpful (and it'd still be a small part of the bigger picture).

Comment 3

6 years ago
(In reply to comment #2)
> A good example of a difficulty we encounter with every release of Firefox is
> native events - each new security measure makes it more difficult to
> generate input events as the OS level. Since Firefox 4, binary XPCOM
> components have to be recompiled for each major version (every 3 months).
> It's a major feature for Selenium and is difficult to implement without
> support from the browser itself (the Chrome driver, being a part of the
> Chromium tree, can inject events directly into the browser's input queue).
> Ideally, there would be a way to cooperate with the browser in a better way
> to generate these events. An XPCOM component to inject such events would be
> very helpful (and it'd still be a small part of the bigger picture).

We have revived an effort to investigate the feasibility of a native C library that can be called from JS via jsctypes so that we can create native OS level events at will from javascript running in the browser's chrome scope.  We'll test it first and see if it provides us any significant wins over the use of the in-browser event generation mechanisms like eventutils.js. [1]

I'm not sure that having something implemented in XPCOM really can get you OS level events though, so I'm not sold that it would really be what you wanted.  What I'd really like to achieve would be finding a way to script OS level interactions with the browser from javascript inside the browser.

[1]: http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/EventUtils.js
(Reporter)

Updated

6 years ago
Depends on: 697844

Comment 4

6 years ago
On the selenium project we've repeatedly seen cases where JS event emulation isn't sufficient. The events are untrusted and don't set various read-only properties for a start. Worse, it's essentially impossible to fire the correct sequence of events when simulating drag and drop. Firing events at the OS level work around this problem.

The obvious implementation of firing events at the OS level (namely something like "SendInput" on Windows) demands that the browser being used has focus. Since tests are frequently run in parallel and on developer workstations, this isn't an acceptable solution (I'd be happy to share disgruntled emails from users from when webdriver did this originally :) Sadly, no OS is really designed to send events to a background window, though we already do extremely accurate user emulation.

The ideal solution is to do something like Opera and Chrome do: inject the events directly into the browser's event queue. This is reliable, extremely fast and provides a really great user experience.
(Reporter)

Updated

6 years ago
No longer depends on: 697844
(Reporter)

Updated

6 years ago
Depends on: 697844
(Reporter)

Updated

5 years ago
Depends on: 702605
> WebDriver is signing up to the Web Testing IG in the W3C[4] in the hope that it can become a standard.
Obviously you're actively working on the spec at https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html. Maybe you could add the URL to the 'URL' field of this bug, so it can be referred to?

Sebastian
(Reporter)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 721859
Alias: webdriver → selenium
You need to log in before you can comment on or make changes to this bug.