To get this fix: https://github.com/mozilla/application-services/pull/3235
Updated as follows:
```
sed -i 's/e8d7530319fa6c20d9de78d031c9398630eca3cd/61dcc364ac0d6d0816ab88a494bbf20d824b009b/g' services/fxaccounts/rust-bridge/firefox-accounts-bridge/Cargo.toml services/sync/golden_gate/Cargo.toml toolkit/components/extensions/storage/webext_storage_bridge/Cargo.toml toolkit/components/glean/Cargo.toml toolkit/library/rust/shared/Cargo.toml
./mach vendor rust
```
Verified by running the new regression test that I added in the bug:
```
./mach test toolkit/components/extensions/test/xpcshell/test_ext_storage_{local,sync,sync_kinto}.js
```
Differential Revision: https://phabricator.services.mozilla.com/D79628
The changes in xpconnect are necessary because this is not being specified in
the usual way, with a getter. Ordinary data properties require an explicit
loophole to make them visible through X-ray wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D77181
This solves a remaining failure in wasm/spec/spec/left-to-right.wast.js, where
the whole function's body is optimized away.
Differential Revision: https://phabricator.services.mozilla.com/D79439
Using the trapnz instruction was incorrect, because traps can't be resumed in
theory, so the previous x86 backend was only working because it would not
remove the jump after this trap instruction. Make it more correct by not lying
to Cranelift and use a conditional resumable trap instead.
Will need a Cranelift bump as well.
Differential Revision: https://phabricator.services.mozilla.com/D79438
There's no good reason for the message to be duplicated, and it turns out that
this test was actually asserting a bug that occured with CSP violation messages
(see Bug 1645745).
We change the test so it only waits for a single message, which should fix the
intermittent on windows7 (the message wasn't "repeated" but duplicated).
Differential Revision: https://phabricator.services.mozilla.com/D79651
This patch tries to implement Blink-compat white-space normalizer for
`HTMLEditor`.
It's difficult to list up our traditional white-space normalization rules
because `WSRunObject` touches white space sequence only when there is not
acceptable case, e.g., an ASCII white-spaces will be adjacent to another
one, and replaces only unacceptable white-space only. Therefore, whether
white-space sequence may start with either an ASCII white-space or an NBSP.
On the other hand, Blink and WebKit makes white-space sequence always
starts with an NBSP or an ASCII white-space (unfortunately, they behave
differently!). So, for web-compat, we should simulate Blink's behavior
because either behavior is reasonable but Blink have more market share.
This patch simply adds new white-space normalization path for the new one,
and it's switchable with a pref, and still disabled by default.
The other reason why we should do this is, our traditional white-space
normalizer touches the DOM a lot of times per edit action, and the timing
is both before and after touches the DOM tree. Therefore, it's difficult
to compute actual deleting range for `InputEvent.getTargetRanges()` and
touching a lot of times causes running mutation event listeners a lot and
creates a lot of transaction class instances. So, new one have a lot of
merits:
1. Improve web-compat
2. Improve the peformance
3. Improve the security
4. Improve the footprint (but this is now worse then traditional one)
5. Simplify the implementation
The new normalizer is mostly implemented with only 3 `HTMLEditor` methods.
One is `HTMLEditor::DeleteTextAndNormalizeSurroundingWhiteSpaces()`. This is
semi-public method for the edit action handlers. This takes a range with
2 `EditorDOMPoinInText` to delete the range simply. This also replaces
surrounding white-space sequence if necessary. For inserting text case,
this method also handles only white-space normalization when it's called
with collapsed range, i.e., same `EditorDOMPointInText`. This tries to use
`RepaceTextWithTransaction()` as far as possible to reduce creation cost of
transaction classes and the footprint.
Another one is `HTMLEditor::ExtendRangeToDeleteWithNormalizingWhiteSpaces()`.
This tries to extend the given range to normalize surrounding white-spaces.
This is currently not optimized for footprint because this may include
white-spaces which do not need to be replaced. This optimization should be
done before shipping, but for now, enabling `InputEvent.getTargetRanges()` in
Nightly channel is more important. So that it should be done in a follow-up
bug.
The other is `HTMLEditor::GenerateWhitepaceSequence()`. This creates
normalized white-space sequence with surrounding character information.
For keeping this method simple as far as possible, we shouldn't optimize
the range of generation even in follow-ups.
Finally, the white-space sequence is not tested in mochitests, so that we
can enable this new normalizer when we run mochitests under
`editor/libeditor/tests`. However, WPT has some tests. We should keep
them running with current normalizer for checking regression. Instead,
we should enable the pref only for the new WPT added by the previous patch.
Depends on D78655
Differential Revision: https://phabricator.services.mozilla.com/D78656
I realized that there is no word "whitespace" in formal English. This patch
replaces it with "white-space" in comments, and change method names to use
"WhiteSpace".
Depends on D78654
Differential Revision: https://phabricator.services.mozilla.com/D78655
This patch adds new tentative WPTs which test Chrome's behavior at modifying
around white spaces. As mentioned in the test files, these tests just check
compatibility with Chrome, not suggesting any standards.
Depends on D77987
Differential Revision: https://phabricator.services.mozilla.com/D78654
Callers of `WSRunObject::GetASCIIWhitespacesBounds()` may want to scan only
previous or next whitespaces. Therefore, we can split it to save creation
cost of `EditorDOMPointInText`.
Additionally, this makes them scan whitespace sequence in a text node until
hitting its end for avoiding to use expensive API of `WSRunScanner`.
Differential Revision: https://phabricator.services.mozilla.com/D77986
While JS can't observe v128 values, the debugger API can, so
implement a case in ToJSValue for this. Other guards will
ensure that these values (which are somewhat wrong) are not
seen by JS.
Differential Revision: https://phabricator.services.mozilla.com/D79261
This is a weird conversion because the existing VarCache mirror prefs are in a
two static structs, one for touch prefs and one for the equivalent mouse prefs,
and we dynamically select the appropriate struct in `GetPrefsFor()`.
(But note that `ui.mouse.radius.reposition` and
`ui.mouse.radius.inputSource.touchOnly` do not have corresponding `touch`
prefs! For touch events they are always considered to be false.)
The commit make the following changes.
- It makes the prefs into static prefs.
- It moves the code in `GetPrefsFor()` into a constructor for
`EventRadiusPrefs`, and copies the pref values into a temporary object of
that type. Those copied values are then used by the subsequent code.
- It removes the two static `EventRadiusPrefs` structs.
- It renames some fields in `EventRadiusPrefs` to make them more closely match
the pref names.
Differential Revision: https://phabricator.services.mozilla.com/D79405
Specifically:
> Log warning: The log 'Services.Common.RESTRequest' is configured to use the preference 'services.common.log.logger.rest.request' - you must adjust the level by setting this preference, not by using the level setter
This is because the hawkrequest module attempts to explicitly set the level
from the preference value, but these days Log.jsm manages that itself.
Also skips obtaining the log itself until it's needed, as it almost never
actually is.
Differential Revision: https://phabricator.services.mozilla.com/D79633
I wrote this patch to address two problems:
1. if I do `mach run` from a directory other than $topsrcdir, $objdir, or
$objdir/dist/bin, then .gdbinit will not be loaded.
2. Debugging the firefox binary will never load the JS prettyprinters in any
case.
I believe this patch fixes other problems as well, such as .gdbinit_python not being found, and the gdbpp pretty-printers not getting loaded in various situations.
The main changes of this patch are:
1. Move .gdbinit into build/ (and $objdir/build/) to delay it from getting
loaded until the search path is configured.
2. Move libxul.so-gdb.py into the correct directory.
3. Use either libxul.so-gdb.py or js-gdb.py to configure the correct
search path then load .gdbinit, and have .gdbinit load all of the
pretty-printers (Gecko and JS).
4. Use a single preprocessed file to configure the source directory. Use
relative paths within the objdir for everything else.
Differential Revision: https://phabricator.services.mozilla.com/D77589
When Tab is moved to another window, all async ImageHosts need to update CompositorBridgeID. It is used for calling ScheduleComposition().
Differential Revision: https://phabricator.services.mozilla.com/D79068
I think we were defining those methods in self-hosted JS, because that automatically gives
us the property that they all have the same identity. This causes bad error messages.
Instead redefine them in the finishInit ClassSpec hook. We still have the "wrong" methods
in the 'methods' array so that JSXray tests continue to pass.
Differential Revision: https://phabricator.services.mozilla.com/D79615
There are a number of system parameters that return simple floats and bools
and are just different forms of system parameter query.
This introduces a new singleton and IPDL calls to send these values from parent
to content processes and cache them in content.
I started with these 2 variables because their values don't go stale. In a
later changeset, I will add more logic to invalidate cached values that go
stale, such as for the SPI_GETFLATMENU metric.
Differential Revision: https://phabricator.services.mozilla.com/D76639
This crash happens because we try and clean up the map from target to WeakRef in the WeakRef finalizer, and the target can be dead by this point if it's a nuked CCW (before it is nuked the CCW ensures this sweep order does not happen).
The fix is to fix up the map when CCWs to WeakRefs are nuked. Fortunately there's already a hook where the GC is told about this.
The same issue applies to FinalizationRecordObjects. This fix is slightly different because they don't have a target pointer so we can't find the map entry. Instead we clear the record and cleanup happens later when it gets swept.
Differential Revision: https://phabricator.services.mozilla.com/D79533
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
Mihai Alexandru Michis
Tooru Fujisawa
Rob Wu
Jason Orendorff
Benjamin Bouvier
Kartikaya Gupta
Jan-Ivar Bruaroey
Sylvestre Ledru
julianwels
Mark Banner
Dimi Lee
Tom Tung
Mirko Brodesser
Simon Giesecke
Martin Stransky
Nicolas Chevobbe
Masayuki Nakano
Lars T Hansen
Nicholas Nethercote
Mark Hammond
Noemi Erli
Steve Fink
sotaro
Emilio Cobos Álvarez
Timothy Nikkel
Tom Schuster
Sonia Singla
Jonathan Kew
Chris Martin
longsonr
Jon Coppeard
Logan Smyth
Yura Zenevich
Eden Chuang
Ting-Yu Lin