The Marionette:getVisibleCookies IPC message listener is not used.
MozReview-Commit-ID: G1N0F8jdLHH
--HG--
extra : rebase_source : 08e40fceae3d2a88c2ae88760d37c00bd8aecbca
This deletes the third-party mozrunner crate off crates.io in favour
of using the in-tree version from testing/mozbase/rust/mozrunner.
MozReview-Commit-ID: 6xQZ99FYrdP
--HG--
extra : rebase_source : 90ef2df2924d4194652255728d73ee03ed729ac3
This moves the Rust crate mozrunner into central from GitHub.
The old repository will be graveyarded:
https://github.com/jgraham/rust_mozrunner
The git history is not considered important, hence this does not
overlay that onto central like we did for testing/geckodriver and
testing/webdriver.
MozReview-Commit-ID: J4ZYdow2Lkw
--HG--
extra : rebase_source : 1b499b708105a89a5fa3ae6ecac71c4946e20755
This moves the WindowState enum from testing/marionette/wm.js to
testing/marionette/browser.js in order to make it easier to apply
the forthcoming Marionette window tracking refactoring patches.
In other words, this patch functionally does not change anything.
MozReview-Commit-ID: 53MKIRHl11p
--HG--
extra : rebase_source : d048086ab48449ba02853076451e6dd1909bafa6
With the WebDriver spec the calculation of the pointer origin
position will no longer be done based on the top and left
position of the referenced element, but based on the center
point of the viewport.
This capability allows to turn on and off the new behavior in
Firefox 59 and following.
MozReview-Commit-ID: Ir3HpgvVg6Y
--HG--
extra : rebase_source : 1538674e333b85100934b498cfc72ded3b58c489
This moves the WindowState enum from testing/marionette/wm.js to
testing/marionette/browser.js in order to make it easier to apply
the forthcoming Marionette window tracking refactoring patches.
In other words, this patch functionally does not change anything.
MozReview-Commit-ID: 53MKIRHl11p
--HG--
extra : rebase_source : 1d0dcbac2c5089a0b9249794548dee7506b6b568
It was neglected to mark navigator.credentials as [SecureContext], yet it
must be for spec compliance and powerful-features compliance.
MozReview-Commit-ID: BYKGqqhoS2L
--HG--
extra : rebase_source : 441be2ae91d51cfff1ed5a8d1e96db4f9a3c917c
Because we use a lot of data URIs when testing Marionette, the URLs
we log during navigation can be quite long. As with logged packets,
we should truncate the URLs.
MozReview-Commit-ID: AKpr5vvdU8P
--HG--
extra : rebase_source : 12d367901f96fe972a1b38ca76b7b46c1a8e47d3
This moves the Rust crate mozversion into central from GitHub.
The old repository will be graveyarded:
https://github.com/jgraham/mozversion
The git history is not considered important, hence this does not
overlay that onto central like we did for testing/geckodriver and
testing/webdriver.
MozReview-Commit-ID: HeBggGmGsg6
--HG--
extra : rebase_source : 14f6943394bd7b6e8daa7a35b29bc209b7ac9ad4
This patch checks that the element satisfies its form control
constraints, as well as being empty, before deciding not to clear
the element. This will make it possible to clear elements that
have invalid input.
The "clear a resettable element" algorithm is missing a check of
the <input> element's ValidityState. WebDriver:ElementClear has
a subtle bug that only manifests in Gecko because Blink rejects
invalid key input to validation fields such as <input type=number>,
but Gecko does not.
The value property of <input type=number> will not be updated unless
the input is actually valid, which means the first step of the algorithm
will pass irregardless of whether the user has actually modified it.
MozReview-Commit-ID: C2M3Fl1iKx6
--HG--
extra : rebase_source : 8e5698cf8adab4361d16ada403858d0703861d9a
Introduces a new function, isMutableFormControl, to the element
module in Marionette that tests if an element is a form control
that can be edited by the user. This replaces the proprietary
UNEDITABLE_INPUTS set used previously.
An editable element is, according to the WebDriver standard, an
element which belongs to the two subcategories of editable elements.
This patch implements the first category of the mutable form controls.
MozReview-Commit-ID: Aix19mq3lcb
--HG--
extra : rebase_source : 1e3d671cd2d3ff618bf2fff3a2d8dadbd82d0540
We use bogomips as a convenient indicator or emulator performance/health and
make that available in the android-performance.log artifact. When the task
times out, that artifact is not uploaded, leaving me curious about what the
bogomips were; let's dump it to the test log.
With the forthcoming window tracking changes the message listeners of
the content frame script are left listening for the duration of the
Marionette lifetime, and not for the duration of the Marionette session.
To prepare for the window tracking refactoring, we will want to
remove message listeners separately from clearing the session state.
Functionally, this patch changes nothing in Marionette for the moment,
except we send two IPC messages to the frame script instead of one.
MozReview-Commit-ID: DwVBCpvk9V9
--HG--
extra : rebase_source : d473a51209eeaf20967303af5aec7376e38fd283
sendSyncMessage returns an array of replies from the frame message
manager, each item being the return value from each message listener
that handles the message.
In testing/marionette/driver.js there are two handlers for
Marionette:Register, but it is not predictable at the moment when
both or either one of them is triggered. We would, however, always
expect a response, which means the reply array should never be empty.
MozReview-Commit-ID: 5F8YfKO8jBU
--HG--
extra : rebase_source : c23900fed32a52d228c91cb6428be569fb967f41
outerWindowID is no longer used for adding message listeners,
which means we do not need to store it globally.
MozReview-Commit-ID: HZ0oY7ozwnu
--HG--
extra : rebase_source : 4a03927b5bdbe3d34a45faf8fa9646e0a58bd96a
The global message manager reaches all browsers and all frames.
If Marionette was _not_ using the global message manager, this
would have been the correct approach.
MozReview-Commit-ID: HKrlfd9pzK2
--HG--
extra : rebase_source : 8a63a0928af574f27d5612d0cef88e4f3a80481b
The forthcoming window tracking refactoring introduces the new
abstractions ContentContext and ChromeContext that to a large extent
share the same interface. They make it possible to interact with
both types of browsing context in a uniform manner.
Marionette currently has a lot of convoluted if-conditions to
paper over the differences between ChromeWindow, <xul:browser>,
and browser.Context. Examples of this includes the assert.window
and assert.contentBrowser assertions: they essentially perform the
same job, but does not share the same API because the underlying
APIs they call are different.
In an effort to prepare Marionette for the window tracking refactoring,
this patch adds a bit of glue to combine them both into one assertion
called assert.open. This checks that the browsing context has not
been discarded.
MozReview-Commit-ID: K5e7Sr1mq0
Andreas Tolfsen
Emilio Cobos Álvarez
Ciure Andrei
iceman
Julian Descottes
Dorel Luca
Henrik Skupin
Geoff Brown
Tarek Ziadé
Coroiu Cristina
Tiberius Oros
Ryan VanderMeulen
Cosmin Sabou
Kartikaya Gupta
Alex Chronopoulos
J.C. Jones
Bob Clary
Jim Chen
Edgar Chen
Chung-Sheng Fu
Xidorn Quan
Noemi Erli
Gurzau Raul