We're going to add crates in build/rust that help reduce crate
duplication by providing older versions of crates based on newer ones,
which implies there would be at least 2 crates with the same name, one
of them being under build/rust. Allow that when vendoring.
Differential Revision: https://phabricator.services.mozilla.com/D146661
This simplifies profiling since now we can see the results within a single build
based on the preference (though there is still a slight cost to copying the
bytecode).
Setting to (the default) 0 disables compression.
Differential Revision: https://phabricator.services.mozilla.com/D144737
This leaves the code in ScriptLoader and ScriptLoadHandler a lot more readable.
ScriptBytecodeCompressedDataLayout and ScriptBytecodeDataLayout simplify
locating data in the ScriptLoadRequest bytecode buffer when compressing and
decompressing it.
The interface is still error-prone. For example, these classes don't check
that the returned pointers are within the bounds of the buffer.
Differential Revision: https://phabricator.services.mozilla.com/D145011
The SRI hash at the beginning of ScriptLoadRequest::mScriptBytecode is left
uncompressed because ScriptLoader::OnIncrementalData() tries to decode it
as soon as enough data is read (instead of waiting until OnStreamComplete()).
ScriptLoader writes the length of the uncompressed bytecode to the buffer
to make it easy for ScriptLoadHandler to allocate an buffer of the right size
to decompress the bytecode.
These changes are based on the bytecode compression implemented for WASM in
dom/fetch/FetchUtil.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D141524
It looks like this is just added in to test a bunch of stuff,
but this causes the test to break if allowXULXBL is not set,
so just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D146646
There's a similar chrome test for this functionality, test_title.xhtml,
and I think we don't care too much about the correctness of in-content
XUL at this point. We want to avoid enabling XUL during tests.
Differential Revision: https://phabricator.services.mozilla.com/D146641
List of changes:
- renamed a section for clarity (WebExtensions Experiments -> Adding
Experimental APIs in Privileged Extensions)
- fixed a few typos because I think we should consistently use the name
WebExtensions (with a `s`) when it is followed by API(s) at least
- added a link to the xpi-manifest repo in a notice (main repo, not the
`docs/` folder or a markdown file because that may change)
- Experimental APIs is referenced in the section that has been edited so
made it clear what is an Experimental API vs Built-in (hopefully).
Also kept the reference to "WebExtensions Experiment" (which seems to
be an alias)
Differential Revision: https://phabricator.services.mozilla.com/D146537
Those are indeed not being mutated during the object's lifetime before
CC, but currently the initialization is being done outside of the
constructor and that violates the newly proposed rule.
The only affected use is TransformStreamDefaultController::mStream
though, as others are exposed by public getters which does not support
MOZ_KNOWN_LIVE yet (and thus MOZ_KnownLive() is used by callers).
Ideally those should be refactored to be initialized within the
constructor, but I'll do that separately.
Differential Revision: https://phabricator.services.mozilla.com/D146209
I tried to pick thread groups that are part of GeckoView (Gecko), might be
common to GeckoView products (Nimbus), and the Android ecosystem (Kotlin
coroutines) instead of threads that are fenix-specific.
Differential Revision: https://phabricator.services.mozilla.com/D144753
The converted value gets passed into TimingNotification which assigns the value
into a PerformanceEntry (this is the only usage). Since PerformanceEntry is
defined in WebIDL, we could not change its types (which is double for mEpoch) so
we were forced to safely convert the value where we did.
I don't think the existing conversion code had any bugs since we converted a
64-bit signed integer timestamp into uint64_t (safe) into a double (which is
safe for the reasons mentioned in the code comments).
Differential Revision: https://phabricator.services.mozilla.com/D145142
Razvan Cojocaru
Daisuke Akatsuka
Ryan VanderMeulen
Mathew Hodson
Iulian Moraru
Mike Hommey
Steve Fink
Hiroyuki Ikezoe
Tom Schuster
Frederik Braun
Csoregi Natalia
Bryan Thrall
Andrew McCreight
Sylvestre Ledru
William Durand
Mozilla Releng Treescript
Joel Maher
Sebastian Hengst
David Shin
Kagami Sascha Rosylight
Jan Rio Krause
Michael Comella