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
The `browser.display.document_color_use` is an a11y feature to allow
users to override colors. This feature does not work for UA stylesheets
and results in the reported bug.
To resolve the bug, this patch changes browser_style to be added as an
AUTHOR_SHEET instead of AGENT_SHEET. To avoid backwards-compatibility
issues, the patch also wraps the stylesheet content in a @layer to
ensure that all rules have a lower precedence than any (unlayered)
extension stylesheet.
The `browser.display.document_color_use` pref is also controlled
through the `browserSettings.overrideDocumentColors` extension API.
For extra test coverage, this patch sets the pref with that API
instead of setting the prefs directly.
Differential Revision: https://phabricator.services.mozilla.com/D198117
Renames all instances of the snake_case identifier to
camelCase to match more closely to idiomatic JavaScript
and to existing conventions throughout the code base.
Differential Revision: https://phabricator.services.mozilla.com/D198826
Renames all instances of the snake_case identifier to
camelCase to match more closely to idiomatic JavaScript
and to existing conventions throughout the code base.
Differential Revision: https://phabricator.services.mozilla.com/D198825
This patch modifies PlacesUtils to cache the keywords and adds functionality to
find a keyword. The Tokenizer calls PlacesUtils to know if the first word
is a keyword and if the first word is a keyword, then the rest of the search
string will be treated as text and Tokenizer won't filter any other restrict
symbols.
Differential Revision: https://phabricator.services.mozilla.com/D198208
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
Calling window.restore will return the window to its previous
dimensions. Prior to this patch, extension windows transitioning to
normal state would add a second step where they would forcibly resize
the window to content. The motivating reason for this additional step is
some kind of difficulty with macOS windows restoring from other states.
Those issues were handled comprehensively in Bug 1631735, and now the
extra step is unnecessary and surprising to users. Since the call was
being made potentially during a deminimization native transition, the
window is at a very small size and expanding it to fit the content is
resizing it to a strange small size. Window.restore will do the right
thing, so this patch stops calling sizeToContent.
Differential Revision: https://phabricator.services.mozilla.com/D189972
There are 2 failing test cases in `browser/components/extensions/test/browser/browser_ext_browserAction_popup_preload.js` for the `html:body` that are sending clicks to a `<body>` element to dismiss the pending popup using an alternative way of the popup dismissal, where the other way like `Esc` key is available, therefore these two test clicks can be excluded from the a11y_checks.
Another test cases are in `browser/components/extensions/test/browser/browser_ext_menus_capture_secondary_click.js` that are clicking on the `<menu>` parent container to confirm the click event is not going to be triggered for the attached menu items, thus these clicks are also excluded from the a11y_checks.
These actions are not expected or do not have to be done by a user of an assistive technology and we do not have to confirm the accessibility of these elements.
Thus, we are excluding these click events from accessibility checks.
Differential Revision: https://phabricator.services.mozilla.com/D193574
We intentionally turn off a11y_checks for these click events, because the clicks in the patch are targeting disabled controls to confirm the click events won't come through. These clicks are not meant to be interactive and are not expected to be accessible.
Thus, we are excluding this click event from accessibility checks and removing the fail-if annotation that was added by bug 1854460 before the investigation in the meta bug 1854461.
Differential Revision: https://phabricator.services.mozilla.com/D193329
