Updated the summary with the standard template. Hid all files in favor of the MR.
I don't know what the best way to go about this is but I have a tiny css update that fixes it while a final fix is put together. Sharing it here as a shim until something official is decided.
A clean install of d 9.* with 4.1 on claro is working, assuming the patch from the linked module is applied. Are you using a different admin theme?
The issue was introduced in the coding standards update, the anonymous function to lambda swap was likely flagged in one of the automated tools.
commit 0e023524be0d6efd063f68871cede70c23f27b47
Issue #3338336: Javascript coding standards (uninstall, permissions, update status)I just spun up a simplytest.me instance on 9.5.11 with module filter 4.1.0 and the no test patch from #6 and have no issues using the filters on the update status page. This patch should fix the issues on 9 as well as 10, the patch in 17 tests cleanly against 9 and 10.
@jonathan1055 Thanks for the review and especially the pointer about the screenshots, that was key to figuring this one out. As an aside, is there a way to dump console errors from a running test? That would have made finding the culprit here much easier.
This was a bit of a rabbit hole. The issue ended up being an undeclared dependency on the once library killing the entire bind on the update status page. Adding that dependency allowed the winnow bind to fire and the tests started clearing. I added the dependency to all libraries that use it.
The show test is correctly failing when I remove the original fix, reapplying the fix allows the test to complete with no issues.
I moved the show test from its own method into the main test method, it looks like tests are combined like this in the core tests I was using as a reference.
I'm clearly doing something wrong trying to push these updates to the merge request so I'm uploading another patch. The patch following naming conventions is the full issue patch, the txt file is the updates to the merge request.
Fixed the coding standard errors and added the fix for this issue into the patch to see if the filter change will succeed. I'm getting a failure in testUpdateStatusPageTextFiltering that doesn't make sense to me.
It mimics the behavior in the other tests by updating the text filter and looking to see if the Drupal Core listing has disappeared. Dumping the value of the field shows that the field value matches what was set, and testing that value in the browser behaves as expected. Assuming this fails in that method again I would appreciate it if someone with more experience in writing browser unit tests could take a moment to review.
My first shot at a browser test for the updates page. This patch does not include the fix for this ticket and should fail in testUpdateStatusPageUpdateShowChange. I'm getting odd behavior while testing locally, checking the test bot to see if it agrees or is something is wrong on my side.
@jonathan1055 sounds good, I have a ticket up with a quick patch and green tests that should allow this patch to get through once it's on dev.
Updated based on similar constructor found in core tests.
wolffereast → created an issue.
Am I reading the failure correctly that there is an issue in the test that is not related to this ticket? It looks like it's a quick update to the form class instantiation, though I don't have phpunit running yet to fire the test off locally. I'm not seeing a separate ticket, would that be helpful? This is similar to what I am seeing in some of the ConfigFormBase Tests in core.
diff --git a/docroot/modules/contrib/module_filter/tests/src/Kernel/Form/ModuleFilterSettingsFormTest.php b/docroot/modules/contrib/module_filter/tests/src/Kernel/Form/ModuleFilterSettingsFormTest.php
index f8d62f514..bd5ef7cf6 100644
--- a/docroot/modules/contrib/module_filter/tests/src/Kernel/Form/ModuleFilterSettingsFormTest.php
+++ b/docroot/modules/contrib/module_filter/tests/src/Kernel/Form/ModuleFilterSettingsFormTest.php
@@ -27,7 +27,8 @@ protected function setUp(): void {
parent::setUp();
$this->moduleFilterSettingsForm = new ModuleFilterSettingsForm(
- $this->container->get('config.factory')
+ $this->container->get('config.factory'),
+ $this->container->get('config.typed')
);
}
I managed to find a local on 9.5.11 and updated Module Filter to 4.1 with the patch in the linked issue. I'm on Claro in this environment. I'm able to use the toggles and text filters on the upgrade status page. I tried with aggregated and unaggregated resources just in case. Am I missing a step to reproduce, or is it possibly an issue with a specific admin theme?
I just dropped a patch in https://www.drupal.org/project/module_filter/issues/3413467#comment-1539... 🐛 Radio buttons on Available updates report do nothing Active that should fix the status page issue reported there but I don't have a 9.* locally to test if it helped this issue as well. Can someone give it a go?
This was caused by a change in the `this` scope between the anonymous function and the lambda function. In the anonymous function `this` is the currently selected input, in the lambda function `this` is the attach abject. Adding the event argument and using the current target correctly pulls the currently selected input and allows the function to behave as it used to.
I'm testing this in 10.1.7 prior to upgrading to 10.2