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
`sender.frameId` should be set iff `sender.tab` is set, as documented at
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/MessageSender
The removal of the `viewType == "tab"` condition broke this in
https://hg.mozilla.org/mozilla-central/rev/2dc4f1baccc8
This patch makes the presence of `frameId` conditional on `tab`, and
fixes several tests that relied on the incorrect behavior:
- Move the runtime.onConnect test from test_ext_contentscript_in_background.js
to a new mochitest at test_ext_runtime_connect_iframe.html.
- Simplify test_ext_contentscript_in_background.js to continue to
provide test coverage for contentScripts.register + allFrames.
- Replace runtime.onConnect with runtime.getFrameId in
test_ext_contentscript_xorigin_frame.js, since sender.frameId is no
longer available in xpcshell tests (because internals to support the
tabs extension API are not available in xpcshell tests). The test
cannot be moved to a mochitest because its purpose is to provide test
coverage for process switching in a xpcshell test (bug 1580811).
Differential Revision: https://phabricator.services.mozilla.com/D135057
`sender.frameId` should be set iff `sender.tab` is set, as documented at
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/MessageSender
The removal of the `viewType == "tab"` condition broke this in
https://hg.mozilla.org/mozilla-central/rev/2dc4f1baccc8
This patch makes the presence of `frameId` conditional on `tab`, and
fixes several tests that relied on the incorrect behavior:
- Move the runtime.onConnect test from test_ext_contentscript_in_background.js
to a new mochitest at test_ext_runtime_connect_iframe.html.
- Simplify test_ext_contentscript_in_background.js to continue to
provide test coverage for contentScripts.register + allFrames.
- Replace runtime.onConnect with runtime.getFrameId in
test_ext_contentscript_xorigin_frame.js, since sender.frameId is no
longer available in xpcshell tests (because internals to support the
tabs extension API are not available in xpcshell tests). The test
cannot be moved to a mochitest because its purpose is to provide test
coverage for process switching in a xpcshell test (bug 1580811).
Differential Revision: https://phabricator.services.mozilla.com/D135057
`sender.frameId` should be set iff `sender.tab` is set, as documented at
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/MessageSender
The removal of the `viewType == "tab"` condition broke this in
https://hg.mozilla.org/mozilla-central/rev/2dc4f1baccc8
This patch makes the presence of `frameId` conditional on `tab`, and
fixes several tests that relied on the incorrect behavior:
- Move the runtime.onConnect test from test_ext_contentscript_in_background.js
to a new mochitest at test_ext_runtime_connect_iframe.html.
- Simplify test_ext_contentscript_in_background.js to continue to
provide test coverage for contentScripts.register + allFrames.
- Replace runtime.onConnect with runtime.getFrameId in
test_ext_contentscript_xorigin_frame.js, since sender.frameId is no
longer available in xpcshell tests (because internals to support the
tabs extension API are not available in xpcshell tests). The test
cannot be moved to a mochitest because its purpose is to provide test
coverage for process switching in a xpcshell test (bug 1580811).
Differential Revision: https://phabricator.services.mozilla.com/D135057
This is almost a revert of bug 1741089 (just with the relevant test fix
and so on). With the previous patch, for something like:
<menupopup>
<menuitem />
</menupopup>
We would still generate the frames for the menuitem. That causes various
a11y tests to fail and starts loading images used by the menuitem which
was caught by browser_startup_images.js.
Make the children completely invisible to layout by keeping them
unslotted. This makes getComputedStyle on them return an empty style,
but only one test was depending on that.
Depends on D134331
Differential Revision: https://phabricator.services.mozilla.com/D134606
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Depends on D130820
Differential Revision: https://phabricator.services.mozilla.com/D122392
Make popup browsers non-transparent so that we can get a meaningful
canvas background-color from layout. I don't think it matters since
popups are not meaningfully transparent since bug 1449933.
Depends on D133772
Differential Revision: https://phabricator.services.mozilla.com/D133773
This patch includes a new test file to cover a scenario similar to the one
fixed in Bug 1735899, and possibly some other similar ones that may slip
through unnoticed.
This test triggers the issue consistently on a build where the fix
is not included and pass consistently in build including the fix,
but even if it doesn't include any arbitrary timeouts to trigger the
issue there is still a chance that the test may start to fail
intermittently for some other reasons.
Keeping it as a separate test file will make it easier to disable it
as a temporary measure if turns out to be necessary.
Differential Revision: https://phabricator.services.mozilla.com/D132267
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
