This patch updates every use of EventManager in child/ext-*.js files
that can referenced from extension contexts of envType "addon_child".
Pre patch, these could trigger "background-script-reset-idle" and
result in triggering "background-script-reset-idle" in the parent
despite the background being stopped, and consequently trigger the
reported bug. The previous patch fixes the negative consequence of this
unexpected event, this patch fixes an underlying cause by removing the
triggers.
Forcing resetIdleOnEvent to false does not have any negative impact on
these modules, because all of these events are dependencies of an
EventManager in the parent, which already activates the functionality
associated with resetIdleOnEvent=true.
To minimize the likelihood of affecting unit tests, this patch keeps the
EventManager of test.onMessage at resetIdleOnEvent=true as before, and
defers to bug 1901294 for changing it to false.
Original Revision: https://phabricator.services.mozilla.com/D215298
Differential Revision: https://phabricator.services.mozilla.com/D216987
The regression range is baffling, but it just shows a missing
invalidation.
The extension has worked around this upstream:
a48ff54cf6
But the root cause is a bug in Firefox. The popup here had styles much
like:
```
html, body, #root {
height: 100%;
min-height: 100%;
width: auto;
min-width: 320px;
}
```
The popup starts off zero-sized, but then gets re-measured async at some
point by the extension code.
Main issue here is that, due to the bresize, we reflow the viewport,
then the html, but the html loses the bresize flag. So we don't reflow
the body element to give it the right height.
Before my patch, the body was reflowed because there was a BFC under it,
so it had the NS_BLOCK_HAS_CLEAR_CHILDREN flag, which ended up papering
over this bug.
I think this can only happen with the special shrink-wrap resize mode,
because it's the only thing that can turn a percentage bsize like 100%
from behaving like a percentage to behave like auto... So I haven't been
able to reproduce outside of our extension popup usage. Otherwise the
percentages resolving to different things would set the bresize flag
appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D215842
This also avoids sending an engine-update Glean event for the default engine by not handling the engine-icon-update
notification in the update tracking code.
Differential Revision: https://phabricator.services.mozilla.com/D210838
This stops sjs files from picking up the test environments/configurations which means they get just the sjs environment
which is what we want.
Differential Revision: https://phabricator.services.mozilla.com/D210928
focus() is sync so there's no need to await stuff.
The delayed one needs to remain focusable for the focus fix-up not to
kick in.
MANUAL PUSH: Trivial test change CLOSED TREE
There's no call to AddRefreshObserver(FlushType::Layout), so we don't
need to track layout flushes. The only reason we need
mLayoutFlushObservers is so that reflows triggered from the style flush
get processed. But at that point, we can just flush layout directly.
There's no really good distinction between style flushes and layout
flushes with container queries anyways, so this makes the code simpler
to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D209924
This patch removes both the backend and UI code related to the built-in
abuse reporting feature. I kept the ability to disable abuse reporting
with the `extensions.abuseReport.enabled` pref. Other prefs related to
the old abuse reporting feature have been removed.
Some tests have been deleted because they aren't relevant anymore.
On the web API side, both the property and method have been removed
since only AMO consumes these APIs and AMO already supports the absence
of these APIs. That is also why GeckoView has been slightly updated.
We do not collect Telemetry with the new AMO (abuse report) form so
all the Telemetry bits have been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D208457
This patch changes the behavior for extensions with an embedded
options_ui page (open_in_tab not false), that have specified the
"dark" value in the "color-scheme" meta tag or CSS property, AND
with the user having indicated the preference for dark theme support.
There are no changes when any of these conditions have not been met.
The "color-scheme" CSS property is the standard way for extensions (web
pages in general) to opt in to automatic dark theme support, e.g. by
changing the foreground color to white. Prior this patch, the
background was unconditionally white, which resulted in unreadable text
when the dark theme is enabled. This patch changes the default
background color to "Canvas", which is a special keyword that is dark
theme-aware (almost black - `rgb(28, 27, 34)` by default).
When `browser_style:true` is used (which is the default in MV2),
extension.css is activated, which unconditionally specifies a black
foreground color. To avoid a poor contrast with the new theme-dependent
background color, the color is now white when the dark theme is enabled.
This patch includes comprehensive test coverage, but the only tests
whose behavior changed by this patch are:
- options_ui_dark (background changed)
- options_ui_browser_style_true_dark (color, background changed)
Differential Revision: https://phabricator.services.mozilla.com/D207540
Note that we intentionally return "null" for null principals *and* file
scheme, which is - at the time of writing - different than Chromium.
Differential Revision: https://phabricator.services.mozilla.com/D206989
