Our click + page load implementation doesn't handle complex navigation
scenarios yet. As such those should not be triggered inside our unit
tests.
MozReview-Commit-ID: Cog5vohttes
--HG--
extra : rebase_source : 7068483f041ab1895ecc921f377da9bfd420ec23
Continue to allow non-multiprocessCompatible extensions in automation.
There are a ton of places that would need to be changed, many of which
will be changing soon anyway with the non-webextensions change in 57
so this is mostly the expedient route to keeping the tree green.
MozReview-Commit-ID: EZZoDVdhLfy
--HG--
extra : rebase_source : 34aa762917566b052ade6372280caed72fbfbe9a
Because DevEdition builds are intended to be shipped, we must force clobbers on all of them. We also need to fix the update channel, which is currently still set to "beta". In order to make it possible to override this we need to change stage_platform to a unique value.
--HG--
extra : amend_source : 84422951ad22665c1cf027882171db01953ff840
To make OS X and Windows DevEdition builds upload to the "devedition" area on archive, instead of "firefox".
--HG--
extra : amend_source : b5472a9c2f27aa59b7f8715800dcb2161fe4252f
Since lengthPairType and positionType share the same testing logics, we shall
just reuse lengthPairType::{testInterpolation, testAddition} for positionType.
MozReview-Commit-ID: 1nBBHmTB3U9
Similar to the other unload and load events during a page load,
the hashchange event should only be handled if the event's target
document is the current window.
MozReview-Commit-ID: F1LMBh5Cy4A
--HG--
extra : rebase_source : 668fd6946067989e7e732b24baf6de2e85541f21
originalTarget seems to be outdated and not used anymore for each
navigation related event. But target is, and as such handleEvent
has to make use of that instead.
MozReview-Commit-ID: AN2H1PbCt7A
--HG--
extra : rebase_source : fbead2b5b802454f0e288fb9696db5d422e46b50
We shouldn't be running pymake any more. So code to work around its
behavior is no longer necessary and can be removed. Good riddance.
MozReview-Commit-ID: AlV6ZLiA6WB
--HG--
extra : rebase_source : 56252a8d96f108fd24878e7a26f0d4ffe4a0db45
Now that mozharness is calling `mach build` to invoke the "check" target,
there are no more consumers of the "enable_pymake" config option. So we
remove it from the configs.
We also remove definitions of the "make" executable referring to pymake.
The only call sites I could find for "query_exe('make')" are in
testing/mozharness/scripts/mobile_l10n.py. So most of these definitions of
the "make" executable appear to be a cargo cult or left over from a
previous rewrite (the code we just changed to stop calling "make" wasn't
using query_exe). Since mobile_l10n.py is still using query_exe() to find
the make executable, there's a chance switching away from pymake (if this
patch even does that - I don't think we touched a config file related to
that script) could break something. I'm fine with teasing out that bug.
MozReview-Commit-ID: 7HR6ShAKcoV
--HG--
extra : rebase_source : 07c6a6f7aaab6d7fceeab46b6ca2744c964148dd
We switch mozharness to use `mach build` to invoke the "check" make
target instead of using `make` itself. Because `mach` is the interface
that everyone should use and `make` is an implementation detail.
My editor also snuck in a change to normalize a CRLF line ending.
MozReview-Commit-ID: 4gdE6oeK0Lz
--HG--
extra : rebase_source : 0bfd6503a25f6b4304b596bd59ef99294c011474
Discussion at <https://github.com/whatwg/dom/issues/319>. In short, the
specification used to say to throw sometimes InvalidCharacterError and
sometimes NamespaceError, but browsers disagreed on which to throw in
corner cases, and everyone agreed it wasn't worth the effort to spec the
distinction, so we just changed it to InvalidCharacterError across the
board.
The test changes are already upstream.
MozReview-Commit-ID: AWSZBznQprG
--HG--
extra : rebase_source : 2f0051f48124380f17300a38ceb8c2ab23015ca1
Because individual <option> elements are painted and represented in the
DOM when they belong to a <select multiple> list, the center point of
the list might be one of the options.
To take this into account, we perform an inclusive descendant check
(DOMElement.contains) to see if the <option> element is a descendant of
the container <select> element.
In the case the targetted element is the element itself, the test will
still pass since it is an _inclusive_ descendant check. In other words,
containerEl.contains(tree[0]), if tree[0] is equal to containerEl,
will pass.
The relevant specification changes were made in
40abcefd6a.
MozReview-Commit-ID: ORX8zLxQJ
--HG--
extra : rebase_source : 87ca38df6696257d569ef1ffcb888426d1f569af
There appear to be no in-tree users of this function and it references
"b2g." I'm pretty sure it is dead code.
MozReview-Commit-ID: EHHRQ2iqQoP
--HG--
extra : rebase_source : ec136063dc5e4243232fce5289a8f47bd925b481
We shouldn't be running any Firefox OS automation.
MozReview-Commit-ID: 4ea9SL7jill
--HG--
extra : rebase_source : 6d5c457d14d9d2b2b4abda47a2b3bfa1fa745d36
We shouldn't be running any automation related to Firefox OS. We should
be able to delete these files.
MozReview-Commit-ID: SY5f0GD9NQ
--HG--
extra : rebase_source : 3b7b5b28bc5da554ad9082c1c3115b3ab8de2e0a
These were the last occurrences of "gaia" in the mozharness directory.
MozReview-Commit-ID: 8ACEw1rMoUS
--HG--
extra : rebase_source : b5d98c9166d75a83f5303ee0faa34484b6f998d3
So far, we don't have a type to test anamations of a pair of length.
Since border-spacing consists two absolute lengths, we shall add this
new type.
MozReview-Commit-ID: Bo8VMWPLDHc
--HG--
extra : rebase_source : 26439e622fac5806465e971b84a111c9e01ffe1e
When refactoring the tests for the Set Window Rect command, it was
discovered that the Maximize Window command was not synchronous.
This patch makes GeckoDriver#maximizeWindow synchronous by waiting for
the DOM resize event to fire before returning the window rect to the user.
It also aligns the command with the WebDriver standard by making it
restore the window to its original size when calling the command a
second time.
MozReview-Commit-ID: Ft3tn2A4m7u
--HG--
extra : rebase_source : 52b523e53dd19cc8bdc4631382c96db5906f333a
When the window's size is being set to the window's existing size,
Marionette unconditionally listens for the DOM resize event. When a
window is not resized, no such event fires.
This patch skips setting the window size when the window's current size
is the requested size. This bypasses the problem of listening for an
event that never occurs.
It also combines the window position- and size tests into a
test_window_rect.py test, since they share many of the same
characteristics.
Fixes: https://github.com/mozilla/geckodriver/issues/643
MozReview-Commit-ID: IUtCFXwT1fh
--HG--
extra : rebase_source : 43c4d0e24cf1e0dc6102af48b8fe6f075b6dd4a2
The test assumes the click point is the centre of the element, whereas
WebDriver uses the _in-view_ centre point to perform clicks.
If parts of the element is rendered outside the viewport, the click
point is calculated from visible portion of the element that is seen in
the viewport.
This means that if any portion of an element is within the boundaries of
the viewport, it is clickable. If it is not, then it is not interactable.
This change is unfortunately not accompanied with any
implementation changes, but prepares Marionette for the changes
to the Element Click implementation that will come as part of
https://bugzilla.mozilla.org/show_bug.cgi?id=1321516.
MozReview-Commit-ID: Kh0zzRrtmJ4
--HG--
extra : rebase_source : 63cc463a11d5ca085e7a96ea84dcadbe3bb90204
With remoteness enabled content framescripts don't seem to inherit the
appenders for loggers, which have been set by the main script. To get
the output written to stdout they have to add their own appender. To
prevent duplicated output after framescripts get reloaded, the addition
of the appender should only happen once.
MozReview-Commit-ID: A5TMQvQu0Iy
--HG--
extra : rebase_source : 9a9ecdb8aec8d7b310b916407edbac77b8ec88c9
If the click command triggered a page load, it should not return before
the page has been fully loaded. With this patch we allow an opt-in for
commands to make use of an unload check. It's set to 200ms right now, and
will cancel an ongoing waitForPageLoad() if no page activity is detected.
MozReview-Commit-ID: DWV53sckBS2
--HG--
extra : rebase_source : 1b7905c101b7ebf406e88c73be5d0e069b7342c0
Tests for page timeout durations have to use an HTTPD handler that delays
or slows down document load. Otherwise there a risk that the timeout error
is not returned before the document finishes loading.
MozReview-Commit-ID: HGGcXfCuaSH
--HG--
extra : rebase_source : c79b01ca4e56e21877c6fe94309b7b0424d9b552
In the case when the trigger callback inside navigate() uses a generator,
the code has to be synchronized and needs to wait until the contained
command has been completed.
MozReview-Commit-ID: 8qKUMvH7HpS
--HG--
extra : rebase_source : 19a87058d62088701914ab2a468ddffaecec1fe2
In the case of switching to an in-process frame, the checkLoad timer
is setup which waits for the frame's content to finish loading.
But the command doesn't actually wait for those events and calls
sendResponse() immediately. This causes a race condition for the
following commands.
MozReview-Commit-ID: 6vuQ7paQ55K
--HG--
extra : rebase_source : ceb590f435d84ead4eba2e718e1ebaa01900d33f
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 92870f1adc7ae68e58b15443e4223012bdf0e39a
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 4beba0212411a0f5867feb506bbf732f5a934fa9
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
Note that the UITour library can still show a panel in the event that we want to
promote the feature that way.
MozReview-Commit-ID: FzKSzO987h7
--HG--
extra : rebase_source : 8c129106478559f011a3a4e311331851939ab408
This change makes it possible to click elements that has its
pointer-events style property set to "none".
If an element has its style property pointer-events set to "none",
the element in view test will fail due to document.elementsFromPoint
excluding it due to non-interactability. This is only a problem when
checking if the element is inside the viewport, and not when actually
performing interaction with the element.
The relevant specification change is
ba6ee925b5.
MozReview-Commit-ID: JwZB6fm7P9A
--HG--
extra : rebase_source : 18ddf7955c7e0bc6d1d7f798aebc6e09799a99ca
This makes sure that tests that either specifically want to test fewer content
processes *or* tests that don't work with multiple content processes will get
what they ask for when they run.
MozReview-Commit-ID: 6FI8BmB98Zi
--HG--
extra : rebase_source : 52fbf155fb3d1ae2a9805968aa96761bc27ed0ed
In cases where CPU usage couldn't be recorded, we may incur a division
by 0 exception.
While we should figure out why we're not collecting CPU data, this patch
papers over the uncaught exception which was causing mozharness to bail.
MozReview-Commit-ID: 3PrIl6cEzuf
--HG--
extra : rebase_source : ece317b73af6a5b47ccad30981963457e6c6b9a8
These builds do not have a distinct variant and they do not have an artifact
build equivalent, so specify this in their respective mozharness configs.
MozReview-Commit-ID: CHMglUoP8LR
--HG--
extra : rebase_source : a82323616c8266a6e7d4d82fde0da441da3cc3f3
The previous commit changed our default behavior to make these entries no longer
necessary.
MozReview-Commit-ID: 5bKEH7zbbWi
--HG--
extra : rebase_source : 431d7f6df1136a20ed5796c23832879c5be99790
No builds other than vanilla opt and debug builds are supported by the artifact
code currently, so prevent variant builds from being replaced by artifact builds
by modifying mozharness' replacement logic to replace a build with an artifact
build only when it is a regular opt or debug build or when specified by a
config.
MozReview-Commit-ID: KUUgrbga53l
--HG--
extra : rebase_source : d3c6e3929bf02893ec18f54b0a8739181067e22b
This will make it easier to correctly star these failures, which
otherwise simply show up as a false positive leak.
MozReview-Commit-ID: 5P6AMRyYmtI
--HG--
extra : rebase_source : 6e63bffb6cdcb389d6533acbc44c2a206009a99e
Practical changes:
1) Some additional method arguments are nullable or optional, which
matches Chrome/WebKit. They make more sense non-nullable and
non-optional, but Chrome is afraid of the compat impact of changing.
2) Added [CEReactions] to deleteFromDocument().
MozReview-Commit-ID: Kg9EDubnEui
--HG--
extra : rebase_source : 1d47ee0b12b0b719159c326f789dd6e6b6000c8e
Add preliminary support for returning unexpected alert open errors when
calling commands that require it according to the WebDriver standard.
Also fixes a faulty test that seems to believe it is fine to click an
element whilst an alert is present.
Further work needs to be done on user prompts, asserts, and the handler
for user prompts in https://bugzilla.mozilla.org/show_bug.cgi?id=1264259.
MozReview-Commit-ID: BiWURoQECji
--HG--
extra : rebase_source : caa1506a0e972c7ad0da2d31993fb0b8ecc1ee17
This patch removes the call to element.isVisible when clicking XUL
elements because it does not do anything useful. element.isVisible skips
the Selenium atom.isElementDisplayed check for XUL elements and runs a
few web content/viewport centric tests that always pass in XUL.
It also splits the chrome click out to a separate function to avoid a
few if-conditions.
MozReview-Commit-ID: EkcwT77ku3C
--HG--
extra : rebase_source : ee5e8148934ec008cda996610c20a826f86412af
The window reference may have been discarded as a result of interaction.
For example, this may happen when clicking a button that deletes the
host <iframe> element containing the child window. In this case, the
WindowProxy will set its closed property to true, to indicate that the
browsing context has been discarded.
We only want to flush the event loop of windows that exist, and so we
return early from interaction.flushEventLoop if the window has been
closed.
MozReview-Commit-ID: LtTHQRudKvk
--HG--
extra : rebase_source : e4133ddeed9e89e38fba6e9b8f17544a3546f7eb
We want to take shadow DOM into account when getting an element's
pointer-interactable paint tree.
Marionette is currently unable to determine if an element inside a shadow
DOM host is disconnected from the document because we are constructing
the frame container with only the main document.
MozReview-Commit-ID: IPDi8fQZYRP
--HG--
extra : rebase_source : 8c6757a032342aa6bbe50ef15025a37ac09ae413
Injected script in the Marionette caret selection API used the "default"
immutable sandbox, but we want to run them in the mutable sandbox.
MozReview-Commit-ID: BpbHdDhDtg4
--HG--
extra : rebase_source : 2b710ca483f1732d91527820006da5da331b5df3
Testing the return value is misleading in this case. What we want to
test is that it does not throw due to a permissions issue.
MozReview-Commit-ID: 2Wbwou9opyF
--HG--
extra : rebase_source : 2731ddce0efcd705880a70d69ee934571a766b9a
The Components.classes constructor should throw an error in both the
mutable and the "default" sandbox.
MozReview-Commit-ID: C40nZNaVWwz
--HG--
extra : rebase_source : 81ecde684967241de5fed8f61dd1c0d69d077cfb
We accidentally only ran them in "default" and "system" before, and also
one of the arguments in the system globals test was wrong.
MozReview-Commit-ID: DmBYGsZaIVP
--HG--
extra : rebase_source : 25f72fca677a44079d727e5ff3fa147e3e28eb6e
We were previously missing a test for the arguments variable that is
implicitly exposed to functions.
MozReview-Commit-ID: IC6aJcUsyhd
--HG--
extra : rebase_source : 7aeb986bb4c299ef5996f7b2847e6cc2d878459f
The Python standard library uses tuples to define arguments for functions,
whenever they are invoked through meta programming.
The Marionette client only allows the list type for backwards
compatibility, so we prefer tuples in this case.
Another good argument for tuples is that tuples are immutable.
MozReview-Commit-ID: 72zPzYvBz7Q
--HG--
extra : rebase_source : 79315dd809e00c4c805bd0de3244b519e3ff286f
Marionette does not protect the unloadHandler in
testing/marionette/evaluate.js from content introspection or
modification, which can happen when web frameworks override
window.addEventListener/window.removeEventListener.
The script evaluation module used in Marionette relies on
sandbox.window.addEventListener/removeEventListener to throw an error when
script execution is aborted due to the document unloading itself. If the
window.addEventListener/removeEventListener functions have been overridden
to introspect the objects that are passed, they may inadvertently touch
objects originating from chrome space, such as the unloadHandler.
Because the Gecko sandboxing system put in place strict security measures
to prevent accidental chrome-space modification from content, inspecting
the unloadHandler will throw a permission denied error once the script
has finished executing.
We have found examples in the wild of this in particular with the Angular
web framework. This patch makes the unloadHandler safe for introspection
from web content.
Fixes: https://github.com/mozilla/geckodriver/issues/515
MozReview-Commit-ID: E2LgPhLLuDT
--HG--
extra : rebase_source : 9948585b4ac2f464a9f31868bfd2d5967e61755e
DevTools is about to move out of mozilla-central and be released as an add-on.
So that these protocol files are going to be missing from the tree.
To accommodate that, we are doing a copy of them next to marionette.
MozReview-Commit-ID: 9PyhuwyZyXI
--HG--
extra : rebase_source : b6d96ae5e4c4ac837713e396ab72163b168871f2
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
Previously, replace() and toggle() would not always remove duplicates
and whitespace from the DOM attribute in the case where they were no-ops
(replacing a nonexistent token, force-toggling a token to its current
state). Now they do. This matches the behavior of add() and remove(),
and also replace() in one case (replacing an existing token with
itself).
This follows a spec change: https://github.com/whatwg/dom/pull/444
MozReview-Commit-ID: 7lDEQxOGxPV
--HG--
extra : rebase_source : 842ff24c46681649affcedcba2623128fc6f5a7b
Blink, WebKit, and Edge already support these, and they're in the spec.
Tests submitted to wpt upstream.
MozReview-Commit-ID: 5NFBeClNN7y
--HG--
extra : rebase_source : ea073639904e1ae9449990827ad32626aa6267d9
If the click command triggered a page load, it should not return before
the page has been fully loaded. With this patch we allow an opt-in for
commands to make use of an unload check. It's set to 200ms right now, and
will cancel an ongoing waitForPageLoad() if no page activity is detected.
MozReview-Commit-ID: DWV53sckBS2
--HG--
extra : rebase_source : 455e252e85c14b4ca841f02794bf0d33133ef10a
Tests for page timeout durations have to use an HTTPD handler that delays
or slows down document load. Otherwise there a risk that the timeout error
is not returned before the document finishes loading.
MozReview-Commit-ID: HGGcXfCuaSH
--HG--
extra : rebase_source : c79b01ca4e56e21877c6fe94309b7b0424d9b552
In the case when the trigger callback inside navigate() uses a generator,
the code has to be synchronized and needs to wait until the contained
command has been completed.
MozReview-Commit-ID: 8qKUMvH7HpS
--HG--
extra : rebase_source : 19a87058d62088701914ab2a468ddffaecec1fe2
In the case of switching to an in-process frame, the checkLoad timer
is setup which waits for the frame's content to finish loading.
But the command doesn't actually wait for those events and calls
sendResponse() immediately. This causes a race condition for the
following commands.
MozReview-Commit-ID: 6vuQ7paQ55K
--HG--
extra : rebase_source : ceb590f435d84ead4eba2e718e1ebaa01900d33f
Wes Kocher
Henrik Skupin
Sebastian Hengst
Andrew Swan
Mantaroh Yoshinaga
Ben Hearsum
Jeremy Chen
Greg Mierzwinski
Joel Maher
Gregory Szorc
Aryeh Gregor
Ben Kelly
Carsten "Tomcat" Book
Shing Lyu
Dragana Damjanovic
Andreas Tolfsen
Alexandre Poirot
Chris Pearce
Iris Hsiao
Jared Wein
Andrea Marchesini
Phil Ringnalda
Mike Conley
Emilio Cobos Álvarez
Blake Kaplan
Chris Manchester
Andrew McCreight