This establishes a high water mark for code loaded (even after a short
delay) by a background task that does nothing.
Code loaded here means:
1) Chrome JSMs imported using `ChromeUtils.import`;
2) XPCOM services, generally long-lived, loaded using `do_getService`
or `Services.*` or an equivalent;
3) XPCOM components defined in JavaScript and loaded via
`chrome.manifest` entries.
At this time background tasks do not load any of category 3. The
distinction is made because they are reported separately by Gecko.
This test is browser-chrome to make it easy/possible to work with
packaged builds.
Differential Revision: https://phabricator.services.mozilla.com/D98095
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
This establishes a high water mark for code loaded (even after a short
delay) by a background task that does nothing.
Code loaded here means:
1) Chrome JSMs imported using `ChromeUtils.import`;
2) XPCOM services, generally long-lived, loaded using `do_getService`
or `Services.*` or an equivalent;
3) XPCOM components defined in JavaScript and loaded via
`chrome.manifest` entries.
At this time background tasks do not load any of category 3. The
distinction is made because they are reported separately by Gecko.
This test is browser-chrome to make it easy/possible to work with
packaged builds.
Differential Revision: https://phabricator.services.mozilla.com/D98095
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
In GTest of the CCov build, UntrustedModulesFixture test detected the following
modules which were loaded by the TestDllBlocklist.* tests in the same process.
- TestDllBlocklist_MatchByName.dll
- TestDllBlocklist_MatchByVersion.dll
- TestDllBlocklist_NoOpEntryPoint.dll
Since they are loaded in a different thread from the one running
UntrustedModulesFixture and are blocked/redirected by our blocklist,
UntrustedModulesFixture needs to verify its loading result differently.
This patch defines an array of the expected results of these modules.
Differential Revision: https://phabricator.services.mozilla.com/D103073
This is, for the most part, just a large refactor of the skeleton UI stuff to
support coarse-grained error reporting via telemetry. There are a few slight
changes in how we handle some errors. For example, if CreateWindow fails, we
will now bail out and report the failure. The flow for the happy path, however,
should remain unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D102098
This establishes a high water mark for code loaded (even after a short
delay) by a background task that does nothing.
Code loaded here means:
1) Chrome JSMs imported using `ChromeUtils.import`;
2) XPCOM services, generally long-lived, loaded using `do_getService`
or `Services.*` or an equivalent;
3) XPCOM components defined in JavaScript and loaded via
`chrome.manifest` entries.
At this time background tasks do not load any of category 3. The
distinction is made because they are reported separately by Gecko.
This test is browser-chrome to make it easy/possible to work with
packaged builds.
Differential Revision: https://phabricator.services.mozilla.com/D98095
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
This patch adds a new field "loadStatus" to the third-party-modules ping,
which derives from `ProcessedModuleLoadEvent::mLoadStatus` introduced by
the earlier patch.
Differential Revision: https://phabricator.services.mozilla.com/D102408
We used to record a DLL loading event only when a module was loaded.
With this patch, we record an event for a module blocked by our DLL
blocklist as well as a loaded module. It is achieved by calling
to `ModuleLoadFrame::NotifySectionMap` in `patched_NtMapViewOfSection`
regardless of the block action.
This patch introduces a new member `ModuleLoadInfo::mStatus` and
`ProcessedModuleLoadEvent::mLoadStatus` to keep the DLL loading status,
which will be added to the third-party-modules ping by a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D102407
This patch adds a new field "loadStatus" to the third-party-modules ping,
which derives from `ProcessedModuleLoadEvent::mLoadStatus` introduced by
the earlier patch.
Depends on D102407
Differential Revision: https://phabricator.services.mozilla.com/D102408
We used to record a DLL loading event only when a module was loaded.
With this patch, we record an event for a module blocked by our DLL
blocklist as well as a loaded module. It is achieved by calling
to `ModuleLoadFrame::NotifySectionMap` in `patched_NtMapViewOfSection`
regardless of the block action.
This patch introduces a new member `ModuleLoadInfo::mStatus` and
`ProcessedModuleLoadEvent::mLoadStatus` to keep the DLL loading status,
which will be added to the third-party-modules ping by a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D102407
On Wayland we don't have a specified order of screens. However,
in order to match intuitive expectations and X11 behavior more, order
the reported screen by their Wayland ID, showing them in order as
reported by the Wayland compositor.
Differential Revision: https://phabricator.services.mozilla.com/D102187
Fetch the DRM device in the EGL version of glxtest, set it in gfxInfo and pass
it to gfxVars. Finally, use it in nsDMABufDevice::Configure().
While on it, also clean up EGL typedefs and defines a bit to match how it's
done for GLX.
Inspired by and copied from wlroots and Xwayland. Thanks to emersion!
Differential Revision: https://phabricator.services.mozilla.com/D98108
Fetch the DRM device in the EGL version of glxtest, set it in gfxInfo and pass
it to gfxVars. Finally, use it in nsDMABufDevice::Configure().
While on it, also clean up EGL typedefs and defines a bit to match how it's
done for GLX.
Inspired by and copied from wlroots and Xwayland. Thanks to emersion!
Differential Revision: https://phabricator.services.mozilla.com/D98108
Fetch the DRM device in the EGL version of glxtest, set it in gfxInfo and pass
it to gfxVars. Finally, use it in nsDMABufDevice::Configure().
While on it, also clean up EGL typedefs and defines a bit to match how it's
done for GLX.
Inspired by and copied from wlroots and Xwayland. Thanks to emersion!
Differential Revision: https://phabricator.services.mozilla.com/D98108
1. On Wayland, use `get_egl_status()` by default
2. On X11/EGL use `x11_egltest()`, avoiding runtime dependencies on GLX
3. Avoid dlopening libgl/libgles on EGL if not needed
4. Some Wayland/X11 `ifdef` cleanups
5. Don't throw warnings when on mesa and using pci device detection
Depends on D101383
Differential Revision: https://phabricator.services.mozilla.com/D100638
Implement `get_wayland_screen_info()` by copying from `weston-info`.
This allows us to get the actual number of screens. Previously, we'd
fall back to using the info from Xwayland, which always reports one
single big screen with the combined size (e.g. 3840x1080 instead of
2x1920x1080). Also, this avoids opening a X11 connection.
Note:
- monitor scale is recorded but not used yet
- the code could be simplified. However, keeping the weston-info
structure would allow us to easily add queries for other extensions
in the future if desired.
Differential Revision: https://phabricator.services.mozilla.com/D101383
This scope will support later functional changes that are conditionally
compiled. This part is standalone to help with blame-tracking.
Differential Revision: https://phabricator.services.mozilla.com/D100805
In GTest, xul.dll is considered untrusted because only the `FirefoxDirectory`
flag of `ModuleTrustFlags` is turned on. In CCov build, however, xul.dll is
considered trusted because the `FirefoxDirectoryAndVersion` flag is also turned
on. In the former case, the `FirefoxDirectoryAndVersion` is not turned on
because when xul.dll is re-built for GTest, its version becomes newer than
firefox.exe. In the CCov build, the version of firefox.exe was also reset
probaly during instrumentation. As a result, the loding event contains a value
in `mXULLoadDurationMS` in CCov build, but normally not.
This fix removes the check for `mXULLoadDurationMS` in GTest.
Differential Revision: https://phabricator.services.mozilla.com/D99564
The method `Telemetry.getUntrustedModuleLoadEvents()` used to move data, meaning
once it was called, the returned data was removed from the application so that
the same data would never be returned again.
To show third-party modules info on about:support, we need to keep data even after
it's submitted as telemetry. At the same time, we need to know which loading events
have been submitted and which have not.
With this patch UntrustedModulesBackupService holds two storages named "Staging"
and "Settled" respectively. To achieve the behavior described earlier, we use
the "Staging" to keep instances not yet submitted, and "Settled" to keep instances
already submitted.
This patch also introduces two flags `INCLUDE_OLD_LOADEVENTS` and
`KEEP_LOADEVENTS_NEW` under `nsITelemetry`, with which the caller of
`getUntrustedModuleLoadEvents()` can control which instances to be returned and
how the returned instances are kept internally.
Differential Revision: https://phabricator.services.mozilla.com/D93829
Nick Alexander
Butkovits Atila
Toshihito Kikuchi
Doug Thayer
Csoregi Natalia
Andrew Osmond
Noemi Erli
Paul Bone
Robert Mader
Mihai Alexandru Michis
Brindusan Cristian
Markus Stange
Kartik Gautam
Brad Werth
Cosmin Sabou
Harsh Gupta
Adam Gashlin
Molly Howell