Adding a test turns out to be difficult. To test that the popup extension does not show a popup we have to somehow enable the relevant gadgets (and also the extension). We can not easily mock the gadgets, because the functions conflictsWithNavPopupsGadget() and conflictsWithRefTooltipsGadget() actually do check if there is a gadget installed. This would mean providing an even more complicated setup.
An alternative to mock the gadgets would be adding a cookie in the js test and reading it in conflictsWithRefTooltipsGadget() to set this variable to true in the test scenario. This would make the code kind of ugly and as this is not a beta feature it would have to stay permanently. But the alternative - installing the gadget on the CI during the test - would slow down the test and might be equally bad. We’re a bit torn here.
One exotic alternative is to test in the browser test case setup that a conflicting gadget is installed. This positive test would be skipped in normal CI (we can still run the negative test "does not suppress when gadget disabled"). Then, we "permanently" enable a conflicting gadget on the beta cluster and run a daily job targeting beta. Both cases can also be run locally by toggling the gadget. This is dirty, but does give us automated coverage of both code paths.