Recycling caused rendering problem on a MacOS PC with OpenGL compositor. TextureHost reuse with OpenGL compositor seemed to have a problem.
Adds pref layers.recycle-allocator-rdd for disable/enable the RecycleAllocator.
Differential Revision: https://phabricator.services.mozilla.com/D79639
This removes the support for the 'geckoview' telemetry in
the core and in the JSM files. It also cleans up testing
and the configurations.
Differential Revision: https://phabricator.services.mozilla.com/D79521
This removes the support for the 'geckoview' telemetry in
the core and in the JSM files. It also cleans up testing
and the configurations.
Differential Revision: https://phabricator.services.mozilla.com/D79521
This commit is made a bit harder to understand by a couple of changes
that I felt were necessary to make:
- I refactored the code for purging a single origin into the maybePurgePrincipal function.
- I updated the logger to actually allow for different log levels (to get debug logging)
Differential Revision: https://phabricator.services.mozilla.com/D79386
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This pref was enabled on all platforms, and the codepath which has it disabled
has been untested for some time. Remove the pref to simplify the code handling
the old case.
Differential Revision: https://phabricator.services.mozilla.com/D78974
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
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
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
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This pref was enabled on all platforms, and the codepath which has it disabled
has been untested for some time. Remove the pref to simplify the code handling
the old case.
Differential Revision: https://phabricator.services.mozilla.com/D78974
This has been this way in Nightly for a while now, with no issues
having been reported. Additionally, the telemetry pref has been at
1 for about the same amount of time, with no meaningful reports of
IO.
Differential Revision: https://phabricator.services.mozilla.com/D76856
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 affect 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
converts:
* security.sandbox.rdd.win32k-disable
* security.sandbox.gmp.win32k-disable
I'm assuming the pattern established by the other, newer, win32k StaticPrefs can
be followed here, and the xpcom checks aren't needed.
Differential Revision: https://phabricator.services.mozilla.com/D78933
The changes proposed here will speculatively parse all external scripts off thread as soon as they are fetched, except for async, link preload, and non parser inserted scripts. This should save us some time since currently all scripts are parsed right before execution or while they are blocking the dom parser.
Differential Revision: https://phabricator.services.mozilla.com/D76644
In general, PSM caches intermediates from verified certificate chains in the
NSS certdb. Before bug 1619021, this would include preloaded intermediates,
which is unnecessary because cert_storage has a copy of those certificates, and
so they don't need to take up time and space in the NSS certdb. This patch
introduces the intermediate preloading healer, which periodically runs on a
background thread, looks for these duplicate intermediates, and removes them
from the NSS certdb.
Differential Revision: https://phabricator.services.mozilla.com/D77152