Last Comment Bug 670674 - (selenium) Selenium WebDriver integration
(selenium)
: Selenium WebDriver integration
Status: RESOLVED DUPLICATE of bug 721859
:
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: All All
: -- normal with 12 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 697844 702605
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-11 08:49 PDT by David Burns :automatedtester
Modified: 2015-08-13 06:58 PDT (History)
22 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description David Burns :automatedtester 2011-07-11 08:49:31 PDT
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
Comment 1 Boris Zbarsky [:bz] 2011-07-11 09:33:19 PDT
Is this something that you think should be part of Gecko, or part of Firefox?
Comment 2 Eran Mes 2011-07-13 06:31:53 PDT
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 cmtalbert 2011-07-15 13:47:52 PDT
(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
Comment 4 Simon Stewart 2011-10-27 15:26:36 PDT
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.
Comment 5 Sebastian Zartner [:sebo] 2014-07-08 05:16:39 PDT
> 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
Comment 6 David Burns :automatedtester 2014-07-08 07:40:01 PDT

*** This bug has been marked as a duplicate of bug 721859 ***

Note You need to log in before you can comment on or make changes to this bug.