This patch:
-Maintains consistency between the fxa and remote tabs' panels "sync now" buttons
-Removes a fluent string no longer in use
-Restores tooltip functionality
Differential Revision: https://phabricator.services.mozilla.com/D106651
Let the front end part relies on the report Id only, because on Gecko side (`DecoderDoctorDocumentWatcher`) we've already done the check to determine if that notification should be reported on current platform.
Differential Revision: https://phabricator.services.mozilla.com/D106682
This patch:
-Maintains consistency between the fxa and remote tabs' panels "sync now" buttons
-Removes a fluent string no longer in use
-Restores tooltip functionality
Differential Revision: https://phabricator.services.mozilla.com/D106651
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
FillHistoryMenu was returning early and preventing the context menu from opening when there is only one history item. For long-presses, the menu typically doesn't open until after the updateSessionHistory callback was finished so the menu shows properly, but context menus have no delay. However, when browsingContext.sessionHistory is available, we can get the history without callbacks.
Also, combine the two similar session history tests into one more complete test.
Differential Revision: https://phabricator.services.mozilla.com/D106694
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