The previous approach of using space characters would sometimes end up causing spaces to get saved in storage and cause data loss.
Differential Revision: https://phabricator.services.mozilla.com/D46663
--HG--
extra : moz-landing-system : lando
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
Currently, we can use chrome process's shortcut key with
`EventUtils.synthesizeKey()` with enabling `"test.events.async.enabled"` pref.
So, we should reconvert it to a mochitest for making it more stable.
Oddly, when I try to run this test as test-verify on macOS, it permanently
fails rendering resizer of `<textarea>` elements immediately after creation.
Therefore, this patch disables this test in test-verify on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D46578
--HG--
rename : editor/libeditor/tests/browser_bug629172.js => editor/libeditor/tests/test_bug629172.html
extra : moz-landing-system : lando
It will generate a warning and is useless as explained in the code comment.
Differential Revision: https://phabricator.services.mozilla.com/D46626
--HG--
extra : moz-landing-system : lando
The inspector was using an outdated Reps bundle
for some time because some non-trivial changed
were made to the ObjectInspector that we wanted
to do as a follow up for in the inspector, but never
took the time to do so.
This will become a painpoint soon as we're planning
to do changes in reps for Fission.
This patch removes the old bundle, and mov the
inspector usage of Reps to the new bundle.
We introduce a new middleware, thunk-with-options,
that is similar to thunk but cab be bound with an
options object (on which we add dispatch and getState),
that will be then passed as parameter to the actions.
Since the task middelware is executed before the thunk one,
and given that it handles async function, it would bypass
the thunk-with-action middleware, making some objectInspector
actions fail. To workaround that, we add an option to createStore
to add the ability to disable the task middleware (which isn't
needed in the inspector).
The ObjectInspector reducer is also added to the
inspector store.
Differential Revision: https://phabricator.services.mozilla.com/D46141
--HG--
extra : moz-landing-system : lando
Both of these files obviously use things from the newly-included
headers, but they were not including them prior to this point.
Differential Revision: https://phabricator.services.mozilla.com/D46632
--HG--
extra : moz-landing-system : lando
This replaces the instances where Length was being called on an interval set
to determine if it was empty or not empty. IsEmpty makes the intention in these
cases more immediately obvious, and avoids the need to think about ints as
bools in cases like `if(!mySet.Length())`.
Depends on D46638
Differential Revision: https://phabricator.services.mozilla.com/D46639
--HG--
extra : moz-landing-system : lando
Restyle include guard + includes to conform to new style rules.
Depends on D46637
Differential Revision: https://phabricator.services.mozilla.com/D46638
--HG--
extra : moz-landing-system : lando
This is a quality of life improvement:
- More concise than checking if Length() == 0.
- More readable then if(mySet.Length()) (in my opinion).
- We already have checks that test if IntervalSets are empty by looking at their
length, so there is a use case for this.
Differential Revision: https://phabricator.services.mozilla.com/D46637
--HG--
extra : moz-landing-system : lando
Note that to avoid introducing errors, I elected against renaming everything in
the code; internally to Firefox the code still refers to "UntrustedModules";
only the relevant fields have been renamed to reference the new ping schema.
A PR for backend schema changes is in the works.
Differential Revision: https://phabricator.services.mozilla.com/D43162
--HG--
rename : toolkit/components/telemetry/docs/data/untrusted-modules-ping.rst => toolkit/components/telemetry/docs/data/third-party-modules-ping.rst
rename : toolkit/components/telemetry/tests/unit/test_UntrustedModulesPing.js => toolkit/components/telemetry/tests/unit/test_ThirdPartyModulesPing.js
extra : moz-landing-system : lando
Untrusted modules 2.0 uses MFBT `Vector`, so this patch adds the ability for
`ProcessedStack` to receive those as input.
Differential Revision: https://phabricator.services.mozilla.com/D43161
--HG--
extra : moz-landing-system : lando
* Significant cleanup to `ModuleEvaluator`
* `UntrustedModuleData` holds all of the accumulated untrusted module info for
a single process.
* `ProcessedModuleLoadEvent` holds information about an individual untrusted
module load in a Gecko-friendly, sanitized, format.
* Since multiple `ProcessModuleLoadEvent` objects may reference the same
module, we store module metadata in a shared `ModuleInfo` structure.
* The `UntrustedModulesProcessor` receives the events from `mozglue` and
processes them on a background thread:
** It does not start background processing until the main thread has gone idle.
The idea here is that we do not want to add any more background work until
we are reasonably confident that Gecko is no longer starting up or doing
other intense activity.
** Background processing runs at a background priority level, *except* when
results are requested by telemetry itself.
** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData`
which runs at normal priority and returns a promise to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D43160
--HG--
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h
rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp
rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h
extra : moz-landing-system : lando
The `const` qualifier on `mVersion` was preventing move and copy, which we
now need this class to support.
Differential Revision: https://phabricator.services.mozilla.com/D43159
--HG--
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
* We refactor the blocklist code. Code that may possibly run before
initialization of the Win32 subsystem and the CRT is contained within the
`freestanding` library.
* The `freestanding` library's static initializers are placed in their own
section so that they may be manually invoked separately from the remaining
initializers in the binary.
* `CheckBlockInfo` and `IsDllAllowed` are modified to return a `BlockAction`
enum instead of a `bool`. This will be used more extensively in the future for
LSP blocking.
* The launcher process now hooks `LdrLoadDll` in addition to
`NtMapViewOfSection`. This is necessary so that we can collect timing
information.
* Telemetry recorders must implement the `LoaderObserver` interface.
* `ModuleLoadFrame` is a RAII class that collects the information about the
DLL load and dispatches the information to `LoaderObserver`s.
* The launcher process exposes an implementation of the `LoaderAPI` interface
that may be called by either the launcher process blocklist or the legacy
blocklist in `mozglue`.
* During startup, the launcher process implements its own `LoaderObserver`.
Once mozglue is running, it connects its `LoaderObserver` to the launcher
process, receives a vector containing the module load events, and then
stores and forwards them into XUL.
Differential Revision: https://phabricator.services.mozilla.com/D43156
--HG--
rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/DllBlocklistInit.cpp
rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/DllBlocklistInit.h
rename : browser/app/winlauncher/DllBlocklistWin.cpp => browser/app/winlauncher/freestanding/DllBlocklist.cpp
rename : browser/app/winlauncher/DllBlocklistWin.h => browser/app/winlauncher/freestanding/DllBlocklist.h
rename : browser/app/winlauncher/moz.build => browser/app/winlauncher/freestanding/moz.build
extra : moz-landing-system : lando
This patch adds the following:
* The `AllocatedUnicodeString` class which encapsulates a `UNICODE_STRING` and
owns its buffer. The buffers are null-terminated so that they may be used as
C-style strings without modification.
** We do not allow either creation or copying within XUL
* `RtlGetCurrentThreadId` and a test to validate it, so that we may obtain the
current thread ID directly from the `TEB` when we do not yet have access to
kernel32.
* An implementation of `SRWLock` that uses Rtl instead of Win32 so that we may
use them before we have access to Win32 DLLs.
* A memory allocation policy that uses Rtl heap functions so that we may use
MFBT `Vector` in code that might not yet have access to Win32 heap functions.
Differential Revision: https://phabricator.services.mozilla.com/D43155
--HG--
extra : moz-landing-system : lando
As part of compiling C/C++ to wasm, we're going to need a wasm-specific
sysroot to be provided. This option enables us to specify that sysroot
during configure.
Differential Revision: https://phabricator.services.mozilla.com/D46314
--HG--
extra : moz-landing-system : lando
This patch duplicates the configuration work done in D43710, but this
path enables better extension to other libraries and a better foundation
to build on for future build system changes.
Differential Revision: https://phabricator.services.mozilla.com/D46312
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
Set a trivial duration (1us) on 0 duration samples before feeding them to the
WMF MFT decoder to prevent it from estimating the duration for such samples.
Differential Revision: https://phabricator.services.mozilla.com/D46516
--HG--
extra : moz-landing-system : lando
This is a back out of changeset c52127007a01, i.e. reverts bug 1560440. That bug
was itself reverting a prior bug where we started setting the duration.
There are two scenarios involved, each with their own issues:
- We don't set the duration when feeding the decoder (what we're doing prior to
this change). In this case the decoder will estimate durations for all
samples. This works in many cases, but leads to issues with files that have
non-uniform durations - as seen in bug 1576990 (this bug).
- We do set the duration when feeding the decoder (what will happen after this
change). In this case the decoder will not estimate durations, except it still
seems to do so when fed 0 duration samples. Since our demuxing pipeline can
create 0 duration samples, this leads to issues with such files (as seen in
bug 1560440).
This patch fixes the former of the above, and the next patch in the chain will
address the latter.
Differential Revision: https://phabricator.services.mozilla.com/D46515
--HG--
extra : moz-landing-system : lando
`image-short.png` never exists in the first place when this test was
introduced, so the intermittent happens when the test file shows a
broken image icon and the reference file without, or the other way
around.
I believe the `<img>` is served as a monolithic element to overflow
`<div class="short">`. Use an empty src should suffice.
Differential Revision: https://phabricator.services.mozilla.com/D46640
--HG--
extra : moz-landing-system : lando
Trying to access `about:config` will fail even before the page has started loading so we don't get the usual flow.
For a normal page (that fails to load) it is:
- OnLoadRequest
- OnPageStart
- OnLoadError
- OnPageStop
but for about:config it's just
- OnLoadRequest
- OnLoadError
So we just wait for the OnLoadError message instead.
Differential Revision: https://phabricator.services.mozilla.com/D46369
--HG--
extra : moz-landing-system : lando
