My delegating to the main thread, waiting for the last DOM resize event
to fire, and requesting an animation frame from the ChromeWindow, we
can ensure the window is (more) synchronously resized. This ensures
better reliability when setting a window's dimensions.
All this means we can get rid of the heuristics we use for "waiting
for a window resize" to occur by checking if the outerWidth/outerHeight
has changed. These were obviously bug ridden.
Depends on D8417
Differential Revision: https://phabricator.services.mozilla.com/D8418
--HG--
extra : moz-landing-system : lando
When the ChromeWindow is already in the desired x/y position,
WebDriver:SetWindowRect should act as a no-op. This avoids a
superfluous call to ChromeWindow.moveTo.
Depends on D8416
Differential Revision: https://phabricator.services.mozilla.com/D8417
--HG--
extra : moz-landing-system : lando
win.Maximized does not exist. This should be WindowState.Maximized.
Depends on D8415
Differential Revision: https://phabricator.services.mozilla.com/D8416
--HG--
extra : moz-landing-system : lando
Unlike the visibilitychange event, sizemodechange appears to fire in a
mostly reliable way. However, in the off-chance that sizemodechange
should not fire, we need an escape path so that Marionette returns
within a timely fashion.
Depends on D8414
Differential Revision: https://phabricator.services.mozilla.com/D8415
--HG--
extra : moz-landing-system : lando
The visibilitychange DOM event does not fire reliably in all
configurations when retrieved from web content. It appears to fire more
reliably in chrome, but to ensure a call to WebDriver:MinimizeWindow
never hangs, we additionally change it to be a TimedPromise.
There is an assumption here that if the iconification process does
not complete within this duration, there is nothing we can do.
Depends on D8413
Differential Revision: https://phabricator.services.mozilla.com/D8414
--HG--
extra : moz-landing-system : lando
Instead of waiting for the visibilitychange event to fire, which does
not work in headless mode, we can poll ChromeWindow.windowState which
appears to be a more reliable way of telling the window's current state.
This will resolve the problem where Marionette never returns from
restoration due to visibilitychange never firing, and will additionally
make it more reliable.
Depends on D8412
Differential Revision: https://phabricator.services.mozilla.com/D8413
--HG--
extra : moz-landing-system : lando
This adds a new synchronisation primitive to Marionette which will
allow us to wait for the last in a sequence of events to fire.
This is especially useful for high-frequency events such as the DOM
resize event, where multiple resize events may fire as the window
dimensions are being changed.
Depends on D8411
Differential Revision: https://phabricator.services.mozilla.com/D8412
--HG--
extra : moz-landing-system : lando
On some systems and window managers, such as macOS and when X11
forwarding an application across systems, there exists a 22px
window border that we cannot detect or do anything about. As this
test is to verify that the width/height changed beyond 800x600,
this assertion change should make the tests pass on more configurations.
Depends on D8409
Differential Revision: https://phabricator.services.mozilla.com/D8410
--HG--
extra : moz-landing-system : lando
Quering the stored devices list for an ID was not always correct. The stored devices list is expected to be empty before an enumeration takes place or after a collection change notification. In those cases, the method will fail to find an existing ID. The method has been updated to address these cases in previous patch. Here I have implemented a unit test to verify the case. Currently, the method is not being used.
Differential Revision: https://phabricator.services.mozilla.com/D9380
--HG--
extra : moz-landing-system : lando
Although this two receivers are guarded by checks for if they were initialized
(and so registered) there are reports of crashes because of trying to unregister
them without them actually being registered.
The underlying issue will be investigated further in bug 1505685 but for the
moment wrapping the unregister operations in a try-catch saves the users from
a crash and because the unregister is done when the app is closed
(for the MmaDelegate receiver) or when the app finished playing media
(for the GeckoMediaControlAgent receiver) the user doesn't loose any
functionality going forward.
Differential Revision: https://phabricator.services.mozilla.com/D11177
--HG--
extra : moz-landing-system : lando
Add GeckoView Media API which provides a way to listen to HTMLMediaElement events in a GeckoSession and control the playback externally
Differential Revision: https://phabricator.services.mozilla.com/D9026
--HG--
extra : moz-landing-system : lando
Now all targets are considered as remote, so isRemote attribute is misleading.
Remote means that we are going through the RDP protocol to debug the target
and we now always do. If some callsite wants to do something special for local tabs
it is better to read target.isLocalTab attribute.
MozReview-Commit-ID: IYlj0wO02PO
Differential Revision: https://phabricator.services.mozilla.com/D11009
--HG--
extra : moz-landing-system : lando
Made IsTableCell() only check the generic type, not the ARIA map entry that gets checked in HasGenericType. This prevents the crash and also fixes IsTableCell() and AsTableCell() not being in sync.
Differential Revision: https://phabricator.services.mozilla.com/D10713
--HG--
extra : moz-landing-system : lando
Previously, we would always hard-code the basis-start and final-start line names first in
the grid column template used to display the minimap.
Because there may be cases where base+delta is actually negative, we cannot do that anymore.
This fixes that by removing this hard-coding and sorting the entire array of sizes before
generating the grid column template.
The test that I added is only a few lines, but to make it simpler to write, I had to
merge doc_flexbox_simple.html and doc_flexbox_specific_cases.html, which is why you are
seeing several test changed here.
Also, to make sure the test case I added would behave the same across platforms, I used the
Ahem font, which is often use in Layout tests as it only has 1 glyph that's exactly the size
of the font-size.
Differential Revision: https://phabricator.services.mozilla.com/D11175
--HG--
extra : moz-landing-system : lando
This creates 32-bits variants of the same packages that were added for
64-bits builds, with a few additions:
- python-defaults, so that the python package can be installed as a
dependency of the libglib2.0-dev package,
- xkeyboard-config, so that the xkb-data package can be installed as a
dependency of the libxkbcommon0 package.
Additionally, because the 32-bits and 64-bits packages are built
separately (the 32-bits packages can't, on Wheezy, be built on a 64-bits
host), they don't end up with the same
changelog.Debian/changelog.Debian.gz file because of a timestamp within
it. One way to address this would be to make the taskgraph more complex,
by adding a task creating the source package, and then two tasks
building the 32-bits and 64-bits binary packages from that source, but
that's not worth the overhead, when a simple hack works around the
problem: We make dpkg skip installing the changelog.Debian* files.
Differential Revision: https://phabricator.services.mozilla.com/D11140
We're going to bump our shipped builds to build against Gtk+ 3.10, but
still want to ensure we can still build against Gtk+ 3.4. As we're using
Gtk+ packages installed in the build docker image, we need to have a
separate image where the Gtk+ packages are kept at version 3.4.
Differential Revision: https://phabricator.services.mozilla.com/D11137
I suspect that the root cause of bug 1502182 is that we try open a database
connection before the old one is fully closed. Instead of dealing with
complicatedasync bookkeeping to make sure this doesn't happen, this patch
simply never closes the database connection. I don't think any of the
benefits of closing IndexedDB databases apply to Normandy, and it isn't
a significant cost to simply keep them open.
Additionally, the patch distinguishes between readonly and readwrite
transactions with the database. This was originally done to try and fix
the bug. When it didn't help, I decided to leave the change in because
it is a beneficial change anyways.
Differential Revision: https://phabricator.services.mozilla.com/D10629
--HG--
extra : moz-landing-system : lando