Currently, `EditorBase::GetDocumentIsEmpty()` is implemented by `TextEditor`,
and it refers only `IsEmpty()` which is implemented both by `TextEditor` and
`HTMLEditor`. So, `IsEmpty()` should be a virtual method of `EditorBase`,
then, `EditorBase` can implement `GetDocumentIsEmpty()`.
Depends on D115786
Differential Revision: https://phabricator.services.mozilla.com/D115787
They are used by setting text value of `TextEditor` or replacing a misspelled
word with a new word in both `TextEditor` and `HTMLEditor`. Therefore,
they should be in the `EditorBase` rather than `TextEditor`.
Note that the path of the former case may be in a hot path. Therefore, we need
to keep redirecting to `TextEditor` for keeping the performance only in the
case.
Depends on D115785
Differential Revision: https://phabricator.services.mozilla.com/D115786
This method is semi-public method, meaning that this is commonly used by
public methods which handle various user input and that causes inputting
text, both in `TextEditor` and `HTMLEditor`.
Therefore, for making `HTMLEditor` stop inheriting `TextEditor` class in the
future, we should move it into `EditorBase`.
Depends on D115784
Differential Revision: https://phabricator.services.mozilla.com/D115785
IME is available in both `TextEditor` and `HTMLEditor`, and the handling
code is almost same (they partially do different things with checking
`IsHTMLEditor()`). Therefore, we should move them to `EditorBase` for
making `HTMLEditor` possible to inherit only `EditorBase` in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115784
So that now EffectCompositor::HasAnimationsForCompositor doesn't return true
for such cases, thus we will not accidentally try to generate
nsDisplayBackgroundColor display item for such animations (bug 1699890#c21)
and we will not generate nsChangeHint_RepaintFrame (bug 1701547) either.
Differential Revision: https://phabricator.services.mozilla.com/D115774
TSan is prone to issues with slowdown and resource exhaustion. Increasing crashtest chunking appears to reduce the rate of restarts and intermittents related to timeouts.
Differential Revision: https://phabricator.services.mozilla.com/D110372
After bug 1586236, we use the memory resource notification object to detect a low
memory situation on Windows, which is signaled when the available physical memory
is low. If the available physical memory is low, however, it's possible that there
is still commit space enough for the application to run. In such a situation, we
don't want to make aggressive efforts to reduce memory usage.
This patch makes sure we send the memory pressure event (both New and Ongoing) only
when the available commit space is lower than the threshold value defined by the pref
"browser.low_commit_space_threshold_mb". Its default value is set to 200MB
based on our telemetry data indicating ~60% of OOM crashes with <100MB, ~75% with <300MB.
To use the pref in `nsAvailableMemoryWatcher`, this patch moves the call to
`AvailableMemoryTracker::Init()` to `XRE_mainRun()`. It was in `NS_InitXPCOM`
because the old initialization code hooked APIs and needed to be done while
the process has only one thread (bug 741540). The current `AvailableMemoryTracker`
does not use hooks, so it doesn't have to be initialized that early.
Differential Revision: https://phabricator.services.mozilla.com/D115605
Remove explicit section-left children widths to allow the parent to flex with a static width section-main for initial screen. Clean up some breakpoint sizing with percent/viewport widths.
Differential Revision: https://phabricator.services.mozilla.com/D115546
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
This changes the MediaKeys to actually service output protection status queries
by sending those queries to the EncryptedMediaChild actor and handling responses
from the actor. These interactions are done via the observer service.
Differential Revision: https://phabricator.services.mozilla.com/D115418
This expands EncryptedMediaChild to be able to query and track the information
now shared by webrtcUI around screen and window sharing. The actor will use this
information to report to observers if capture is possible or not.
For now we use a coarse approach where we only track if the screen or any window
is shared, but in future I plan to have a more granular tracking of windows.
Differential Revision: https://phabricator.services.mozilla.com/D115417
This patch plumbs the QueryOutputProtectionStatus call from the CDM up to the
MediaKeys. This is plumbing is done to get the request to an endpoint of Gecko
C++ code, and future patches will do further plumbing in order to complete the
query.
After the first query is complete, we cache the result in a CDM's
ChromiumCDMParent and update the value only when notified of changes from the
MediaKeys. This has the benefit of that checks after the first don't need to
touch the main thread. This avoids adding more main thread work, and means we
can still complete checks in a timely fashion even if the main thread is running
hot.
We cache in the parent rather than the child so that the parent can make
decisions on how to handle requests even if the CDM machinery is not yet fully
initialized. In future it may make sense to move the caching to the child, but
I'd prefer to do this only after other refactoring of the machinery which I
consider out of scope for this bug.
Future patches will ensure listeners are in place such that the cached data is
updated when updates are received further up the stack.
Differential Revision: https://phabricator.services.mozilla.com/D115415
* Stop memoizing web console front
* track navigations via DOCUMENT_EVENT's dom-complete
* await for HarAutomation async initialization from toolbox codebase
These changes help fix browser_harautomation_simple.js.
But this isn't enough as will-navigate can easily be missed.
Differential Revision: https://phabricator.services.mozilla.com/D114464
This introduces uncessary complexity and makes it uterly complex to wait
for HarAutomation's async initialization.
Its init isn't async yet.
Differential Revision: https://phabricator.services.mozilla.com/D114837
When a user changes a preference involved in a Normandy experiment, we no
longer immediately end the experiment. This caused a problem because Normandy
didn't check for user changes when resetting prefereces at the end of an
experiment. As a result it would reset all preferences back to their original
values on the specified branch, even if that would mean changing a preference
it knows the user had modified.
This change causes Normandy to never reset the user branch of an experiment
preference that the user has changed. This is true even if the user changes the
preference away from the experimental value and then back to it.
Differential Revision: https://phabricator.services.mozilla.com/D115713
About browser_jsterm_autocomplete_getters_cache, we weren't correctly waiting
for popup to close because of the reload. Instead we probably worked around intermittents
by closing the popup explicitly before the reload.
But that creates other issue, where the reload may close the popup *after* we do Ctrl+Space.
(this patch doesn't trigger any issue with this test, but better fix that)
Differential Revision: https://phabricator.services.mozilla.com/D112231
I didn't add this check originally because the thinking was that macOS wouldn't dispatch
these events to us anyway as long as a menu is open.
However, our menu opening is asynchronous. So we can still get wheel events between the
mousedown that asks to open the menu, and the delayed perform which then ends up opening
the menu for real. We don't want to cancel opening when we get these straggler events.
Differential Revision: https://phabricator.services.mozilla.com/D115763
The strong reference will be dropped when FutureClientSourceParent is removed,
and we guarantee that all FutureClientSourceParents will either be removed or
replaced with a ClientSourceParent (or at least this is a guarantee that's
supposed to be true).
Differential Revision: https://phabricator.services.mozilla.com/D68041
ClientChannelHelperParent is the thing creating the ClientInfos which aren't
backed by existing ClientSources, so it may make sense for CCHP to tell the
ClientManagerService (CMS) to "expect" or "forget" a "future"
ClientSource(Parent).
When such a ClientInfo is created, CCHP notifies the CMS that a future
ClientSource may be created. This notification has to be observed before any
ClientHandles try to query CMS to a ClientSourceParent, which is the case
because the notification as well as ClientHandleParent constructors occur over
PBackground, and the notification sending method is called first.
CMS is told to forget the future ClientSource whenever a redirect occurs that
would result in the creation of a new ClientSource (i.e. a new ClientInfo). It's
also possible that the ClientInfo's LoadInfo's channel is cancelled. To account
for this, CHCP stores the most recent ClientInfo it's created and tells CMS
to _possibly_ forget the associated future ClientSource in its destructor. It's
possible that the channel completed its load, in which case this notification
is a no-op. This also relies on CHCP being destroyed after the reserved
ClientSource has a chance to both be created and register its
ClientSourceParent.
Differential Revision: https://phabricator.services.mozilla.com/D66529
The changes only make it possible for ClientManagerService to store
FutureClientSourceParents, but it will not actually store them until
following changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66145
Also implements SourceTableEntry and nsIDHasher to switch ClientManagerService's
nsDataHashTable to a mozilla::HashMap<nsID, SourceTableEntry> in following
changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66144