Problem/Motivation

The permissions filter phpunit test is now failing with

1) Drupal\Tests\module_filter\FunctionalJavascript\ModuleFilterJavascriptPermissionsTest::testPermissionsFiltering
Behat\Mink\Exception\ResponseTextException: The text "Roses" was not found anywhere in the text of the current page.
/builds/project/module_filter/vendor/behat/mink/src/WebAssert.php:907
/builds/project/module_filter/vendor/behat/mink/src/WebAssert.php:293
/builds/project/module_filter/tests/src/FunctionalJavascript/ModuleFilterJavascriptPermissionsTest.php:36

The last passing pipeline was on Dec 19 which ran on Drupal Core 10.1
https://git.drupalcode.org/project/module_filter/-/jobs/507939

The first failure was on 2 January which ran core 10.2
https://git.drupalcode.org/project/module_filter/-/jobs/560664

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

jonathan1055 created an issue. See original summary.

jonathan1055’s picture

Title: Permissions filter test » Permissions filter test - admin access tightened
Issue summary: View changes
Status: Active » Needs review
Related issues: +#3409652: Failing phpunit test: h1[text() = "Administration"] not found, +#3409743: Access permission to /admin/ changed between 10.1 and 10.2

It 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.

jonathan1055’s picture

Issue summary: View changes

The 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.

jonathan1055’s picture

Title: Permissions filter test - admin access tightened » Permissions filter test
Status: Needs review » Needs work
Related issues: -#3409652: Failing phpunit test: h1[text() = "Administration"] not found, -#3409743: Access permission to /admin/ changed between 10.1 and 10.2

OK 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.

jonathan1055’s picture

The drupalci test pases, because it is being run at core 10.1. The pipeline is on 10.2

jonathan1055’s picture

Status: Needs work » Needs review

I 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.

jonathan1055’s picture

Status: Needs review » Needs work

Adding extra drupalGet did not help. Now trying extra waitForText()

smustgrave’s picture

All green, this good for review?

jonathan1055’s picture

Yes, 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.

smustgrave’s picture

Status: Needs work » Fixed

Fixed the merge conflicts from merging the pipeline change.

All green! Now jumping over the last eslint ticket.

jonathan1055’s picture

StatusFileSize
new118.06 KB
new58.65 KB

Excellent, 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
saved html

automated screen grab
automated screen grab

jonathan1055’s picture

Assigned: jonathan1055 » Unassigned

I 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 a waitForText() on the string we did want to see, and that solved the problem.

jonathan1055’s picture

Title: Permissions filter test » Permissions filter test - waitForNoText() also needs waitForText()

Adding info to the title to help future searching.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.