Closed (fixed)
Project:
Module Filter
Version:
4.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Jan 2024 at 11:37 UTC
Updated:
26 Jan 2024 at 12:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jonathan1055 commentedIt is to do with admin access permissions being tightend up between core 10.1 and 10.2
I have seen this in the last two weeks:
#3409652: Failing phpunit test: h1[text() = "Administration"] not found
#3409743: Access permission to /admin/ changed between 10.1 and 10.2
Adding permission 'use administration pages' should fix it.
Comment #4
jonathan1055 commentedThe permission was not the problem. I think it is failing the phpunit job because the core patch from #2895388: Modules uninstall filter does not filter by machine name is for 10.2 and it does not apply at core 10.2
That should be fixable, becuase there is a 10.2 MR on that issue too.
Comment #5
jonathan1055 commentedOK its not anything to do with permissions. The browser output artifacts show that the permissions page is being shown initially, with all permissions. But when entering the first filter values it matches with nothing, hence the test failure.
I suspect that some form classes have been changed from 10.1 to 10.2 for the theme being used in the javascript test.
Comment #6
jonathan1055 commentedThe drupalci test pases, because it is being run at core 10.1. The pipeline is on 10.2
Comment #7
jonathan1055 commentedI noticed oddly that the failing test has two output pages for /admin/permissions, the second of which has no permissions showing. If somehow as second page is called, which is empty (for some unknown reason) then this would be why the test fails.
Usually, on the 10.1 passing test, there is no second page output. The javascript filtering does not create a second page.
The latest commit added a further call, so try to see where exactly the failure is happening. I can't run the javascript tests locally at the moment, as my latest updated chrome driver does not work with my OSX.
Comment #8
jonathan1055 commentedAdding extra drupalGet did not help. Now trying extra
waitForText()Comment #9
smustgrave commentedAll green, this good for review?
Comment #10
jonathan1055 commentedYes, except we might want to do #3412243: Add pipeline phpunit job for previous core version first. Then I will adjust the changes on this mr.
Comment #12
smustgrave commentedFixed the merge conflicts from merging the pipeline change.
All green! Now jumping over the last eslint ticket.
Comment #13
jonathan1055 commentedExcellent, thank you. I was just coming back here to do the rebase. But at least it was easy, ie. we did not want any changes from .gitlab-ci.yml
The screen grab is a nice useful thing in the javascript test. It showed that the test is using Claro even though the saved html pages display as Stark.
html file

automated screen grab

Comment #14
jonathan1055 commentedI don't know exactly what caused the change in javascript interaction behavior from 10.1 to 10.2, but I am assuming there were new versions of things. The processing was waiting for text to disappear from the page on entering a filter value, using our custom
waitForNoText()function. This was adequate in 10.1 but at 10.2 maybe the page is re-rendererd in a different order? or slower? The text to be hidden was not found, so the test proceeded. But the text we did want to find was not yet showing at that point. So I added awaitForText()on the string we did want to see, and that solved the problem.Comment #15
jonathan1055 commentedAdding info to the title to help future searching.