🇺🇸United States @dan.d

As I worked through the fix for 🐛 Multiple dialogs open / have to click multiple times Active , I've come to realize that at times it's hard to guess the reason for certain decisions that were made by developers who contributed to the module. Consequently, making changes and testing the whole set of features turned out to be quite cumbersome.

I would like to suggest that we create a doc page dedicated to describing the settings and the expected behavior prior to working on a new release. Whoever works on the code must also try to provide comments and code annotations.

It is a seemingly simple module. However, it deals with security and therefore must be well organized and implemented, IMO.

My team has been testing this implementation, and we've discovered a small issue with auto-refresh for the session. I'm ready to make an adjustment, but I wanted to run the assumed logic behind the feature.

Current state:

Right now we've got an activity tracker that check whether a user has been active within the last 30 seconds. If so and the main timer is running out (the session is coming to an end), it will automatically re-new the session, without showing the confirmation modal.

So, the issue arrises when a user has been active for an hour and then takes a short break for a minute, looks away and his session expires just because he/she wasn't active within the last 30 seconds of the session.

Proposed solution:

Start a background timer that checks the activity status every 30 seconds. If there was an action within the last 30 seconds, extend the session in the background. Otherwise, let the session expire after a set interval. This solution will send a request to the server every 30 seconds to extend the session while the user is active on the page.

+ We can also adjust that period based on the actual length of the session, let's say 1/10 of the session period. So, for a 20 minute session we'd "check in" with the server every 20 minutes.

@dmrupp, thanks for the update! I'll take another look, but the same behavior was observed on both branches for me.

...and I do agree with you on that the current fix should be very minimal. However, after familiarizing myself with the current implementation, I believe, that a switch from the jQuery modal to the D dialog should be a relatively straightforward process.

@joseph.olstad, that's great! I'm glad it turned out to be of use to us ;)

I will have to break my comment up into 3 parts since I'm responding to multiple posts by multiple users.

@dmrupp,
1. Which branch did you test with? The opening description of the issues states: This affects 2.x AND also 8.x-1.x.
2. Were you able to repeat the session refresh without a page reload (using AJAX) multiple times?

@hlopes,
I like your approach! But it seems like it goes well beyond the scope initially described by Joseph. This module is due for some good refactoring, perhaps we can start a completely new branch for it. I'd be interested in contributing to it.

@joseph.olstad,
to keep things to the point and to provide the most generic and non-intrusive solution to the issue, I'm suggesting some JS refactoring with a bit of a code clean-up. If you want to take a look and see if this is something we can work with, I'm attaching the patch.

In this patch, I'm addressing the following issues:

1. Creation of poorly-managed background timers (which led to an increased number of background processes)
2. Changing the handling of AJAX responses on success (which led to the stacking responses and a growing number of pop-ups with each consecutive AJAX trigger)
3. Check attachment of the behavior to make sure that we initialize it once (which led to the creation of multiple DOM elements for the timer container)

---
I will also update my branch with this and will create an MR, once it passes the validation locally. In the meantime, I will try testing it in my projects.

Hi @joseph.olstad! I've applied the patch #17 🐛 Multiple dialogs open / have to click multiple times Active and I'm observing the following behavior, similar to what was described in comment #14 🐛 Multiple dialogs open / have to click multiple times Active .

Context

Installed D10.3.x. Installed and enabled autologout module. Applied patch #17. Set Timeout value @60 seconds and Timeout padding @20 seconds.

Observed inconsistent behavior

Upon the expiration of the allowed inactivity period (~1 min), the prompt modal displays with the options to keep the session going (Yes) or to immediately log out (No).

1. The expected behavior is to auto logout the user if there's no interaction with the modal. Unfortunately, the modal stays open and the user session can be extended by clicking on the confirmation button ("Yes" default label) at any time beyond the timeout padding time.

2. There was a case when the user got logged out automatically without an interaction with the modal within the proper timeframes. But I couldn't replicate this behavior in my consecutive attempts. This will require further investigation.

@joseph.olstad, about a week ago I started looking into this issue reported @ https://www.drupal.org/project/autologout/issues/3468020 🐛 Multiple clicks to extend session needed Closed: duplicate . Since then, you've been leading this conversation here. I want to contribute, if you don't mind, with setting a bit of context based on my observations.

Clean Installation

First of all, I've decided to troubleshoot this issue in an "untainted" environment, so I started off with a clean installation of Drupal 10.3.x. Then I installed and enabled Autologout module. I set the timeout to the lowest-allowed number (60 seconds) and tested the feature on a single page (no page reloads to re-fresh the session). This is a good case when you have a micro frontend (or a collection of such) running on a single page and you expect your visitors/users to spend some time there.

