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
This also fixes a potential problem when deduping SERPs against form history:
We're creating SERP URLs based on the lowercased version of SERP terms instead
of the terms as is. That means we won't detect example.com/?q=foo and
example.com/?q=FOO as being dupes, but I think we should.
I updated the test to check for leading/trailing spaces as well as case.
Differential Revision: https://phabricator.services.mozilla.com/D107164
We enable compilation of FOG/Glean on _all_ platforms.
We disable Glean initialization and metric recording on Android (GeckoView) by respecting MOZ_GLEAN_ANDROID.
This way GeckoView just works, consumers don't need to think about it (except in tests, these need to be disabled for Android builds).
Stubbing out the metric implementations will happen in the commits after
this one.
Differential Revision: https://phabricator.services.mozilla.com/D106766
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 fixes the two a11y problems with quick suggest results:
* When their help button is present, they aren't recognized as a listbox
option. That has a couple of consequences: They aren't read as an "<index> of
<size>" option, and they're read as an autocompleted URL instead of their
title.
* Their help button is read as its URL instead of its label. (The button has a
URL that's loaded when you click it.)
Fixing the second problem is easy, just give the help button an ID.
The first problem is trickier. It's due to the fact that when the help button is
present in the actual row, the "logical" row -- the part that's selectable and
looks like the main part of the row -- is not the row itself but rather one of
its children. So the rows container with `role=listbox` doesn't have the
selectable part as a direct child. To fix that, I added `role=option` to the
selectable part and `role=presentation` to the row itself.
Aside from these fixes, another possibility is to include the row's help button
as an option too, instead of as a button. I chose not to do that because it's
really a button and not a row/result, and also we have precedent with tip
results, which have similar buttons that we treat like this.
Note that the help button is *not* read on hover, only when keyboard selected.
That's a known bug we encountered in tips or interventions, but I can't find the
bug.
Depends on D106559
Differential Revision: https://phabricator.services.mozilla.com/D106712
In bug 1589102, changes were made to how about:blank and about:srcdoc load,
making them go via DocumentChannel and thus slightly increasing documents' load
times. This causes some timing issues in SessionStore code.
When we click to "Reopen all (closed) Windows", undoCloseWindow() is called for
each window that we have to restore. The following scenario can occur - we are
restoring window 1, and undoCloseWindow() has already called restoreWindows,
after receiving the window showing promise, and in the meantime
undoCloseWindow() has been called for window 2, and there is now a promise in
the WINDOW_SHOWING_PROMISES. But now restoreWindows() for window1 calls
_openWindows(), where root.windows length is 0, but WINDOW_SHOWING_PROMISES is
not empty (because of window 2's undoCloseWindow), and the resolve callback for
_openWindows() gets called with wrong arg. To solve this, ensure that the
promises returned from _openWindows() correspond to the windows opened
within the body of the function.
Differential Revision: https://phabricator.services.mozilla.com/D106304
toolkit/components/search/tests/xpcshell/test_notifications.js and the test_opensearch* tests already test this functionality. There's nothing extra gained by running this as a mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D105030
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
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
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
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This skips setting `.urlbarView-url` text content for quick suggest results. The
other option is to keep setting it like we do now, but set `display: none` on it
in the CSS. The first option seems better since quick suggest results don't ever
show their URLs, so it seems wrong to treat them like they do and to set the
`has-url` attribute. My patch to bug 1694723 also depends on QS results not
having `has-url`.
This also fixes the bug of course.
Differential Revision: https://phabricator.services.mozilla.com/D106550
Allows to perform the search in a new foreground/background tab or
a new window using modifiers or middle mouse button.
Introduces a certain level of consistency with other entries in
the context menu, like navigation and "view image".
Differential Revision: https://phabricator.services.mozilla.com/D103354
This adds event telemetry that's recorded when the
`browser.urlbar.suggest.quicksuggest` pref is toggled. This pref corresponds to
the checkbox in about:preferences#search labeled "Show suggested and sponsored
results in the address bar".
I used `contextservices.quicksuggest` as the event telemetry category name to be
similar to the `contextual.services.quicksuggest.*` scalars. Event names are
limited to 30 chars, so it couldn't be exactly the same.
This is based on my earlier revision for scalar telemetry in D106173.
Depends on D106173
Differential Revision: https://phabricator.services.mozilla.com/D106248
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
This adds event telemetry that's recorded when the
`browser.urlbar.suggest.quicksuggest` pref is toggled. This pref corresponds to
the checkbox in about:preferences#search labeled "Show suggested and sponsored
results in the address bar".
I used `contextservices.quicksuggest` as the event telemetry category name to be
similar to the `contextual.services.quicksuggest.*` scalars. Event names are
limited to 30 chars, so it couldn't be exactly the same.
This is based on my earlier revision for scalar telemetry in D106173.
Depends on D106173
Differential Revision: https://phabricator.services.mozilla.com/D106248
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
This adds event telemetry that's recorded when the
`browser.urlbar.suggest.quicksuggest` pref is toggled. This pref corresponds to
the checkbox in about:preferences#search labeled "Show suggested and sponsored
results in the address bar".
I used `contextservices.quicksuggest` as the event telemetry category name to be
similar to the `contextual.services.quicksuggest.*` scalars. Event names are
limited to 30 chars, so it couldn't be exactly the same.
This is based on my earlier revision for scalar telemetry in D106173.
Depends on D106173
Differential Revision: https://phabricator.services.mozilla.com/D106248
This adds three new keyed scalars:
* `contextual.services.quicksuggest.impression`: Incremented when a Quick
Suggest result is shown in an address bar engagement where the user picks any
result.
* `contextual.services.quicksuggest.click`: Incremented when the user picks a
Quick Suggest result (not including the help button).
* `contextual.services.quicksuggest.help``: Incremented when the user picks the
onboarding help button in a Quick Suggest result.
The changes to telemetry.rst and Scalars.yaml have more details.
I modified `TelemetryEvent.typeFromElement()` to return `"help"` for clicks on
the help button so that the quick suggest provider can tell whether the main
part of the result was picked or the help button. I left `"tiphelp"` for tip
help buttons in case anything depends on that.
Depends on D106060
Differential Revision: https://phabricator.services.mozilla.com/D106173
This patch mainly does three things:
1. Changes the necessary CSS to meet the Proton spec.
2. Removes several calls to UrlbarInput.startLayoutBreakout(), because the Urlbar no longer expands when the panel is not open.
3. Introduces a [suppress-focus-border] attribute. This attribute hides the 2px focus ring around the Urlbar. This ensures that we don't flash the focus ring when the user clicks a Urlbar that will autoOpen, seeing as the open Urlbar no longer has a border. It also hides the focus border after the user presses Esc, as specified in Figma.
Differential Revision: https://phabricator.services.mozilla.com/D105097
With adding new feild to the `aParam`, `synthesizeNativeMouseClick` can
work as `synthesizenativeMouseClickAtCenter` too. Therefore, we can get
rid of the redundant API.
Additionally, this patch makes `synthesizeNativeMouseClickWithAPZ` can
take the new field for consistency between them.
Differential Revision: https://phabricator.services.mozilla.com/D105756
I'm keeping the generic 'animate' selectors which are still used for the bookmark/star animation.
This should make it easier to add other animations to the library in future, if that
ends up useful, and making them more specific to the star animation doesn't seem like it gains
us anything. The de-duplication from bug 1393565 helps a lot here.
Differential Revision: https://phabricator.services.mozilla.com/D106153
There are a couple of things that would make collecting engagement telemetry
like impressions and clicks a lot easier: having the query context and details
of the picked result. We need to collect this exact telemetry for the top sites
and quick suggest experiments. For quick suggest in particular, we need the
index of the quick suggest result for the impression telemetry. There's no good
way to get that right now because although the quick suggest is always last, the
index depends on the muxer and the number of final results.
Details of the picked result is easy because there's already a `details` object
with that info when the controller's telemetry event tells the providers manager
to notify providers of an engagement.
The query context is a little harder, but we can take it from the controller.
It's not guaranteed to be defined at the time that `onEngagement` is called for
`start`, so I tried to make that clear in the javadoc. Since it may not be
defined on `start`, `onEngagement` still needs the `isPrivate` param even though
the context also has an `isPrivate` property.
With this patch, we should be able to record clicks in providers without having
to call `pickResult` for every provider. `pickResult` would be the other obvious
place to record picks on results in providers.
Depends on D105815
Differential Revision: https://phabricator.services.mozilla.com/D106060
This was a little more work than I first thought because fixing it uncovered
another problem: The recurse logic in the muxer isn't quite right. There are a
couple of problems actually:
1. By re-using the results from children that did not fill up, we skip updating
`stateCopy` (and therefore `state`), which messes up subsequent buckets in
the recursion because they're working with the wrong state.
2. By simply assigning `state = stateCopy` after handling children that didn't
fill up, we're not really doing anything because at that point the function
is done. The caller and subsequent buckets in the recursion won't see the
updated state. We need to update `state` in place.
These problems were revealed in test_resultBuckets.js, which is pretty thorough.
To fix the actual problem that the bug is about (not deduping remote suggestions
and form history), we just need to keep a set of suggestions that the muxer has
seen so far, and then `_canAddResult` can discard dupe suggestions. This patch
adds `state.suggestions` for that, and it includes form history, remote
suggestions, and the heuristic query when it's a search result. This way the
relative ordering of form history vs. remote suggestions doesn't matter. We'll
dedupe whichever comes later.
A bunch of tasks in test_resultBuckets.js needed to be updated to account for
this because they were incorrectly not expecting dupes to be removed.
Differential Revision: https://phabricator.services.mozilla.com/D106030
`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
### Story
When a COOP+COEP page is opened, we change the remoteness of the tab. After
changing the remoteness, the tab is then restored by its TabState. However,
we haven't collected userContextId through the current mechanism.
To fix that, this patch changes the way to collect userContextId.
### Test Plan
Test: D98296
Depends on D98296
Differential Revision: https://phabricator.services.mozilla.com/D98468
This is an unusual revision, but it adds a checkbox to the Search Suggestions
section of the Search pane for the urlbar Quick Suggest experiment, which is
en-US only. The checkbox is hidden by default and it's only shown if the
`browser.urlbar.quicksuggest.enabled` pref, which controls the experiment, is
true. Because this is an experiment and it's en-US only, I've hardcoded some
strings. Bug 1692518 has info on the experiment, and bug 1693345 has a
discussion about hardcoding strings.
The checkbox controls the new pref `browser.urlbar.suggest.quicksuggest`. It's
similar to the other existing `browser.urlbar.suggest.*` prefs.
There's a learn-more link but we don't know the final URL yet, so I'm using
mozilla.org. There's a TODO with a bug number.
We also want to change the Search Suggestions description when the experiment is
enabled. I've hardcoded that new string, too.
The test is pretty thorough and I started writing it before the new prefs
landed, so it doesn't assume the prefs exist or which branch they're on.
Differential Revision: https://phabricator.services.mozilla.com/D105701
The telemetry is triggered either when the user is shown the tab crashed page, or when the subframe notification is displayed and the crash occurs in an active tab, or when the user switches to a tab that has a subframe crash notification displayed. The telemetry only applies the first time the tab is switched to. The unsubmitted crashes notification bar appears after 10 minutes or so and is shown in the top-most browser window, if one exists, and telemetry applies once when this occurs.
Differential Revision: https://phabricator.services.mozilla.com/D100349
It turns out we're going to hardcode user-facing strings for the Quick Suggest
experiment, so help buttons need to allow their `title` attribute to be set
directly. This patch leaves `data-l10n-id` support because ultimately that's
what we'll want to use for non-experiment features. I didn't bother only setting
one or the other if both exist because we're never going to use both at the same
time, and it's not worth the code IMO.
Depends on D105095
Differential Revision: https://phabricator.services.mozilla.com/D105679
There is still some usages in isTargetSupported,
but that would requires refactoring this method into isDescriptorSupported
and be async as some isTargetSupported only works against target as it checks for traits on it.
Differential Revision: https://phabricator.services.mozilla.com/D105201
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
We previously had no tests for the default User-Agent string values, just for the spoofed values when resistFingerprinting is enabled!
Differential Revision: https://phabricator.services.mozilla.com/D99857
### Story
When a COOP+COEP page is opened, we change the remoteness of the tab. After
changing the remoteness, the tab is then restored by its TabState. However,
we haven't collected userContextId through the current mechanism.
To fix that, this patch changes the way to collect userContextId.
### Test Plan
Test: D98296
Depends on D98296
Differential Revision: https://phabricator.services.mozilla.com/D98468
The problem is that the test creates and registers many providers but never
unregisters them. Usually that's not a problem since test providers have random
names and test query contexts are created with the `providers` option. But
sometimes two different providers end up with the same name because
`Math.random() * 100000` ends up being the same. Therefore a context can end up
with two (duplicate) providers when there should be only one, which means
`context.results` ends up with two copies of each result.
This patch makes several changes:
* test_resultBuckets.js now unregisters providers.
* Stop using `Math.random()` as the basis for making random test provider
names. Instead, use UUIDs.
* Add a `registerCleanupFunction` in head.js for unregistering test providers
(even though that wouldn't have fixed this bug).
* Make `registerBasicTestProvider` return the provider instead of its name so
that the provider can be passed to
`UrlbarProvidersManager.unregisterProvider()`.
Differential Revision: https://phabricator.services.mozilla.com/D104929
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
Summary of changes:
* Replace the `matchBuckets` pref with `resultBuckets`.
* `resultBuckets` stores a JSON'ed root result bucket object. See the big
javadoc above `makeResultBuckets` in UrlbarPrefs for details.
* Convert existing result groups to more granular groups. This lets us remove
the heuristic-ordering logic in the muxer. It also lets us fix a subtle
inconsistency with regard to remote suggestions and form history; see the
removal of the two comments that start with "Note that the second form history
result appears after the remote suggestions" and "Note that the remote
suggestions appear in between the two form history results" in
test_search_suggestions.js.
* Unlike `matchBuckets`, `resultBuckets` stores *all* buckets, including the
heuristic at the beginning. Modify the muxer so that it discards heuristic
results that are not the first result.
Depends on D103137
Differential Revision: https://phabricator.services.mozilla.com/D99281
