Uncaught TypeError: Cannot read properties of null (reading 'value')

#2 works perfectly for me and looks like the right way to solve this.

This is also showing Uncaught TypeError: unpublishOn is null depending on your js aggregation settings.
Confirming RTBC: Patch #2 fixes the issue, thanks!

+1 to RTBC

Like @pcambra mentioned, this fixes Uncaught TypeError: unpublishOn is null error in the browser's console.

This was blocking Cypress tests for me and the patch fixes it.

Thanks so much!

Thank you @greenSkin for the patch. No that DrupalCI patch testing has been discontinued I have converted this into a MR. It would be good to have some test coverage for this. What was the scenario that you had which led to the fields not being in the form?

Ran into this issue after upgrading to 2.0.4 on a site. The MR/patch fixed the issue.

What was the scenario that you had which led to the fields not being in the form?

For me it was showing on content types that only showed the published or unpublished form elements, but not both. So for instance on content types configured to only allow publishing but not unpublishing, or vise-versa.

Yes, what PCate mentioned. The issue is when using the published or unpublished form element, but not both.

Thanks for the info, yes I can replicate this locally.
Do you know, in general, how to detect console errors in phpunit javascript tests amd/or how to make the test fail? I've done some searching but cannot find out how. It should be a normal requirement to fail the test, but I can't how to do it.

@jonathan1055,
I'm adding a related/duplicate issue here.
I've fixed that issue using optional chaining. Please check once.

https://www.drupal.org/project/scheduler/issues/3465015 🐛 JS error when "Unpublishing" option is disabled RTBC

When I first was extending the test coverage, I tried it on a different issue (MR83) and the 'test-only changes' job correctly produced the error

Drupal\Tests\scheduler\FunctionalJavascript\SchedulerJavascriptVerticalTabsTest::testEditNonEnabledEntitySummary with data set "#node" ('node', 'testpage')
TypeError: Cannot read properties of null (reading 'value') 
at http://localhost/web/modules/custom/scheduler/js/scheduler_vertical_tabs.js?shy5qp:27:27
at $.fn.drupalGetSummary

https://git.drupalcode.org/project/scheduler/-/jobs/2392334#L495

However, in this issue, on MR162, we do not get that error, the test just continues beyond the js error, and fails with the subsequent text assertion

Drupal\Tests\scheduler\FunctionalJavascript\SchedulerJavascriptVerticalTabsTest::testEditEntitySummary with data set "#node" ('node', 'testpage')
Behat\Mink\Exception\ResponseTextException: The text "Scheduled for publishing" was not found anywhere in the text of the current page.
/builds/project/scheduler/vendor/behat/mink/src/WebAssert.php:907

https://git.drupalcode.org/project/scheduler/-/jobs/2395564#L447

I don't understand why this MR does not report the javascript error, as that is clearly happening (silently) and is the reason why the later "Scheduler for publishing" assertion fails. Both test jobs are using core 10.3 and phpunit 9.6.20. If anyone has an idea, let me know. But this should not stop the test and fix being committed.

Thanks @omkar-pd but I have closed 🐛 JS error when "Unpublishing" option is disabled RTBC as a duplicate of this one, given that this issue was created first (2nd July compared to 31st July)

I have discovered what causes the js error to be hidden. If there are subsequent assertions that fail, then the log shows those and the js error is not displayed. But if there are no later assertions, or only assertions that pass, then we do get the js error showing. This is not great, because it could easily obscure an error and make debugging more tedious without the details of what caused the problem. However, that is a separate issue.

Here's the test with a temporary change to remove later assertions. We get the desired js error instead:
https://git.drupalcode.org/project/scheduler/-/jobs/2402226#L449

The latest commit uses optional chaining ?. (credit to omkar-pd for that idea). This syntax was introduced in ECMA2020 in June 2020 so should be OK to use here. If you know of a reason to keep with the old long-hand syntax let me know.

Merged and fixed. Thank you everyone.

Not sure if this fix was only for 10.3, but running 10.2.7 and we still see the same broken JS error message from scheduler. Turning off the scheduler module and the errors go aways, so it's definitely still happening in version 2.0.4 on Drupal 10.2.7.

@jcsparks, the fix hasn't made it into a new release of the scheduler module yet. You'll either need to install the dev version of this module (which has the fix) or use the MR in this issue. Whether you're using Drupal core 10.3 or 10.2.7 shouldn't matter.

Gotcha... I see that now, thanks for pointing me to the update.

Can also backport this to 8.x-1.x