The problem was that we did not apply post barriers uniformly. For nursery
objects, bug 1779733 removed post barriers from set operations and the
finalizer. However they could still fire when the table was resized by a
removal. This could push store buffer entries that pointed into hash table
storage and which were not removed when the storage was resized again by a set.
This lead to use after free.
The patch improves things by adding nurseryTable and tenuredTable methods which
return a pointer to the table with the appropraite barriers depending on
whether the map object itself is tenured or not. The getData method remains and
returns a const pointer, so can't invoke any write barriers.
Operations that can mutate the map have to handle both nursery and tenured maps.
Differential Revision: https://phabricator.services.mozilla.com/D152035
This adds MutableRange and moves methods that can mutate the table into it. It
then allows us to create Range iterators for const tables. The range classes
still hold a non-const pointer to the table internally.
Differential Revision: https://phabricator.services.mozilla.com/D152034
Each line of the edit and resend panel should no longer grow when resizing the panel
But when editing, we fallback to multiline
Differential Revision: https://phabricator.services.mozilla.com/D152006
`js_fputs` is only used in "UbiNodeShortestPaths.cpp". Let's move it into that
file, so we can remove the `<stdio.h>` include from "Text.h".
Drive-by change:
- Remove the unused `AutoSuppressGC` using declaration from "Text.cpp".
Depends on D152015
Differential Revision: https://phabricator.services.mozilla.com/D152016
`FileEscapedString` was only used by TraceLogger. The `EscapedStringPrinter` function
accepting `const char*` was only used by `FileEscapedString`.
After the removal of `FileEscapedString`, "util/Text.h" no longer needs to include
"vm/Printer.h" and instead can use a forward declaration for `GenericPrinter`.
Also remove the unused fwd declaration of `StringBuffer` and then add the missing
fwd declaration in "StringType.h".
Differential Revision: https://phabricator.services.mozilla.com/D152015
This patch solves a performance problem and a semantic problem introduced
in Bug 1773109. That Bug changed the term tile cache 'backdrop' to mean
two distinct things:
1) An opaque region spanning the entire tiling area (the sole original
meaning).
2) An opaque region spanning the visible area.
Presently the code tries and fails to maintain both of those meanings in the
BackdropInfo structure. The problem arises when the tiling backdrop is one
color and the visible backdrop is a different color. There's only one color in
the structure! The existing code attempts to circumvent this by setting the
tile cache background_color for the tiling color, and that's slow. Even if it
wasn't slow, the opaque_rect is set for the tiling area instead of the actual
backdrop area, which is semantically confusing, and could lead to incorrect
draw on platforms that support native color layers.
This patch addresses these issues by adding a spanning_opaque_color to the
BackdropInfo structure, which will only be set when there is a backdrop that
covers the tiling area. That color can be used as a clear color for the slice
tiles, when set. This patch also adds a backdrop_rect which indicates the area
of the actual backdrop, if set. This backdrop_rect is used to size the native
color layers, if supported by the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D151942
This allows to pull out target management code out from toolbox back to TargetCommand.
And then allows to more easily share this store in the context of the browser console,
where there is no toolbox.
This is also an interesting example on how commands may populate redux store directly
so that we avoid having each panel translate commands's event into actions.
An alternative here, would be to introduce some generic layer between commands and redux.
Which would be the glue between a command and populating a store.
Differential Revision: https://phabricator.services.mozilla.com/D151493
There are potential races between insertion of the same gradient into
the cache on different threads, as well as acquiring a strong reference
to the GradientStops object racing with the expiration timer.
Differential Revision: https://phabricator.services.mozilla.com/D151981
Now that we're no longer testing FOG init instrumentation via rust-in-gtest, we
need a new thing to test in this manner or we'll delete this code and (in my
case) completely forget how we used to do this.
So let's replace the real instrumentation test with a boring one that doesn't
actually require all the boilerplate, but isn't harmed by it either.
Depends on D147450
Differential Revision: https://phabricator.services.mozilla.com/D147451
This instrumentation test has been disabled since bug 1763474 because delaying
init to this test meant that the preinit queue would overflow.
Because GoogleTest runs all at once and in its own decided order, we shouldn't
write any test that depends on FOG init happening at a specific time unless we
make it happen before the test suite even runs.
...and if we do that, the test resets that we perform in between will
obliterate the value in the init instrumentation, meaning we can't test it
anyway.
Note also that we skip-OK this test near local 4AM in case a properly-but-
inconveniently-timed "metrics" ping clears the value between FOG init and the
test run.
Now I thought we could put this in mochi, but it turns out that we reuse
browsers between test files. This means previous files' init of FOG and wiping
of all data causes the test to permafail when not run in isolation.
So here we are in xpcshell where we control init ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D147448
This is necessary because we haven't enabled APS in Beta yet and browser_partitionedIndexDB.js relies upon APS.
We want to clear up this "central as beta" breakage before the next Beta release.
Differential Revision: https://phabricator.services.mozilla.com/D152020
Using nsLayoutUtils::TransformPoint instead of going through the widget takes the iframe's
transformations into account.
Differential Revision: https://phabricator.services.mozilla.com/D151995
We directly pass the editor stylesheet in the `location` parameter that is passed
to `jumpToLocation`.
`jumpToLocation` wasn't covered in any test, so we modify `browser_styleeditor_media_sidebar.js`
to add coverage for it.
This is also testing Bug 1779180 which is in the same stack.
Differential Revision: https://phabricator.services.mozilla.com/D151597
For <style> elements, `getRelativeRuleLine` gives us the position of the rule
inside a stylesheet, when `getRuleLine` gives the position of the rule relatively
to the whole HTML source.
The former is more accurate for us when we want to display such line number in
DevTools UI (for example in the StyleEditor media query sidebar).
Test will be added in next patch of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D151596
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
Enable clearing of network resources on all layers(frontend, resource layer, server) when the
user click the clear button.
Differential Revision: https://phabricator.services.mozilla.com/D148694
When converting lazy getter calls, if the previous/next statement is
`ChromeUtils.defineESModuleGetters`, add properties into it, instead of
converting the lazy getter call into `ChromeUtils.defineESModuleGetters`
or creating new `ChromeUtils.defineESModuleGetters` call.
Differential Revision: https://phabricator.services.mozilla.com/D151980
