when testing this we can see that recaptcha logic is attached to the last page of wizard as expected, yet when webform has ajax enabled it indeed has a problem. On the last page of wizard, when we have previous/next buttons available, the "previous" one does not work anymore, this is probably caused by following checks:
https://git.drupalcode.org/project/simple_recaptcha/-/blob/8.x-1.x/js/si...
https://git.drupalcode.org/project/simple_recaptcha/-/blob/8.x-1.x/js/si...
Since this check will pass for both buttons it will break the ajax on previous button, I think we need to try to validate if element triggering ajax is really a submit button , since there is buttons.js which tries to mark exactly one file with .simple-recaptcha-submit class, maybe it could be reused in ajax logic as well.
Then this patch also raises a discussion if the recaptcha logic should be attached to first or last step of wizard ( imo first is better, since it can prevent creation of empty submissions by bots ), maybe to solve this we could extend handler settings and allow to choose if recaptcha should be added for first or last step on a webform basis..
All right, I've created a follow up issue to check the recaptcha checkbox part of tests:
https://www.drupal.org/project/simple_recaptcha/issues/3495253
📌
JavaScript tests - recaptcha checkbox does not work anymore
Active
And new release for Drupal 11 compat is now available:
https://www.drupal.org/project/simple_recaptcha/releases/8.x-1.0-beta9 →
Thanks everyone for all the help with this issue!
sandboxpl → created an issue.
Okey this will lead us to nowhere, even after validating that the click event is triggered, and adding 30s timeout, it keeps spinning and spinning:
going back from iframe to page content still shows empty checkbox:
This will lead us to nowhere and will take lot of time to investigate , since it is only 3 tests and all other tests are passing, I will create a separate issue for that ( it could be that we will have to completely change the idea for the checkbox itself, maybe it is not even possible to test it anymore ).
For tests, it seems that switch to recaptcha iframe is working properly, the only thing we miss is clicking on right element, let's try to switch from .recaptcha-checkbox to #recaptcha-anchor element
ah the gitlab-ci.yml file is added via fork , so this test won't trigger the pipeline
The merge request is compatible enough to make it all work, but I see the js tests failing and the issue is following:
1) we switch to recaptcha iframe and click the checkbox, it seems that it somewhat has been clicked:
https://issue.pages.drupalcode.org/-/simple_recaptcha-3451320/-/jobs/374...
2) yet on the next screen we can see that checkbox is empty again:
https://issue.pages.drupalcode.org/-/simple_recaptcha-3451320/-/jobs/374...
The generated output of recaptcha checkbox is following:
<span class="recaptcha-checkbox goog-inline-block recaptcha-checkbox-unchecked rc-anchor-checkbox recaptcha-checkbox-clearOutline" role="checkbox" aria-checked="false" id="recaptcha-anchor" tabindex="0" dir="ltr" aria-labelledby="recaptcha-anchor-label">
<div class="recaptcha-checkbox-border" role="presentation">
</div>
<div class="recaptcha-checkbox-borderAnimation" role="presentation">
</div>
<div class="recaptcha-checkbox-spinner" role="presentation">
<div class="recaptcha-checkbox-spinner-overlay">
</div>
</div>
<div class="recaptcha-checkbox-checkmark" role="presentation"></div>
</span>
And what seems to be missing here is:
1) Element class remains recaptcha-checkbox-unchecked while it should become recaptcha-checkbox-checked
2) Aria attribute aria-checked remains false , while it should be switched to true
It seems that final step of 3 failing js tests is not working with current markup/behavior of recaptcha widget things we can try:
1) Click on element with ID = recaptcha-anchor and not class = recaptcha-checkbox
2) optionally wait until aria-checked attribute has been really changed to true , and/or element class has been successfuly changed to recaptcha-checkbox-checked
Inspiration:
https://github.com/remarkablemark/remarkablemark.github.io/blob/master/_...
https://git.drupalcode.org/project/recaptcha/-/blob/8.x-3.x/tests/src/Fu...
Aha, I've just found that this behavior can be reproduced in CKEDitor demo:
https://ckeditor.com/docs/ckeditor5/latest/examples/builds-custom/full-f...
and similar issue is reported in ckeditor issue queue: https://github.com/ckeditor/ckeditor5/issues/14236
I've tested with Drupal 10.3.2 which adds a feature to maintain table/cell properties ( https://www.drupal.org/project/drupal/issues/3324225 ✨ Support CKEditor 5's table properties and cell properties plugins in Full HTML Fixed ), using patch #21 as it seems to be enough to just enable the plugin.
Standalone features seem to be working properly, but I can see there is a conflict and UI glitch when trying to use TableProperties and TableColumnResize plugins together.
Here's what I've tried to do:
Create new table and use table/table cell properties to define fixed widths:
1. table width: 500px
2. first cell width: 250px
3. second cell width: 250px
And here's the HTML produced:
<table style="width:500px;" data-once="js-once-set-responsive-tables" class="no-th">
<tbody tabindex="0">
<tr data-once="js-once-check-th-position">
<td style="width:250px;">250px</td>
<td style="width:250px;">250px</td>
</tr>
</tbody>
</table>
Now edit content again, and use TableColumnResize feature to change width of cells using your mouse, this will result with following markup:
<table class="ck-table-resized no-th" style="width:61.9%;" data-once="js-once-set-responsive-tables">
<colgroup>
<col style="width:17.67%;">
<col style="width:82.33%;"></colgroup>
<tbody tabindex="0">
<tr data-once="js-once-check-th-position">
<td style="width:250px;">250px</td>
<td style="width:250px;">250px</td>
</tr>
</tbody>
</table>
Result:
- in the markup we can see the result of both plugins used
- <colgroup> will take higher priority , the style of <td> elements won't apply anymore, so all style attributes applied on <td> elements become useless
- The UI becomes confusing, there is no way to clean up or override done with TableColumnResize, aka there is no way to remove <colgroup> element. I can still drag columns to change their size, but using cell properties to change anything does take any effect.
- if within the editor I try to change cell properties, I can't see instant results as well ( which was totally fine before applying TableColumnResize change )
So maybe some extra logic would be needed to make both plugins work in parallel, for example:
- when using TableColumnResize plugin to resize columns, popupalate <colgroup>, but clean up styles from <td> elements
- when using TableProperties plugin, remove <colgroup> populated by TableColumnResize plugin to resolve conflict between both plugins?
- or maybe just allow to use one of those plugins at the same time?
Hi, this is really interesting, can you provide device type and browser which fails on mobile? I'd like to check something like browser stack to see if I can reproduce this problem
Hi, thanks for the feedback, please check following thigs:
I notice if I am logged in as admin it does not work.
There is a bypass of validation for admins indeed, the module provides permission for that:
https://git.drupalcode.org/project/simple_recaptcha/-/blob/8.x-1.x/simpl...
So I logged out, and now I can see the relevant JS code and other HTML on the page for it, BUT, the V2 checkbox still does not appear. When I submit the form I get the error:
There was an error during validation of your form submission, please try to reload the page and submit form again.
For v2, the checkbox is hidden by default, and only when you click on submit button it should be rendered, this logic is explained here:
https://git.drupalcode.org/project/simple_recaptcha/-/tree/8.x-1.x?ref_t...
if you get an form validation error, please check dblog, you should see more details about the error in there + corresponding recaptcha error code.
If I switch to V3 I can see the badge, but the form submits OK. How can I know its implementing ReCaptcha when V2 is not working? I cant trust it.
V3 is quite invisible, to see it in action you'd have to inspect the document, and look at the hidden element with name=simple_recaptcha_token, this one should get filled in with verification token once you submit the form, and it will be sent to recaptcha API for validation. For more detailed investigation you can place breakpoints in here:
https://git.drupalcode.org/project/simple_recaptcha/-/blob/8.x-1.x/src/S...
The webform ID is contact_us
But when I dump the form_id passed to your code it's:
webform_submission_contact_us_block_content_4_add_formSo that's incorrect, you should be using the actual ID showing in the URL and the form ID called. Its in the $form array passed as "webform_id" but looks like you are using form_id.
Adding the webform_submission_contact_us_block_content_4_add_form to the list of forms to add ReCaptcha to still does not show it though.
Using form IDs for webforms is not reliable at all, please try to install simple_recaptcha_webform submodule, and add handler directly to the webform.
sandboxpl → created an issue.
Possible workaround for this is to add "/user/reset/*" to the list of excluded paths in disable language settings,
the module's config can be also dynamically overriden via settings.php file with following line:
$config['disable_language.settings']['exclude_request_path']['pages'] = '/user/reset/*';
Same issue occurs for node types with layout builder enabled,
when trying to edit a layout (with "Show content preview" option enabled) that contains addtoany block, it breaks.
The patch #4 fixes the problem for LB
I am trying to follow up the issues but currently I feel like I'm delayed on everything,
if anyone would like to help with pushing open issues and MRs forward please open application for co-maintanance.
Ideally I'd love to get some help from someone who:
1. Understands how clientside parts of the module are working, has good knowledge in JS and could help with forming JS files of the module - I have a feeling that some refactor is needed there, currently we handle 2 JS libraries for 2 versions of recaptcha and the jQuery code grew a lot
2. Knows common practices of following issues, working with drupal gitlab, reading and understanding functional tests
For the stable release I believe we should:
- Merge and close open issues
- Merge and close open feature requests
- Figure out if we can setup testing for reCAPTCHA v3 - technically this is doable and what we miss is the API key ( v2 has a test key, v3 doesn't provide one, I wonder how we could deal with this )
- NTH: refactor current JS libraries, maybe try to reduce amount of jQuery beign used, merge both libraries and make the code more modular. Currently each patch/MR will change the code in a way that it will most likely introduce merge conflict for all other open MRs
sandboxpl → created an issue.
sandboxpl → created an issue.
The provided patch is breaking the tests,
please check tests output at
https://www.drupal.org/pift-ci-job/2777420 →
This is indeed how the module works, for both types of recpatcha ( v2 and v3 invisible ) all recaptcha related javascript calls are being triggered only after submitting the form. The main reasons for that are following:
1) when developing the module, there was a lot of rumors saying that recaptcha might become a paid service, so by doing API calls only when it's really needed we've limited the total amount of calls, this also has good performance impact (imagine having a simple newsletter form added to footer on each page and making recaptcha calls everytime the page is loaded vs making that calls only when user interacts with form )
2) most of recaptcha logic is delegated to JS libraries, which makes it easier to work with different caching systems
We experience same problem , after deploying changes the website goes down and we get following error:
Error: Class "Laminas\Diactoros\ServerRequestFactory" not found in /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 #0 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(449): Drupal\Component\DependencyInjection\Container->createService(Array, 'private__Q1ZW9d...')
restarting FPM pool and clearing op/apcu cache solves the problem,
it seems that it comes down to the change introduced in core 9.5.9 and following issue:
https://www.drupal.org/project/drupal/issues/3356283
📌
Fork laminas/laminas-diactoros
Fixed
The fork of laminas/laminas-diactoros packange moved the vendor package around in vendor directories
vendor/laminas/laminas-diactoros -> vendor/longwave/laminas-diactoros
Usually setting new deployment_identifier helps us to get around such problems, but in this case it didn't work
It seems that all add this services have been deprecated,
see the announcement on addthis homepage: https://www.addthis.com/
sandboxpl → created an issue.
Hi @cosmicdreams,
by default we try to override Drupal.Ajax.prototype.beforeSubmit via JS library, this should stop the ajax submit before the module does it's work and populates the token, you can see this here:
https://git.drupalcode.org/project/simple_recaptcha/-/blob/8.x-1.x/js/si...
If this doesn't work there might be plenty of reasons for custom forms, could you provide some basic code example for the custom form which does not work for you? We need some steps to reproduce this, maybe if we have an example structure we could provide a test for custom forms as well
I've modified the plugin base to use start date when it's available,
otherwise it should fallback to start date +1h, see MR.
Example result:
Event dates:
- Event start date: 13 September 2023 14:42
- Event end date: N/A
Generated google calendar link:
http://www.google.com/calendar/event?action=TEMPLATE&text=Test%20Event&d...
sandboxpl → created an issue.
That was an interesting exercise :)
We also should update min version requirement for the module via infol.yml file, see
https://www.drupal.org/node/3158256 →
If we switch to core/once library the module won't work with drupal core versions below 9.2.x
Good catch! Thanks for providing the patch!
Reroll for 9.5.x and PHP 8.1
Needs rerolls for drupal 9.5.x, when testing previous patches with Drupal 9.5.7 I get following errors:
When installing profile via UI:
The website encountered an unexpected error. Please try again later.
Error: Unknown named parameter $interactive in call_user_func_array() (line 426 of core/lib/Drupal/Core/Extension/ModuleHandler.php).
call_user_func_array(Object, Array) (Line: 426)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'myprofile') (Line: 405)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('site_install_finished', Object) (Line: 433)
Drupal\Core\Extension\ModuleHandler->invokeAll('site_install_finished', Array) (Line: 1895)
install_invoke_finished_hooks(Array) (Line: 700)
install_run_task(Array, Array) (Line: 571)
install_run_tasks(Array, NULL) (Line: 119)
install_drupal(Object) (Line: 48)
When installing width drush si ( drush 11.5):
Error: Unknown named parameter $parameters in /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php on line 426 #0 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(426): call_user_func_array(Object(Closure), Array)
#1 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(405): Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object(Closure), 'myprofile...')
#2 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(433): Drupal\Core\Extension\ModuleHandler->invokeAllWith('site_install_fi...', Object(Closure))
#3 /var/www/html/docroot/core/includes/install.core.inc(1895): Drupal\Core\Extension\ModuleHandler->invokeAll('site_install_fi...', Array)
#4 /var/www/html/docroot/core/includes/install.core.inc(700): install_invoke_finished_hooks(Array)
#5 /var/www/html/docroot/core/includes/install.core.inc(571): install_run_task(Array, Array)
#6 /var/www/html/docroot/core/includes/install.core.inc(119): install_run_tasks(Array, Array)
#7 /var/www/html/vendor/drush/drush/includes/drush.inc(129): install_drupal(Object(Composer\Autoload\ClassLoader), Array, Array)
#8 /var/www/html/vendor/drush/drush/includes/drush.inc(113): drush_call_user_func_array('install_drupal', Array)
#9 /var/www/html/vendor/drush/drush/src/Commands/core/SiteInstallCommands.php(152): drush_op('install_drupal', Object(Composer\Autoload\ClassLoader), Array, Array)
#10 [internal function]: Drush\Commands\core\SiteInstallCommands->install('myprofile...', Array)
#11 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
#12 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#13 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#14 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(390): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#15 /var/www/html/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/html/vendor/symfony/console/Application.php(1039): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/html/vendor/symfony/console/Application.php(275): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 /var/www/html/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#19 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(124): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(51): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#21 /var/www/html/vendor/drush/drush/drush.php(77): Drush\Runtime\Runtime->run(Array)
#22 /var/www/html/vendor/drush/drush/includes/preflight.inc(18): require('/var/www/html/v...')
#23 phar:///usr/local/bin/drush/bin/drush.php(143): drush_main()
#24 /usr/local/bin/drush(14): require('phar:///usr/loc...')
#25 {main}
basically this:
function install_invoke_finished_hooks(&$install_state) {
\Drupal::moduleHandler()->invokeAll('site_install_finished', $install_state);
}
should become this for php8.1:
function install_invoke_finished_hooks(&$install_state) {
\Drupal::moduleHandler()->invokeAll('site_install_finished', array_values($install_state));
}
@forzakenus which drupal core version are you using for the testing? if it is below 9.2.x it is most likely caused by following change:
https://www.drupal.org/node/3158256 →
We are planning to drop support for Drupal core 8.x as it is not supported anyway.
Indeed, this was also spotted in #3338584 after recent updates,
as D8.x is not supported and jQuery/once was deprecedated I don't see any other options than kicking out support for d8 for the future versions of the module
New release is ready:
https://www.drupal.org/project/simple_recaptcha/releases/8.x-1.0-beta8 →
thanks for work and testing every1!
Okey the code is now merged, I'll create new release in few minutes
Oki I've refreshed the branch and moved the code a little,
generally passed into the addSubmitHandler() so we can have it in one place.
If the form contains actions element, which is a case for most of Form API forms, the policy markup will be attached as a prefix of the actions element, otherwise we will do a fallback and put that text at the bottom of form.
No matter which case will apply, I believe that for each specific project a bit of project-specific will be needed anyway, so this code should be enough on the module's side of things
The approach looks good to me, I just have one observation:
+ use Drupal\Component\Utility\Random;
+ $random = new Random();
+ $key = $random->string('10', TRUE);
+ $build['#attached']['drupalSettings']['rocketshipUI_layout_carousel'][$key] = $this->configuration;
+ $build['#attributes']['data-carousel-id'] = $key;
To me Random.php seems to be quite heavy to generate IDs,
maybe we could replace it with Html::getUniqueId:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Util...
it's also using static cache and ensures that we generate unique ID per single page scope
Committed and pushed, thx every1!
from recent drupalci output:
08:54:39 cd modules/contrib/disable_language && sudo -u www-data /var/www/html/vendor/bin/phpcs -e --report-full=/var/lib/drupalci/workdir/phpcs/codesniffer_results.txt --report-checkstyle=/var/lib/drupalci/workdir/phpcs/checkstyle.xml --report-diff=/var/lib/drupalci/workdir/phpcs/codesniffer_fixes.patch --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --file-list=/var/lib/drupalci/workdir/phpcs/sniffable_files.txt > /var/lib/drupalci/workdir/phpcs/phpcs_sniffs.txt
08:54:39 Adjusting paths in report file: /var/lib/drupalci/workspace/jenkins-drupal8_contrib_patches-143065/ancillary/phpcs/checkstyle.xml
08:54:39 sudo chmod 666 /var/lib/drupalci/workspace/jenkins-drupal8_contrib_patches-143065/ancillary/phpcs/checkstyle.xml
08:54:39 ---------------- Finished phpcs in 0.745 seconds ----------------
08:54:39 ---------------- Finished validate_codebase in 0.858 seconds ----------------
as patch does not provide any logic / data model changes in code, this one is good to go
See MR
sandboxpl → created an issue.
oooh, w8, I think it might be related to the latest commit making the module compatible with drupal 10, see: #3289651 📌 Automated Drupal 10 compatibility fixes Fixed
We have moved from deprecated jquery/once to , see:
https://www.drupal.org/node/3158256 →
I believe that for core versions lower than 9.2.x JS is now throwing errors related to missing once function, can you confirm that ?
Hi, the webform submodule provides webform specific handler,
please remove webform ID from /admin/config/services/simple_recaptcha
and add handler via /admin/structure/webform/manage/{webform_id}/handlers
If the problem still occurs, please check the page source, the webform should contain a hidden input with name "simple_recaptcha_token" ,
and this one should be prefilled when you click on submit button, also please check if there's no errors showing up in browser console
If this doesn't solve your problem please add some additional details such as:
- webform module version
- steps to reproduce with https://simplytest.me/
- or dump webform configuration ( yml dump would be nice )
As webform module is extremely flexible and provides a lot of contribs extending the default functionality,
it is hard to test and cover all scenario, thus if you could provide more usueful details and steps it will be easier to dig in :)
All right, I've merged the code and published new release, so drupal packagist can pick up d10 support. For the testing, I've enabled tests for D9.5 and D10 so we can keep an eye on both supported core version. Thanks everyone for pushing this one through!
Okey so the test against D9.5 was fine, but there was some integrity check failing on drupalci part of the job,
as expected, the problem resolved itself overnight, looks like we're good to go now
Okey pretty much done after cleaning up some last leftovers in tests,
I'm just confused why D9,5 test switched from "pass" into "Build successful" , all tests are passing nicely, but something strange happens in the test run itself...
gilab asked for rebase ( 1 commit with updated tests ) , so I did so, let's just confirms if tests will pass
I've also triggered a test against core 10.x to see if we don't miss anything here
sandboxpl → made their first commit to this issue’s fork.
Definitely!
I've just added new section in the docs, so the info won't get lost ( couldn't find any useful info in documentation before )
see
https://www.drupal.org/docs/automated-testing/phpunit-in-drupal/running-... →
Added some examples to showcase overriding of chromedriver args dynamically ( handy for drupalci )
Okey let me wrap it up and share as much details I can, as it was quite intensive research:
1. This is how drupalci runs javascript tests:
23:47:56 cd /var/www/html && sudo MINK_DRIVER_ARGS_WEBDRIVER='["chrome", {"browserName":"chrome","chromeOptions":{"args":["--disable-gpu","--headless"]}}, "http://chromedriver-jenkins-drupal-contrib-654786:9515"]' -u www-data php /var/www/html/core/scripts/run-tests.sh --color --keep-results --suppress-deprecations --types "PHPUnit-FunctionalJavascript" --concurrency "1" --repeat "1" --sqlite "/var/lib/drupalci/workdir/run_tests.js/simpletest.sqlite" --dburl "mysql://drupaltestbot:drupaltestbotpw@172.18.0.4/jenkins_drupal_contrib_654786" --url "http://php-apache-jenkins-drupal-contrib-654786/subdirectory" --directory modules/contrib/simple_recaptcha
2. In order to reproduce the errors locally, 2 pieces were needed:
First of all run chromedriver with bare minimum settings and args, here's my docker-compose template:
version: '3.5'
services:
chrome:
image: drupalci/webdriver-chromedriver:production
ulimits:
core:
soft: -1
hard: -1
cap_add:
- SYS_ADMIN
volumes:
- /dev/shm:/dev/shm
ports:
- "4444:4444"
entrypoint:
- chromedriver
- "--port=4444"
- "--allowed-ips="
- "--allowed-origins=*"
networks:
- default
Second thing, the MINK_DRIVER_ARGS_WEBDRIVER in command above is being passed along to the getMinkDriverArgs():
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/tests/Drupa...
So we'd like to keep this one same locally, here's line for phpunit.xml file:
<env name="MINK_DRIVER_ARGS_WEBDRIVER" value='["chrome", {"browserName":"chrome","chromeOptions":{"args":["--disable-gpu","--headless"]}}, "http://chrome:4444"]'/>
3. Now we are able to reproduce the tests locally with quite close set up
Tests are failing only for JS tests, and it seems to be a problem with recaptcha iframe,
the key here is that we connect to chrome via insecure connection:
http://chrome:4444
drupalci as well:
http://chromedriver-jenkins-drupal-contrib-654786:9515
This is causing issues with recaptcha iframe, getting into cross origin issues and blocking some js from recaptcha domains ( those are loaded via https:// )
4. Fixing it locally
This was quite easy, just allow insecure connections in chrome by adding extra args
"chromeOptions":{"args":["--disable-gpu","--headless", "--disable-web-security"]}}
5. Fixing this in drupalci
This was tricky as there is no clear explanation or doc on that. After debugging code I've found it is actually doable by taking over getMinkDriverArgs() method, so I've added this:
protected function getMinkDriverArgs() {
// drupalCI chrome is executed via http://
// for example: http://chromedriver-jenkins-drupal-contrib-652354:9515
// due to this, we hit cross-origin errors when fetching ext. resources.
$args = json_decode(parent::getMinkDriverArgs(), TRUE);
$args[1]['chromeOptions']['args'][] = '--disable-web-security';
return json_encode($args, JSON_UNESCAPED_SLASHES);
}
Modifying only args part, as we don't want to touch other parameters ( f.e. chrome URL )
Now the tests are passing again, I've cleaned up the MR a little and merge it into the dev branch
Bingo ! :-)