That was redundant with the manifest being added with MT (although useful
for mingw builds, that don't use MT), but is also now handled by the
automatic creation of rc files.
Differential Revision: https://phabricator.services.mozilla.com/D86156
We are currently relying on two different ways to insert side-by-side
manifests in binaries on Windows: through resource files, or through
the use of MT. The latter is not supported on mingw builds, which is
not great.
Link.exe has options to add a manifest at link time without relying on
either method above, but that's not supported on mingw either.
So the best we can do is to move everything to using resource files.
This also avoids using MT, which, on cross builds, requires using wine.
Ideally, the manifests would be declared in moz.build, but that
complicates things for cases like TestDllInterceptor, where there are
multiple binaries in the same directory, but only one of them needs the
manifest. This keeps the status quo of getting the manifest
automatically from the source directory.
Differential Revision: https://phabricator.services.mozilla.com/D85382
We're currently not using the feature, and host programs ought only
to be used during the build, so I don't expect the feature to ever
be necessary.
Differential Revision: https://phabricator.services.mozilla.com/D86167
The resource file is always generated so being able to configure its name
is not useful. On the other hand, the way things are currently implemented,
the lack of RESFILE also makes RCFILE ignored, which we fix at the same
time.
And remove a spurious RESFILE in widget/windows/moz.build, where no binary
is produced, which means RESFILE had no meaning.
Differential Revision: https://phabricator.services.mozilla.com/D86154
Because while the original perl script was added to add version info
to Windows binaries, it does more and will do even more with upcoming
changes.
Differential Revision: https://phabricator.services.mozilla.com/D86153
RCFILE is only actually used when the moz.build that contains it defines
a binary, which is not the case for dav1d, which ends up in gkmedias.dll.
Which also means that moving the definition to gkmedias would also not
make sense, since all dav1d.rc does is add descriptors to the dll that it
contains dav1d and what version, but gkmedias.dll contains other things
too.
Differential Revision: https://phabricator.services.mozilla.com/D86152
It was only ever set to the same value as its default, except in
comm-central, where it is unset, but in directories that now don't link
anything (they did back when binary components were a thing).
Differential Revision: https://phabricator.services.mozilla.com/D85381
`scrollbar-no-margin.html` is adapted from `scrollbar.html` with margin
removed from flex-items, to workaround bug 1527539.
`font-size: 0` added to `.flex` is to workaround bug 1302700. Also,
adjust `scrollbar-width` and `scrollbar-color` to avoid fuzzy rendering
on rounded-corner slider on some platforms.
Differential Revision: https://phabricator.services.mozilla.com/D86079
The backwards compatibility checks existed to support devtools
backend for version older than FF79. Now that FF79 has hit the
release channel, these tests for older backend can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D86142
We want this to be turned on for nightly users by default. The page range is still a WIP,
so we should hide that section for now.
This also adds the pref to the "Nightly Experiment" panel, turned on by default.
Differential Revision: https://phabricator.services.mozilla.com/D85907
This can cause the URL preloader to think that initialization has succeeded
when it hasn't. This add observer call can fail if we're late in shutdown,
because the observer service still exists, but it isn't taking new
observers. I'm not sure how much it matters that we're failing to listen for
an observer that can't possibly fire at this stage, but a failure to check
for this seems to have contributed to the crash in bug 1656973, so we
might as well just fail.
Differential Revision: https://phabricator.services.mozilla.com/D86031
Some of the entry points into the URL preloader check sInitialized, and only
use it if it is true. However, if we're late in shutdown and we've already
cleared the singleton for the preloader then our failure to clear the
sInitialized flag means we'll recreate the preloader, which is going
to fail in various ways.
I think this won't help in the case of bug 1656973, because that seems
to go through AutoBeginReading, which unconditionally creates a new
singleton if one does not exist.
Differential Revision: https://phabricator.services.mozilla.com/D86030
I don't think this will fully resolve the shutdown hangs associated
with this bug. The underlying problem is that writing the startup
cache during shutdown can take a long time. This seems like A Bad Thing,
and I have a mild leaning toward the thought that we shouldn't write the
startup cache at all during shutdown. However, I do think that trading
shutdown time regressions for startup time wins is probably good, so
I don't feel super comfortable making that change.
However, this change at least fixes the problem where we A) block the main
thread waiting for the write to finish, and B) are more likely to hit a
shutdown hang, since we concentrate all of the hang time in one phase,
rather than it being spread across the shutdown timeline. This is likely
the major change that the regressing bug introduced.
The unfortunate consequence is that if we try to GetBuffer during shutdown,
we will now read out of the omnijar. However, it should overall be better
since we'll be waiting on a (hopefully) small number of small reads rather
than a large write.
Differential Revision: https://phabricator.services.mozilla.com/D86054