🇺🇸United States @tregonia

@timwood
My process was as follows.

1. Find a form that includes a reset button and open it in a different browser.
2. Ping the database using drush sql:cli to get a count on anonymous sessions.
   SELECT count(*) FROM sessions WHERE uid = 0;
   Also used this to look at them.
   SELECT * FROM sessions WHERE uid = 0 ORDER BY timestamp DESC;
3. Clicked the reset button.
4. Run the 2 sql:cli commands again.

Note the sessions count increases, and a new session is created in the database.

I am currently running D11.1.

In my instance, I am finding that the code never reaches the resetForm function.

The call to resetForm is on line 292, but does not make it into the if statement. This is due to op not being in the form_state within the exposedFormSubmit function.
https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php#L292

Currently rubbing up against this issue in D11. I can confirm that the patch does apply, but does not not prevent the anonymous sessions from being created.

johnpicozzi → credited tregonia → .

tregonia → created an issue.

Encountered issues with multiday events pushing the calendar days outside of the container. Applied #25 to Drupal (10.2.7) and the issue is resolved, with no errors found after a 5-minute review.

RTBC +1

I cannot speak to the changes needed; as mentioned in #26-#28.

I have found that the changes in the latest MR completely override the `novalidate` attribute functionality in some of my forms. Specifically, forms with required fields, and a onchange (not a submit button) that triggers a rebuild of the form.

In my case, I have products on a group and on a user. When adding a user, there is a select element for the company that when changed, triggers an ajax callback that filters a form rebuild that further filters the products that can be assigned. Adding this patch results in the `novalidate` on the `
` element getting ignored, and the ajax callback not being able to submit until all required fields are entered. Having only added this patch last week, reverting the patch out of the build results in the functionality working as expected.

I think that this is by design; since this patch affects the `formnovalidate` attribute, that overrides the `novalidate` attribute.

While this patch does swap out the once syntax, it does not update the libraries to use the correct once dependency.

google_place_autocomplete:
  js:
    js/google_place_autocomplete.js: { }
  dependencies:
    - core/jquery
    - core/jquery.once
    - core/drupal
    - core/drupalSettings
    - google_place_autocomplete/google_maps.places

should become

google_place_autocomplete:
  js:
    js/google_place_autocomplete.js: { }
  dependencies:
    - core/jquery
    - core/drupal
    - core/once
    - core/drupalSettings
    - google_place_autocomplete/google_maps.places

Sidenote:
This issue is resolved in another way in 3414138 ✨ Remove dependency on jQuery Active

Tregonia → changed the visibility of the branch 3414102-use-of-jquery to hidden.

Tregonia → changed the visibility of the branch 3414102-use-of-jquery to hidden.

The update in this issue is also included as part of 3414138 ✨ Remove dependency on jQuery Active .

Tregonia → created an issue.

Tregonia → created an issue.

+1 RTBC
Confirming the patch is still good.

Sidenote. This issue is a 100% blocker to a functioning module, but this patch gets it working again.

+1 RTBC
Confirming the patch is still good.

Sidenote. This issue is a 100% blocker to a functioning module, but this patch gets it working again.

Updated the diff because it was not applying.

Found out today that the patches do not apply against 10.2. I have been debugging and the apply failure is isolated to the form loop in ajax.js; or the logic that handles the focus.

I have removed that section, and resolved the apply failure. I cannot speak to whether any further changes are necessary for other concerns. Please review.

+1 for this being a potentially nice addition to core.

In my use-case, when a user is changed from Active to Blocked, several custom things are triggered. Having the ability to define a confirmation step between validation and submit would be a welcome addition, and better encapsulate all the form functionality.

Looks like I spoke too soon before diving in. The code in this issue is against 9.5.x and affects a file that was removed in `10.0.x` and `10.1.x`.

See https://www.drupal.org/project/drupal/issues/3269082 → for more details.

Next steps are to reroll this patch against D10, or at least D11

Noticed that this patch is using jQuery.once and not Drupal once. Should this issue include using Drupal once?
https://www.drupal.org/node/3158256 →

Tregonia → created an issue.

Created a MR for the issue, but it seems that other code is piggy-backing on the changes.

Tregonia → created an issue.

Tregonia → created an issue.

I am encountering this issues on 10.1.0-alpha1 with the following code.

function theme_preprocess_html(&$variables) {
  // Add class to html if user is masquerading.
  $isMasquerading = \Drupal::service('masquerade')->isMasquerading();
  if ($isMasquerading) {
    $variables['html_attributes']['class'][] = 'masquerading';
  }
}

My workaround is to not put the class on the <html> element, and just go with the <body> instead.

function theme_preprocess_html(&$variables) {
  // Add class to html if user is masquerading.
  $isMasquerading = \Drupal::service('masquerade')->isMasquerading();
  if ($isMasquerading) {
    $variables['attributes']['class'][] = 'masquerading';
  }
}

nicxvan → credited Tregonia → .