Depends on D107099
With the previous patch, we are waiting for toolbox open before creating contexts.
This makes some tests a bit racy if they are only waiting for toolbox open. They should also wait for the context to be ready.
Firing an event from the devtools_page seems to work fine for this but don't hesitate to suggest a better approach.
Differential Revision: https://phabricator.services.mozilla.com/D107100
Depends on D107099
With the previous patch, we are waiting for toolbox open before creating contexts.
This makes some tests a bit racy if they are only waiting for toolbox open. They should also wait for the context to be ready.
Firing an event from the devtools_page seems to work fine for this but don't hesitate to suggest a better approach.
Differential Revision: https://phabricator.services.mozilla.com/D107100
Per conversations with Bas, we want the behavior for slow extensions to match
that of slow content scripts WRT requiring user input. The test change is less
than great, but I don't think we have the ability to simulate input in
mochitests without running JS in the content process? But correct me if I'm
wrong.
Differential Revision: https://phabricator.services.mozilla.com/D107521
The patch for bug 1498432 will include a unit test that uses
tabs.onUpdated with the "url" filter for "properties".
The updated test here verifies that the tabs.onUpdated event does not
include other properties in changeInfo when filtering by "status".
Differential Revision: https://phabricator.services.mozilla.com/D106733
The patch for bug 1498432 will include a unit test that uses
tabs.onUpdated with the "url" filter for "properties".
The updated test here verifies that the tabs.onUpdated event does not
include other properties in changeInfo when filtering by "status".
Differential Revision: https://phabricator.services.mozilla.com/D106733
While using -moz-os-version selectors in a shared CSS file isn't ideal, I think it's the best approach here. These selectors will hopefully be temporary, and will be removed when bug 1695280 is fixed. I considered a creating a ruleset like
```
@media (-moz-os-version: windows-win7),
(-moz-os-version: windows-win8) {
#navigator-toolbox:-moz-lwtheme {
background-color: unset;
}
:root:-moz-lwtheme {
background-color: var(--lwt-accent-color);
}
}
```
in browser/themes/windows/browser.css, but I think unsetting the background-color could become a headache if we need to make any other changes to the #navigator-toolbox background. We could also move these background rules to platform-specific stylesheets, but that way they're defined much later in the CSS despite being fairly foundational rules. It would also create more code to remove in bug 1695280.
Differential Revision: https://phabricator.services.mozilla.com/D106670
This patch removes the wait button on the slow script warning, on the suspicion
that it is confusing to the user since it's redundant with the close button. It
also changes the text of the notification to blame the hanging tab.
Differential Revision: https://phabricator.services.mozilla.com/D106015
tab.hasTabPermission indirectly triggers an access to
browser.currentURI, which for lazy tab browsers causes an incorrect
value to be cached. To avoid this, skip the call to hasTabPermission.
Differential Revision: https://phabricator.services.mozilla.com/D106622
`appearance` CSS rules allow elements to take on system appearance. For UI elements that we want to take on system styling, we set `appearance: auto` combined with platform-specific rules like `-moz-default-appearance: -moz-mac-vibrant-titlebar-light;`
macOS sidebar vibrancy broke because a background-color was being applied to `root`. That colour appeared under elements with `appearance: auto` set, so we wouldn't see the platform-specific styling. This patch moves the root background-color to `#navigator-toolbox`, so that it does not appear under `#sidebar-box`.
We still want a background colour applied to sidebars when a lwtheme includes one. We only want `appearance: auto` applied to sidebars when the active theme does not have sidebar styling rules. That's why `#sidebar-box:not(:-moz-lwtheme)` is changed to `#sidebar-box:not([lwt-sidebar])`.
This patch also removes the rule
```
:root:-moz-lwtheme {
appearance: none;
}
```
from osx/global/global.css. There's no corresponding addition of a `#navigator-toolbox { appearance:none; }` rule because that rule already exists in [osx/browser.css](https://searchfox.org/mozilla-central/rev/7067bbd8194f4346ec59d77c33cd88f06763e090/browser/themes/osx/browser.css#45).
Differential Revision: https://phabricator.services.mozilla.com/D104416
This supports a new `helpUrl` payload property on all results. It causes results
in the view to have a help button that can be selected and picked independently
of the main part of the result. When picked, the help button loads the
`helpUrl`. It looks and acts the same as the help buttons we already have for
tip results.
The help button should be flush with the trailing edge of the result row, and it
should be selectable independently from the main part of the result. To achieve
that without disrupting things too much, I create the button inside of
`.urlbarView-row` but outside of `.urlbarView-row-inner`. The "main" part of the
row is `.urlbarView-row-inner`. I made `.urlbarView-row` have `display: flex` so
the the inner part can have `flex: 1` so it can fill up the entire row except
for the help button.
This also reworks view selection a little so that for each row, we look for
selectable elements in the row instead of assuming that the row itself is
selectable. That also lets us remove a couple of special cases for tip and
dynamic results.
Differential Revision: https://phabricator.services.mozilla.com/D105095
Credits to Jonathan Mayer for submitting the original patch.
The patch changes the onFocusChanged extension event handler
so that it no longer bails out if focus is moving to a private
window, ensuring that the onFocusChanged event gets generated
with the proper WINDOW_ID_NONE identifier.
Differential Revision: https://phabricator.services.mozilla.com/D104732
The urls where an OpenSearch engine can be loaded from are already limited in LinkHandlerChild. This is cleaning up and simplifying what the OpenSearchEngine allows, and as a result allows the load path handling to be greatly simplified.
The test changes are due to no longer allowing chrome or file protocols. For future, we probably want to move away from OpenSearch for most of these, but the changes will make it easier to find the places to update.
Differential Revision: https://phabricator.services.mozilla.com/D104010
- Moved aboutaddons.html at the root of the about:addons page
- renamed aboutaddons.js `initialize` global function to `initializeView` (and renamed `show` and `hide` global functions accordingly)
- Simplify initial load logic a bit more:
- remove gCategories
- moved responsability of the CategoriesBox initialization to the `initializationView` function
- replaced initialization logic based on `gPendingInitializations` and `notifyInitialized` with
a `promiseInitialized` global resolved when `initializeView` method has been called and its return value resolved
- Fix test helpers and test failures
- InlineOptionsBrowser: take into account that browser-custom-element does opt-in the delayedConnectedCallback behavior
and browser.loadURI may throw if called while the document is still loading.
Differential Revision: https://phabricator.services.mozilla.com/D96472
