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
Report to telemetry when add-on is blocked by the blocklist, or when an
updated/installation resutls in the unblocking of an add-on.
Differential Revision: https://phabricator.services.mozilla.com/D114820
Tests that rely on `AddonTestUtils.promiseCompleteInstall` to await the
completion of an update may encounter intermittent test failures,
because the test helper relies on `onInstallEnded`, which is sent before
all cleanup has run (removing temp xpi, removing staged directory).
The `install()` method returns a promise that is resolved right after
the cleanup of those temporary files. So await that.
Also fixed an intermittent issue in test_system_upgrades.js that became
a permafail as the result of this patch.
fix test_system_upgrades.js / promiseCompleteAllInstalls
Differential Revision: https://phabricator.services.mozilla.com/D114819
AddonUpdateChecker.getNewestCompatibleUpdate has only one non-test
consumer in XPIInstall.jsm. That consumer filters out older versions
after finding an update.
In order to correctly report whether an update is blocked by the
blocklist, the version comparison has been moved inside the
getNewestCompatibleUpdate method, with no other changes.
Differential Revision: https://phabricator.services.mozilla.com/D114818
An alternative to this is changing the line scrolling acceleration Gecko
does to double the amount-per-line, rather than the amount-of-lines that
we scroll.
(But actually, even if we determine that that is a better course of
action, we probably want this anyways).
Differential Revision: https://phabricator.services.mozilla.com/D115692
In GTK widget, we dispatch a set of composition events when IME or something
inserts text which is different from typing character or without tying a key.
However, this causes non-cancelable beforeinput event and Chromium on Linux
does not dispatch keyboard events nor composition events in this case, and the
beforeinput event in this case is cancelable.
Therefore, we should take same behavior as on macOS which was implemented by
bug 1520983.
Differential Revision: https://phabricator.services.mozilla.com/D115681
Capping selection range in SetValue early makes the subsequent SetSelectionRange call unable to detect actual selection range change. This patch defers it so that select events can be consistently fired.
Differential Revision: https://phabricator.services.mozilla.com/D115729
