This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This was more difficult to solve than I expected. The main issue is that the
`[open]` attribute on `#urlbar` wasn't accurate when the view was "open" but
there were no results or one-offs, so it was in fact closed. This broke a few
style rules.
This bug can also be reached when the user has no engines and clears the search
string while in search mode. This includes pressing Accel+K when typing a search
string while not in search mode.
The relationship between the UrlbarView and the one-offs is complex and depends
on a lot of listeners and async calls made in synchronous contexts. Furthermore,
most of the UrlbarView open/close code is synchronous, but checking the number
of engines (to determine if the one-offs will open) is an async operation. These
factors make it difficult for the view to discern any state about the one-offs
and plan accordingly.
First I tried adding a [oneoff] attribute to .urlbarView, set asynchronously when
the one-offs are built. Then I changed CSS rules to check
```
.urlbarView:not([noresults]),
.urlbarView[oneoffs]
```
instead of just `#urlbar[open]`. This approach would've required changing
a bunch of CSS from the simple `#urlbar[open]` to the more complicated CSS
above, which was not good for code readability. Also it would keep `[open]` in
a weird useless state where it couldn't really be trusted. This would've caused
other styling problems.
I settled on adding a `.then` call around the affected UrlbarView opening. The
view opens only if we are sure that we will have either results or one-offs,
so we can once again trust the `[open]` parameter. This approach has its
drawbacks. Mainly, it's a more JavaScript-heavy solution so it's possibly
slow. Thankfully, it's something that can be easily cached.
Differential Revision: https://phabricator.services.mozilla.com/D92526
This patch adds support for key modifiers on the refreshed one-offs. They work the same as the old key modifiers, with one exception: Shift+Click and Shift+Enter both execute a search immediately in the current tab, replicating the behaviour of the old one-offs. For empty searches, Shift+Click and Shift+Enter just enter search mode. To support these Shift modifiers, we dropped support for opening a one-off search in a new window. Users can still search in a new window with a non-default engine by typing a search string, selecting a one-off with the keyboard, then Shift+Clicking the heuristic result or the Go button.
Other key modifiers worth pointing out include Accel+Click to search in a new background tab and Alt+Enter to search in a new foreground tab. If these modifiers are used on the local one offs or with an empty query, we open search mode in the new tab.
Differential Revision: https://phabricator.services.mozilla.com/D89504
This is a narrow fix to the bug, which happens because I removed this
conditional in bug 1654439: https://hg.mozilla.org/mozilla-central/rev/f561eb606ad3#l1.251
That conditional kept the selection out of the one-offs when the urlbar hid
them. This patch replaces that conditional with a version that can be overridden
by the urlbar subclass. It adds a `hasView` getter that is equivalent, but note
that `this._view` can't be used because the urlbar subclass sets `this.view` in
its constructor and never nulls it out, unlike the original implementation. So
instead the subclass `hasView` checks whether the one-offs are hidden. This is
effectively the same thing because in the old implementation the urlbar one-offs
were hidden at the same time `this._view` was nulled out.
Differential Revision: https://phabricator.services.mozilla.com/D86293
The test intermittently fails because sometimes `tooltiptext` is not set when
the engine has an alias. For engines with aliases, we set l10n attributes on
their button elements instead of setting `tooltiptext` directly.
At first I thought that the l10n machinery is setting `tooltiptext` asyncly so
that it's sometimes not set when the test checks for it. So I added a
`waitForCondition` in [this try push](https://treeherder.mozilla.org/#/jobs?repo=try&revision=049b44c1bb97e1e8bc11dc464a57ca4b85781246&selectedTaskRun=GXE1b3XAQeaPI7ExPDwQXg.0).
But there was still one failure out of 11 runs. This time the `waitForCondition`
timed out. So there seems to be something more going on. (I also added a check
for the l10n attributes before the `waitForCondition` call, and that check
passed.)
This patch just has the check for the l10n attributes without the `tooltiptext`
check when the engine has an alias. I don't think it's worth spending more
cycles on this.
Differential Revision: https://phabricator.services.mozilla.com/D85958
