Due to a change in timing in this patch, when we reset the confirmation pref
at the end of the test, a TRR request would happen after we changed the prefs
leading to accessing a non-local IP in testing and causing a crash.
This should be gated on being in the correct mode anyway
Depends on D81517
Differential Revision: https://phabricator.services.mozilla.com/D82222
mTRRUsed is a variable that we check to gate several telemetry probes, and to
decide if TRR really failed and we should add a domain to the TRR blocklist.
The problem with setting this too early is that when this is true but we
don't actually send the TRR request, then we will report that we fell back
to Do53 and potentially skip next TRR requests in the future.
The solution here is to only set mTRRUsed if TRRServiceChannel::AsyncOpen
succeeds.
Differential Revision: https://phabricator.services.mozilla.com/D81517
Removes the incorrect optimisation added in D37584 for IonBuilder and keeps it
only in `MPow::foldsTo()` when optimising the cases when power ∈ {2,3,4}.
Also changes `MPow::canBeNegativeZero()`'s access modifier to private, now that
it's only used within `MPow::foldsTo()`.
Differential Revision: https://phabricator.services.mozilla.com/D82338
Different from `GetInvisibleTrailingWhiteSpaceRange()`, it always returns
the range even if it's collapsed (i.e., there is no leading white-space).
Differential Revision: https://phabricator.services.mozilla.com/D82274
When switching from a dedicated addon toolbox to an about:devtools-toolbox tab, we did a minimal migration for the browser_aboutdebugging_addons_debug_* tests.
They used to inject a "toolbox test script" in the process of the addon toolbox. But we could have updated them with regular test APIs, async/await patterns etc.
Doing the migration now in preparation for adding calls to waitForRequestsToSettle in the next changeset.
Differential Revision: https://phabricator.services.mozilla.com/D82362
While the duration returned by the demuxer is typically equal to the decoded size; recent cases have shown that this isn't always the case.
Now, the only way you can encounter this bug is if the user has set some pref. the audio BlankDecoderModule is never used by default; only the video one.
Differential Revision: https://phabricator.services.mozilla.com/D82138
This patch includes content from the following places.
- Lina's "Getting Rusty: How to ship an XPCOM component in Firefox" slide deck.
- Zibi's "Rust <--> C/C++ FFI for newbies" gist.
It also links to Emilio's "FFI patterns #1 - Complex Rust data structures
exposed seamlessly to C++" blog post. I was going to include that content, but
it's very long, so I have omitted it for now.
Differential Revision: https://phabricator.services.mozilla.com/D81963
Set a flag on stubs used by the transpiler and then treat those similar to a
constraint in the old system: invalidate when attaching a new IC stub (in front of
it), when updating the stub, or when unlinking the stub.
This is necessary to avoid repeated bailouts followed by a deoptimization in
CheckFrequentBailouts.
Differential Revision: https://phabricator.services.mozilla.com/D81823
One of the `WSFragment`users' purpose is, they remove invisible white-spaces
when there are. So, `TextFragmentData` should have API to retrieve the
ranges and use them for initializing `WSFragment` which represents leading
or trailing white-spaces. For making this patch smaller as far as possible,
these APIs implements only the case when there is no NBSP.
For result of the new API, this creates a template class, `EditorDOMRangeBase`,
whose boundary type is `EditorDOMPointBase`. Its methods are named from
`nsRange`'s same methods.
Differential Revision: https://phabricator.services.mozilla.com/D82272
If client script wants to commit composition string per input, it sometimes
use the following script.
```
let input = document.getElementById('input');
input.addEventListener('input', () => {
input.blur();
input.focus();
});
```
Since `blur` will commit composition string, this script can commit text. But
since Gecko has an optimization for this situation, focus won't be lost
completely.
Although GeckoView synchronizes Java text and selection with Gecko text when
getting focus, this sample may be failed due to timing issue. `blur` tries to
commit string, but result is never returned since focus is lost as temporary
(although text is finally committed in Gecko.). Then, GeckoView are waiting
for result that is never returned forever, So this synchronization is failed.
When getting focus again, we should synchronize it at force.
Differential Revision: https://phabricator.services.mozilla.com/D80147
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We need to be able to init StartupCache before the Omnijar in order to cache
all of the Omnijar contents we access. This patch implements that.
Depends on D77632
Differential Revision: https://phabricator.services.mozilla.com/D77633
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
test_collation.js uses nsICollation and nsICollationFactory from script, but
I would like to make it non-scriptable. Actually, it is only used from
xpcshell tests.
Differential Revision: https://phabricator.services.mozilla.com/D82310
This is strictly a quality of life improvement when cross-compiling to
Windows targets. A common scenario is mounting an object directory
into a Windows VM, which requires additional VM configuration to
handle (absolute) symlinks. With this patch, `export NSDISTMODE=copy`
in a mozconfig sidesteps any such symlink issues.
Differential Revision: https://phabricator.services.mozilla.com/D77118
Source history does not give any good clues about why this line was added in the first place. In any case, LLVM trunk currently has build bustage when threads are disabled. We could work around the bustage and/or wait for a fix, but it seems like threads are a good thing to have in general nowadays. Maybe this could help with LTO build times.
Differential Revision: https://phabricator.services.mozilla.com/D82447
For a while, now, ICU data has been stored as raw read-only data in rather
than a separate loadable library. This means the parts of ICU that can load
such a module are not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D82262
