browser_ext_browserAction_popup_resize.js was permafailing for me locally, even without the other changes part
of this issue, that was more annoying than usually because I wanted to be sure that the changes for the browserAction
persistent listeners were not breaking any of the existing tests but it was tricky without being able to see the
test to pass consistently also when running locally.
The reason behind the failure was a 1px difference in width for the browserAction popup.
Given that the tests in browser_ext_browserAction_popup_resize.js were already being tollerant
elsewhere about a 1px difference between the dimensions of the content compared to the dimensions
the test case was expecting, it seems reasonable to apply a similar tollerance in the
test helper used to wait for the content dimentions to reach a given set of expected dimentions
and make this test able to pass consistently when running locally.
Differential Revision: https://phabricator.services.mozilla.com/D141663
This allows themes to override our light / dark theme heuristics if they
choose to, so that we don't have to complicate the heuristics too much.
This is specially useful for themes with images, where the image might
be "light", but still have enough contrast with light text. A good
example is the theme mentioned in bug 1749837 comment 0.
The semantics are:
* color_scheme: If set, overrides the general "toolbar theme" (so
window and context menu appearance and so on), otherwise we fall back
to heuristics.
* content_color_scheme: If set, overrides the color scheme for the
content area. Otherwise we fall back to color_scheme if present, or
heuristics otherwise.
One thing that I didn't include was a sort of "system" option, which
might be useful to say "this theme is neutral, and works both for light
and dark themes". Let me know if you think that's a must-have, otherwise
I think it's probably worth deferring to a follow-up if it's needed at
all.
Differential Revision: https://phabricator.services.mozilla.com/D136354
PathUtils.filename throws if the path is not an absolute path, which was likely
not the case with the OS.Path.basename call used previously.
This internal change of behavior shouldn't be triggering any issue on Windows,
where the hostInfo.manifest.path seems to be always normalized into an absolute
path (by computing it as relative to the hostInfo.manifest if it wasn't already
an absolute path), but it makes browser.pkcs11.isModuleInstalled to regress
on Linux (and maybe also on MacOS if the pkcs11 manifest files include only
the library name and not its full path, as it seems to be the case for
the Belgium eID pkcs11 manifest packaged for Linux).
The result of PathUtils.filename is expected to only include the basename of
the file (without the full dir path and the file extension) and so to fix
the regression being triggered on non-windows platform we could use a fake
absolute url to get the expected result using PathUtils.filename as is.
Differential Revision: https://phabricator.services.mozilla.com/D141097
In bug 1678611, the id property was added to this event, without unit
tests. The existing test didn't pick up the change because it checked
for a specific property. This patch adds a check of the whole event
object to get coverage for the id property AND to avoid this kind of
issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D139408
If elements added to the doc were not visible, context-click on
the element would fail because composedTarget.ownerDocument is null.
Differential Revision: https://phabricator.services.mozilla.com/D138190
This adds a block button to best match rows. The button looks similar to the `?`
help button. For best match rows, both the block and help buttons appear, with
the block button first.
Figma spec, see "Top pick proposal
for Firefox 99 - awesomebar":
https://www.figma.com/file/seJ2ZA4v3FgoV7jCxUR74B/Firefox-Suggest?node-id=4937%3A67136
This does not handle clicks on the button because that will be covered by bug
1754591 and bug 1754594.
To test this, the easiest way is still probably to pause browser_bestMatch.js.
You can use the `nonsponsored()` task to test the block button by itself and
`nonsponsoredHelpButton()` to test with a help button; pause before the
`promisePopupClose()` at the end. If that's not practical I can post my WIP for
triggering best matches and you'll need to enable Firefox Suggest too.
To implement this I generalized the existing help button code into a way to add
arbitrary buttons. Instead I could have duplicated it, but that's not as nice
and it makes the CSS a little uglier because we'd need rules for handling the
help button alone, the block button alone, and both (although there are no plans
to show the block button alone). In addition, eventually we want a way to report
inappropriate suggestions so there's been discussion about having a report
button too. It may turn out that we add a single `...` button for everything,
but it's not clear yet.
I tweaked the button style a little to match the new spec. Help buttons in the
usual Firefox Suggest rows will get these tweaks too of course. The help button
(and block button) are now smaller, have smaller margins, and their hover
background color is the same as the color for rows.
Finally, I noticed we're not correctly updating `item[role]` when reusing a row
and going from without a help button to with a help button, or vice versa, so
this fixes that too.
Differential Revision: https://phabricator.services.mozilla.com/D138508
If elements added to the doc were not visible, context-click on
the element would fail because composedTarget.ownerDocument is null.
Differential Revision: https://phabricator.services.mozilla.com/D138190
This patch contains a proposed approach for the longer term fix we agreed on (see Bug 1746841 comment 10 and comment 11) and replace the
mochitest-browser added in the other patch attached to this bug with an xpcshell test (which besides covering the same base scenario
that mochitest-browser was convering, it is also lighter and covers also other cases that were not explicitly covered yet).
- added also an image to the test extension to explicitly verify the image caching behavior is also covered and works as expected
- added a test case to verify that cache images aren't cleared when the addon is permanently installed and it is not starting for an upgrade/downgrade
Differential Revision: https://phabricator.services.mozilla.com/D134508
