Using "Default date source: Date of first view result" causes JS error

What is the result if you choose other display format for that view?

More specifically, what is the date of the first row of the result? If it is not a validated date format or is null. The calendar view won't work.

I also have this issue.
I am using a single smart date field

• format Smart date Formatter
• timepart start and end
• tisamrt date format : default

The browser console shows

Uncaught TypeError: Cannot read properties of null (reading 'getUTCFullYear')
    at B (main.min.js:6:4632)
    at e.startOf (main.min.js:6:62456)
    at d (main.min.js:6:69617)
    at e.buildRangeFromDuration (main.min.js:6:69815)
    at e.buildCurrentRangeInfo (main.min.js:6:68908)
    at e.build (main.min.js:6:68116)
    at main.min.js:6:72011
    at er (main.min.js:6:72235)
    at e.reduce (main.min.js:6:90654)
    at e.dispatch (main.min.js:6:89995)

I was able to reproduce this issue on Drupal 10.6.12 with fullcalendar_view 5.2.5.

The issue happened when using:

- Default date source: Date of first view result
- An exposed search/filter on the calendar View

Without the patch, the calendar either failed to load correctly or did not open on the month of the searched event.

This patch updates the default date handling so the first result date is only used when an exposed search/filter has actually been submitted. On a normal initial page load, the calendar continues to open on the current month.

It also validates the first result date before using it and adds initialDate along with defaultDate.

Tested locally:
- Initial calendar load with no search opens the current month.
- Searching for an event opens the month of the first matching result.
- PHP syntax check passes.

Rerolled the patch to use $view->getExposedInput() instead of raw request query parameters. This supports exposed filters submitted through AJAX and non-AJAX GET requests.

Tested with fullcalendar_view 5.2.5 and Drupal 10.6.12.

As suggested on #5 (https://www.drupal.org/project/fullcalendar_view/issues/3366896#comment-...), this issue is related to the Smart Date module. Please be advised that this module only supports field types implemented by Drupal core.

If you are using the Smart data module with Fullcalendar.js, please try other modules, for example.

https://www.drupal.org/project/fullcalendar

Regarding this issue, I traced every path on 5.2.5:

1. The empty($default_date) ? date('Y-m-d') fallback at FullcalendarViewPreprocess.php:401 has existed unchanged since 5.1.12 (the reported version) — so the obvious "null default date" theory was never the cause.
2. For core datetime / daterange / timestamp fields, substr($start_date_value, 0, 10) always yields a valid YYYY-MM-DD (timestamps are converted to ISO upstream at line 273-276 before they reach the default-date code). No malformed value is producible. No crash.

Change the issue status due to on 5.2.5, with the field types this module actually supports, the reported crash is not reproducible.