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.
There is no advantage in making these methods more restrictive on their
parameters than AssignLiteral.
The current implementation of the AppendLiteral overloads for equivalent
char_types is more permissive than AssignLiteral, but comments in the
implementation mention the possible optimization used in AssignLiteral and so
are assuming a similar constant and static storage duration restriction on its
parameter. The optimization may never be implemented, but clients that would
benefit from support for non-constant or non-static parameters are also
expected to be rare, so there is little value in ruling out the optimization
at this stage.
ReplaceLiteral currently uses the AssignLiteral optimization.
Differential Revision: https://phabricator.services.mozilla.com/D8777
--HG--
extra : moz-landing-system : lando
A character array initialized with a list of character literals will not
necessarily have a trailing null-terminator required for AssignLiteral or
trimmed in EqualsLiteral.
Depends on D8775
Differential Revision: https://phabricator.services.mozilla.com/D8951
--HG--
extra : moz-landing-system : lando
"Bound" is the term used in the C++ standard to describe the number of
elements in an array.
EqualsLiteral has no opportunity to optimize for constant and static storage
duration parameters.
Depends on D8773
Differential Revision: https://phabricator.services.mozilla.com/D8774
--HG--
extra : moz-landing-system : lando
There is no advantage in AssignASCII() for char, and AssignASCII() does not
exist for char16_t array and char_type. Similarly for ReplaceASCII and
AppendASCII. This AssignLiteral() overload already says it is not only for
ASCII.
Depends on D8771
Differential Revision: https://phabricator.services.mozilla.com/D8773
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR. Change APP_PATH to be the path to the parent process .app directory and make GetAppPath return this path when called from the parent or a child process.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
Since https://hg.mozilla.org/mozilla-central/rev/9db7cf4cc385#l13.44 the type
system always excludes calls with character pointers and so there is no need
to mention this in the comment.
The comment for the 8-bit to 16-bit AssignLiteral overload is modified a
little to use "char" instead of "character" so as not to imply that anything
other than 8-bit char parameters may be provided to that overload.
The ReplaceLiteral and InsertLiteral comments are adjusted to use "character"
instead of "char" so as not to imply that the method or comment is limited to
8-bit char parameters.
Differential Revision: https://phabricator.services.mozilla.com/D8770
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
The NS_NewTimer* family of functions, when using a custom event target,
currently go through a path that looks something like:
auto timer = createTimer()
timer->SetTarget(target);
// call the requisite Init* function
return timer;
This setup is inefficient, because SetTarget requires the timer mutex to
be acquired. The mutex acquisition here is completely unnecessary,
because the timer hasn't yet been shared out to the wider world; we can
set the timer target without acquiring the mutex at all because we know
that no sharing is possible at this point.
This patch reworks things somewhat to make that possible.