The Hidden Element

During the initialization the script adds a hidden element in the DOM. Which needs to be added once (the reason for its creation is irrelevant at this point). However, I've noticed that there are multiple instances of the element being added.

Nesting of the Hidden Element

There seems to be an issue with the AJAX handler, as well as a redundant creation of simultaneously running background timers. It's possible this is where the actual issue originates. If you confirm the continuation of a session via the auto logout prompt (modal), you will notice that the number of nested hidden elements increases with each interaction (with the modal).

The Growing Number of Modal Overlays

At the same time, you will notice that each consecutive aoutologout prompt will trigger a greater number of modals (roughly equal to the number of nested hidden elements). At some point the number went over 200 modals stacked on top of each other. Which, as you can imagine, will lead to issues with rendering and, as a result, session expiration.

Further Actions:

I believe we will have to refactor and modernize the JavaScript implementation for this module, concentrating on the issues related to AJAX handlers and the background timers racing against each other. I will create a fork for this project and will keep on updating this thread with my further discoveries.

We already have information related to these two questions in the documentation for SDC. I'm providing brief explanations to the raised questions with references to the relevant sections in the docs.

dan.d → created an issue.

There are two ways to achieve this:

1. If you are trying to create a list of selections to swap out in your story, based on - https://storybook.js.org/docs/react/api/arg-types#mapping, you can use mapping:

title: Your Components/Examples/Component
argsTypes:
  argument_name:
    name: Give it a Name
    control: select
    options:
      - Option_1
      - Option_2
   mapping:
     Option_1: <p>Option one stuff</p> (or whatever you need, e.g. object, array, etc)
     Option_2: <p>Option two stuff</p> (or whatever you need, e.g. object, array, etc)

... to pass default arguments, use args property:

args:
argument_name: Option_1

2. You can also provide a single value for the field.

stories:
  - name: 1. Your Story
     args:
       content: |
         <p>Whatever your heart desires goes here</p>

@e0ipso - I suggest we create an example in this collection to demonstrate the case.

Дякую! That makes sense now :) I'll switch the version for the issue to 1.0.0-rc5 and the Component entry to "Documentation".

I'm posting the updated version of the patch, which seems to be completing the list of deprecations for D10. Any feedback will be appreciated.

This patch seems to be incomplete. There is another issue that needs to be addressed to make this module compatible with D10:

Call to deprecated function file_munge_filename(). Deprecated in drupal:9.2.0 and is removed from drupal:10.0.0. Dispatch a \Drupal\Core\File\Event\FileUploadSanitizeNameEvent event instead.

L475 - https://git.drupalcode.org/project/filefield_sources/-/merge_requests/5/...
L596 - https://git.drupalcode.org/project/filefield_sources/-/merge_requests/5/...

dan.d → made their first commit to this issue’s fork.

Hi @mstrelan!

Can you please provide more information on how you reached the mentioned path? (/admin/config/user-interface/cl-components) I'm not sure whether the code has been updated and the reference to this route is no longer there. I went over the instructions provided in the repo, however, I couldn't really make out which step you are referring to as " the last."

Please give me a few more details and I'll try to troubleshoot this for you.

Rate your excitement about SDC in core: 1 ... 10 | N/A

10

Rate your excitement about potential contrib extending SDC: 1 ... 10 | N/A

10

Rate our documentation: 1 ... 10 | N/A

8 - The lower score should not reflect poorly on the person/persons who created and maintain(s) the documentation. I can only imagine the pace with which the whole SDC ecosystem has been evolving, and to keep up with all the developments, one must be very responsive and willing/able to contribute a lot of resources. I'm anticipating a very dynamic future with many upcoming changes, therefore, we should pay more attention to this initiative. I'd say HELP NEEDED!

Did you 1️⃣ refactor existing template into a component, or did you 2️⃣ write a component from scratch? 1 | 2

1 & 2

Rate the helpfulness of error messages encountered: 1 ... 10 | N/A

8 - There were moments when I had to dig into the inspector and try figuring out the issues on my own or reach out to the community members, mostly related to the Storybook integration, I'd say. But overall, the error messages were quite descriptive and helpful.

Have you tried the Storybook integration? Yes | No

Yes.

Any thoughts you would like to share? The sky is the limit

...More to come

Julian (@Anybody), I've created an MR and switched the status of the issue to "Needs review." I'm also attaching the screencap of my test with tabs.

dan.d → created an issue.