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
We intentionally turn off this a11y check, because the following click is purposefully targeting a non-interactive content of the page to move cursor to the center of the entire browser UI to avoid issues with other focus/hover checks. We do this to avoid intermittent test failure.
Differential Revision: https://phabricator.services.mozilla.com/D205407
ext-urlbar.js is unused but will be removed in a separate
patch to avoid test failures in condprof tests. Condprof tests may use
an outdated profile directory that still references ext-urlbar.js in
startupcache files, which triggers a test-only test failure in
mozilla::net::CheckForBrokenChromeURL.
Differential Revision: https://phabricator.services.mozilla.com/D199769
* Make schema files directly parsable as valid JSON, consumable by JSONSchema
tools (like addons-linter).
* Clarify, simplify and unify licensing information across all repositories
and places we use the schemas.
Differential Revision: https://phabricator.services.mozilla.com/D200357
When an extension's content script is very slow and causes a webpage
to hang noticeably, a warning banner is displayed to the user. It
would be useful to also notify the extension developer when that
happens, so that they can address the issue.
Let's add a new event runtime.onPerformanceWarning that can be
dispatched when the browser needs to warn an extension of runtime
performance issues. For now, let's just dispatch that event when the
slow extension warning banner is displayed to the user.
See also https://github.com/w3c/webextensions/issues/456
Differential Revision: https://phabricator.services.mozilla.com/D194708
`inert-iframe-hittest.html` expects that `:hover` state should be updated
immediately after a pointer down. The state is updated by
`EventStateManager::NotifyMouseOver` [1] when we received a real or synthetic
`eMouseMove`. Therefore, the hover state may have not set yet if no refresh
occurs between the pointer down and checking the result.
Additionally, some WPT for UI Events and Pointer Events expect that `mouseover`
or `mouseout` should be fired before `mouseup`/`pointerup` if a preceding
`mousedown` or `pointerdown` event listener removes the target. So, this
patch may fix intermittent failures of them if there are.
Therefore, we should flush pending synthetic `mousemove` event for keeping the
event order as same as they happen. However, simply flushing it causes
unexpected pointer capture state change because
`PointerEventHandler::ProcessPointerCaptureForMouse` handles synthetic
`mousemove` but it should not cause pointer boundary events at the moment (the
pointer boundary events should be fired when the pointer is actually moved, note
that this is different rule from the rules of mouse boundary events).
Therefore, this patch changes
`PointerEventHandler::ShouldGeneratePointerEventFromMouse`.
However, this blocks `lostpointercatpure` event when the capturing content has
already been removed from the DOM tree. The path is,
`EventHandler::HandleEventWithPointerCapturingContentWithoutItsFrame` stops
dispatching `pointerup` nor `pointercancel` in this case, but
`EventStateManager::PostHandleEvent` is the only handler of implicit pointer
capture release. Therefore, we need to make it dispatch lostpointercatpure`
event if the canceling event caused `ePointerUp` or `ePointerCancel`.
Finally, this patch fixes a bug of `browser_ext_browserAction_popup_preload.js`.
It tests the pre-loading which starts when `mouseover` before `mousedown` on a
widget. However, it does not correctly emulate the user input.
* Synthesizing only `mouseover` does not update the internal pointer info and
does not cause dispatching related events.
* Synthesizing `mousedown` without `mousemove` cause `mouseover` before
`mouseup` because at dispatching `mousedown`, `PresShell` stores the cursor [2]
and the mouse boundary events will be dispatched before `mouseup`.
`ext-browserAction.js` assumes the events are fired as this order,
`mouseover` -> `mousedown` -> `mouseup`, but this would not work if the
preceding `mousemove` of `mousedown` is not correctly fired. I'm not sure
whether `mousemove` is always fired before `mousedown` on any environments,
but it should be rare and it affects only this kind of tricky code. For now,
fixing this in the test side must be enough.
1. https://searchfox.org/mozilla-central/rev/9a5bf21ea2dd04946734658f67f83f62ca76b0fa/dom/events/EventStateManager.cpp#4874,4913-4914
2. https://searchfox.org/mozilla-central/rev/9a5bf21ea2dd04946734658f67f83f62ca76b0fa/layout/base/PresShell.cpp#6756
Differential Revision: https://phabricator.services.mozilla.com/D193870
Merge (browser_style) extension-mac.css with extension.css and use
-moz-platform media query for conditional CSS.
Replace extension-{mac,linux,win}-panel.css with one CSS file, without
platform-specific conditions since their content were already identical.
Simplified JS code referencing these CSS files: Instead of lazy getters
("extensionStylesheets") exported and imported across modules, use plain
string constants for simplicity. The extension.css file is not expected
to be used in new code since it is a deprecated feature, and the string
is sufficiently unique to be easily findable through code search.
Differential Revision: https://phabricator.services.mozilla.com/D198312
