TimedPromise logs a warning if the timeout exceeded and not error
should be raised. Given that Sleep always runs into that condition
a lot of inappropriate log entries are made that also causes
confusion for our users when commands (especially actions) don't
work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D89354
TimedPromise logs a warning if the timeout exceeded and not error
should be raised. Given that Sleep always runs into that condition
a lot of inappropriate log entries are made that also causes
confusion for our users when commands (especially actions) don't
work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D89354
There is a race condition in the "WebDriver:SwitchToWindow" command
that would throw an UnknownError instead of NoSuchWindowError when
the window gets closed at the same time as the command gets called.
Differential Revision: https://phabricator.services.mozilla.com/D89377
Fixes a regression from bug 1661495, which missed to reset the
current content browsing context if the new chrome window isn't
a browser window.
Depends on D88827
Differential Revision: https://phabricator.services.mozilla.com/D88900
If a navigation in the current browser causes a remoteness change,
the current content browsing context needs to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D88827
Since the patch on bug 1652932 landed in Firefox 80 we always
update the current content browsing context and that now only
when switching to a new window. That leads to an unexpected
change of the current window handle, and as such breaks tests.
Differential Revision: https://phabricator.services.mozilla.com/D88771
During scrolling, the caret's position relative to the
custom-content-container (cached in mImaginaryCaretRectInContainerFrame)
may not change, but its position relative to root frame can (cached in
mImaginaryCaretRect).
We need to update mImaginaryCaret each time we are in SetPosition().
Otherwise, the caret still remembers its pre-scrolling old position next
time when we drag it, resulting the caret jumping to its old
pre-scrolling position suddenly.
Note this bug only occurs on the root scroll frame where the APZ is
enabled, not in any sub-scroll frames where APZ is disable when the
caret is shown.
Differential Revision: https://phabricator.services.mozilla.com/D88638
If a navigation in the current browser causes a remoteness change,
the current content browsing context needs to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D88827
Since the patch on bug 1652932 landed in Firefox 80 we always
update the current content browsing context and that now only
when switching to a new window. That leads to an unexpected
change of the current window handle, and as such breaks tests.
Differential Revision: https://phabricator.services.mozilla.com/D88771
With the changes on bug 1654628 we do not completely track the current
browsing contexts, but loose the reference when windows are closed.
With this patch the appropriate browsing contexts will be correctly
reset.
Also the commands for switching frames are operating on content
windows and as such are not allowed to update the currently
selected chrome browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D88441
GeckoView allows only a single tab. But that shouldn't prevent the
code to make use of switchToTab() as long as the target tab is
the currently selected one.
Also reftests currently override window.gBrowser which leads to a
wrong detection of Firefox instead of GeckoView. Checking for
Android first will workaround the problem for now.
Differential Revision: https://phabricator.services.mozilla.com/D88467
It should be possible to get the browsing context not only for the
currently selected context (chrome vs. content), but also for a
specific one.
Differential Revision: https://phabricator.services.mozilla.com/D88439
Reftests are running inside a custom browser element, which basically is
reflected as content context in Marionette. And given that some commands
like "WebDriver:GetCurrentURL" rely on the correct context to be set,
wrong data would be returned.
To allow that all commands are working based on the custom browser element
don't enforce chrome context for the Reftests code in Marionette.
This change also fixes the code which counts the assertions as seen for
debug builds. Until now only assertions from chrome context have been
collected.
Differential Revision: https://phabricator.services.mozilla.com/D88408
Without waiting for the initial navigation to "about:blank" to
complete, there is a risk for a race condition given that the
navigation to the test URL happens immediately.
Differential Revision: https://phabricator.services.mozilla.com/D86967
When the first test URL is "about:blank" the reftest window
needs to refresh its location and not trigger a new navigation,
which would lead to no page load events.
By correctly initializing the lastURL property, "loadTestURL"
will be able to determine the correct loading mechanism to use,
and not always trigger a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D86966
To prevent performance degration and extra memory usage in Firefox
for newly spawned content processes, only load external modules if
required in both the parent and child actor.
Differential Revision: https://phabricator.services.mozilla.com/D88138
Without waiting for the initial navigation to "about:blank" to
complete, there is a risk for a race condition given that the
navigation to the test URL happens immediately.
Differential Revision: https://phabricator.services.mozilla.com/D86967
When the first test URL is "about:blank" the reftest window
needs to refresh its location and not trigger a new navigation,
which would lead to no page load events.
By correctly initializing the lastURL property, "loadTestURL"
will be able to determine the correct loading mechanism to use,
and not always trigger a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D86966
By moving out the "currentURI" getter from the Browser class,
and making it available on the driver other parts of Marionette
like reftests can make use of the "currentURL" property.
Also a couple of methods expressed the passed-around data as
instance of nsIURI whereby it was a string or an instance of
URL. The patch fixes that to always pass-around URL instances.
By doing these changes the command will be Fission compatible now.
Differential Revision: https://phabricator.services.mozilla.com/D87572
They're enabled in all configurations and there's no plan to change
this. With it, dom.experimental_forms is also useless, so we can remove
it too.
Differential Revision: https://phabricator.services.mozilla.com/D87623
With this patch a couple of changes are made to generally make it easier
to handle browsing contexts, and the current window. Basically this includes:
Since bug 1652932 landed the driver class keeps a reference
to the currently selected browsing context in content. As such
there is no need anymore to retrieve it from the framescript
each and every time. As side-effect this also removes the
async requirement and makes code better to read.
Similar handling for the browsing context exists for chrome scope,
which is also cached now, and no longer has to be retrieved via
the current window. With specifically this change "getCurrentURL"
for chrome scope correctly reports the location of the top-browsing
context, and not from the current one.
In the early days of Marionette a feature has been added to
work with embedded xul:browser elements. Those elemenets outside
of the tab browser have been tracked with "curFrame". Given that
until now there wasn't a single case to handle that, and the
code path is basically untested, it will be removed for now.
Differential Revision: https://phabricator.services.mozilla.com/D84707
It's not only Firefox that should be able to resize / move the window, but also Thunderbird on desktop.
Further all GeckoView based applications on Android, which claim themselves as 'Firefox', should not be allowed.
Differential Revision: https://phabricator.services.mozilla.com/D86956
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development.
Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074.
Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly.
Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D86255
While implementing support for JSWindowActor classes in Marionette most of the commands operating in content scope and requiring references to elements won't work because running the actor and the framescript in parallel would result in different element id's. As such one or the other code path won't be able to find the referenced element.
That means we have to hide the actor implementation behind the `marionette.actors.enabled` preference. By default it's false. Once all commands work we could enable it for all Fission related tasks in CI, and then for everyone.
Differential Revision: https://phabricator.services.mozilla.com/D84479
Henrik Skupin
Bogdan Tara
Narcis Beleuzu
Ting-Yu Lin
Anny Gakhokidze
Razvan Maries
Emilio Cobos Álvarez
Sonia Singla
Gabriele Svelto
Kris Maglione
Ricky Stewart
Butkovits Atila