CompositorD3D11's implementation of `GetWindowRenderTarget` would return a
`nullptr` if we were not presently recording a profile with screenshots. Now,
CompositorD3D11 correctly will return a window render target when it has been
asked to by the `LayerManagerComposite` via `Compositor::RequestRecordFrames`.
Differential Revision: https://phabricator.services.mozilla.com/D29369
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
The button (using a div) did not have any hover state before this patch.
While the CSS tried to control the stroke color, the SVG was not set up
for this – also fixed in this bug to correctly use the theme colors.
Differential Revision: https://phabricator.services.mozilla.com/D24742
--HG--
extra : moz-landing-system : lando
This patch replaces the quick-n-dirty implementation of -force-launcher with
one that makes LauncherRegistryInfo aware of that state, thus correctly setting
the affected registry values.
Differential Revision: https://phabricator.services.mozilla.com/D29545
--HG--
extra : moz-landing-system : lando
* New installs should always have launcher process telemetry enabled by default
(since it is opt-out telemetry).
* Upgrades do a reset of the force-disabled launcher state, as that state might
have been set by SHIELD but is no longer desired in 68.
* We add the `|Telemetry` registry value to the list of values to be removed at
uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D29544
--HG--
extra : moz-landing-system : lando
There's no good reason why we should let unnamed threads through this interface.
Differential Revision: https://phabricator.services.mozilla.com/D29672
--HG--
extra : moz-landing-system : lando
We were incorrectly not performing an EnsureSubscribed for the origin
process which a BrowsingContext came from. Normally this would mean that
the BrowsingContext could die in the parent process before the
WindowGlobalParent listener arrived, but that didn't generally happen
due to the low likelihood of a CC occuring between the two messages.
It's likely that this crash was caused by people on lower-end hardware
triggering a print. This would be a longer-running operation in the
content process between the first and second message than usual. On
systems with memory pressure, there would be a higher chance of a CC
occuring between the messages, which would then cause this crash.
This patch correctly connects the origin ContentParent to the
BrowsingContextGroup, which will prevent the CC from destroying our
objects.
In the future, it may be desirable to ensure that this doesn't happen
more reliably by using a ContentParent-local table for looking up
BrowsingContext IDs sent over IPC. This would prevent our current
dependency on the weak pointer behaviour of the current global ID cache.
Unfortunately, this patch adds no tests, and I'm not aware of a good way
to test this edge case to confirm it has been fixed. I believe that this
patch should fix the issue I mention, however.
Differential Revision: https://phabricator.services.mozilla.com/D29563
--HG--
extra : moz-landing-system : lando
The failures when running the app update tests during TV runs print an activity stream error to the console and this will at the least eliminate it as a cause for the failure and possibly will prevent these tests from failing during TV runs.
Differential Revision: https://phabricator.services.mozilla.com/D29612
--HG--
extra : moz-landing-system : lando
This issue was caused by the updating of the caret position after the paste occurs firing an `updateposition` event resulting in an `GeckoView:ShowSelectionAction` message to reposition context menu without any attempt to close the context menu. The solution is to hide the context menu before the repositioning of the caret occurs such that the `updateposition` event doesn't trigger a redisplay.
I tried several versions of this trying to trigger the menu close from inside `GeckoViewSelectionActionDelegate`, including making the call to `docShell.doCommand("cmd_paste");` asynchronous and firing `ACTION_HIDE` before firing `ACTION_PASTE`, but the result is always the same - one of the events is processed before the other and so the second event is rejected as a stale response.
Therefore we are firing the `pagehide` from inside the code that performs the paste. This has to be done before the paste occurs otherwise the `updateposition` event is fired before the page hide event and the context menu redisplays before being hidden.
Differential Revision: https://phabricator.services.mozilla.com/D29665
--HG--
extra : moz-landing-system : lando
this change comprises the in-tree changes required to make use of sccache in gcp.
specifically:
- a gcp metadata lookup for availability-zone is added to mozconfig, enabling a build to determine its regional gcp sccache bucket
- the sccache cargo build command is modified to include the gcs feature when the environment contains gcs configuration
note that further changes are required on infra to support sccache use. the required changes already [exist](https://github.com/mozilla-releng/OpenCloudConfig/commit/1d515dc) and are enabled for gcp windows infra, including:
- a json credential file on the build instance filesystem, containing credentials valid for the appropriate scm level bucket for the gcp region
- an `SCCACHE_GCS_KEY_PATH` env variable containing the path to the json credential file
- an `SCCACHE_GCS_RW_MODE` env variable containg the text `READ_WRITE`
- sccache buckets must exist for each region and scm levels 1 & 3
- credentials for scm level 1 buckets **must not** be valid for scm level 3 buckets
on gcp systems which do not contain credential files and the above mentioned env variables (eg gecko-[1-3]-b-linux), sccache should fail gracefully without breaking builds.
Differential Revision: https://phabricator.services.mozilla.com/D29622
--HG--
extra : moz-landing-system : lando
Barret Rennie
Josh Matthews
Botond Ballo
Harald Kirschner
Andrea Marchesini
Mathieu Leplatre
Aaron Klotz
Nathan Froyd
Nika Layzell
Robert Strong
yulia
Michael Kaply
Bastien Abadie
Emily Toop
Gian-Carlo Pascutto
Ehsan Akhgari
Valentin Gosu
Emilio Cobos Álvarez
Julian Descottes
Kartikaya Gupta
Mitchell Hentges
Byron Campen [:bwc]
Rob Thijssen
Mark Banner
Jean-Yves Avenard
Thomas Nguyen
ffxbld
shindli
Kershaw Chang
Ivan Yung
Alexandre Poirot
Jonas Allmann
Jan de Mooij
Yura Zenevich