Add CEnum types to XPIDL, allowing for typed enums in C++ instead of
using uintXX_t types. Javascript will still reflect CEnums as
interface level consts.
Depends on D8593
Differential Revision: https://phabricator.services.mozilla.com/D8594
--HG--
extra : moz-landing-system : lando
Sometimes when we call ShutdownWithTimeout on a thread pool, the unresponsive
thread that we leak will actually complete before the main thread is done.
In that case, the thread will dereference the thread shutdown context, so
we must intentionally leak it too.
Differential Revision: https://phabricator.services.mozilla.com/D10645
NsresultExt.to_result() is called by Rust code, so it would be more idiomatic for it to return Result<(), nsresult>, i.e. to return Ok(()) when the nsresult is NS_OK. This change makes it do so.
MozReview-Commit-ID: EaMEKfonHhC
Differential Revision: https://phabricator.services.mozilla.com/D10127
--HG--
extra : moz-landing-system : lando
After bug 1496622, the IDL parser converts some references to `nsresult` in IDL files to `::nserror::nsresult` in IDL-generated Rust files. But it doesn't convert others. It should convert them all consistently, and this patch makes it do so by adding conversion of the return type of attribute getters/setters and references generated by the IDL parser's Typedef class.
MozReview-Commit-ID: 838K8XGjvTx
Differential Revision: https://phabricator.services.mozilla.com/D10121
--HG--
extra : moz-landing-system : lando
This method is necessary because some threads might be stuck making blocking
calls. This means the thread is not processing any events, and we're unable
to safely terminate it. Our solution here is to leak the stuck threads
instead of waiting for them and potentially causing a shutdown hang.
Differential Revision: https://phabricator.services.mozilla.com/D9601
--HG--
extra : moz-landing-system : lando
This bumps the timeout when waiting for reports to 180 seconds which seems to
be long enough for MacOS in automation.
--HG--
extra : rebase_source : 6eb396e53bd37f6640b7c5402fb997c73af40d99
This is kind of like the previous patch (where we had a not-very-friendly user experience shutting down misbehaving h2 sessions), but in this case the server has proven to us that it can speak a minimum of h2, so we don't want to just fallback. Instead, when we send a GOAWAY frame because we have detected some error on the part of the server, if it's a top-level page load, we'll show an error page explaining that the server spoke bad http/2, and the site admin(s) need to be contacted. We already did this for INADEQUATE_SECURITY (which is its own special case still), but that didn't cover all the cases.
Differential Revision: https://phabricator.services.mozilla.com/D8436
--HG--
extra : moz-landing-system : lando
I left GetMethodInfo, GetConstant as they are still useful as separate methods.
Differential Revision: https://phabricator.services.mozilla.com/D9638
--HG--
extra : moz-landing-system : lando
This is needed for bug 1500926. It takes the approach of taking a JSFlatString
and using AutoAssertCannotGC to read the memory directly from the JS heap.
This lets us avoid re-encoding strings when performing lookups, which can be
advantageous.
Only ASCII strings are supported by this handler, and wide strings are hashed
as though they contain only values under 0x7f. This is OK as invalid keys to
perfecthash may return any hashtable entry.
Differential Revision: https://phabricator.services.mozilla.com/D9405
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
After the previous patches, we no longer rely on the component manager
to incidentally start up XPConnect when we load the JS loader service
or to hold the JS component loader alive, so the do_GetService() call
for the JS loader in XPCOMInit.cpp can be removed. After that is done,
the JS loader is no longer used as an XPCOM component, so all of the
boilerplate for that can be removed.
Depends on D8757
Differential Revision: https://phabricator.services.mozilla.com/D8758
--HG--
extra : moz-landing-system : lando
nsLayoutModule must be initialized in order to call into JS, but I
don't want to have to rely on calling a service in that
module. Instead, always initialize the module very early in component
manager initialization. This also makes initialization more
consistent, so things like errors in manifests won't affect when it
happens, which can result in different behavior in different builds.
I also made nsLayoutModule initialization infallible, because I can't
imagine that we can do much that is useful without it.
Another change I made is that gInitialized is set to true even in a
GPU process. This simplifies checking whether initialization has
happened already when we start up the layout module.
Differential Revision: https://phabricator.services.mozilla.com/D9583
--HG--
extra : moz-landing-system : lando
JSONWriter currently calls new and delete indirectly through mozilla::MakeUnique to allocate a buffer. Becuase of this, the methods of this class cannot be invoked within Spidermonkey due to https://searchfox.org/mozilla-central/source/config/check_vanilla_allocations.py#6-14. Therefore, JSONWriter needs an AllocPolicy template parameter so that the allocation and deallocation routines can be changed to match the JS AllocPolicy when invoked within SpiderMonkey.
Differential Revision: https://phabricator.services.mozilla.com/D7279
--HG--
extra : moz-landing-system : lando
This change applies to Windows only.
Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed.
Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24.
This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla".
The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper.
Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within.
This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall.
Differential Revision: https://phabricator.services.mozilla.com/D4249
--HG--
rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp
rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js
extra : moz-landing-system : lando
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
Instead of creating a timer and then setting the timer's target, we can
determine the timer's target and pass it in directly when the timer is
created. This reordering of steps is slightly more efficient, since
SetTarget() is both a virtual call and requires locking, both of which
can be skipped if we know the target at timer creation time. If we're
reusing the timer, we also don't need to repeatedly set the timer's
target: we can set the target once at timer creation, and then be done.
We can do this safely here because mTaskCategory doesn't change
throughout the life of the IdleTaskRunner; we make mTaskCategory `const`
to make this more explicit to the reader.
