Using Chrome ConfirmForms do not double click prevention causing problems

I can confirm my colleague's bug as I could start fixing it afterwards for one of our drupal installs :P

To be a bit more specific about the sequence of events:
- Enable a module which needs another required module which has not been enabled yet
- You move to the next screen where you are being asked if the required module should also be enabled
- Click the continue button twice
- This will disable any module currently enabled, aside from the modules that cant be disabled because they are required by others

The first time it happened we thought it was some weird error that happened, but we were able to reproduce the bug.

I would say maybe a possible solution would be to disable the button after one click via javascript or have an actual fallback with php to remember which modules are currently enabled.

I can confirm this with Drupal 6.20.

Damn annoying too :p

Could not reproduce on D7, so it looks more like a 6.x issue, but I recall going through this as well.

This is kind of a big deal. Wow. Found this out the hard way. Worst day ever! Well, not the worst, but pretty bad in my Drupal world.

I'm guessing there's no actual "fix" for this. Time to start guessing which modules need re-enabled on my ubercart site.

This is still a problem in 6.26 and should really be fixed.

I just had this happen to me with 7.x-dev (I just switched to dev off 7.14 a couple of days ago). I was installing a mod that needed a required mod enabled, I clicked confirm and went to do something else. When I came back I forgot I had already confirm and clicked the button again. Fortunately I found this through a search, I at first thought someone had hacked me, but quickly got thinking that the last mod I installed caused it. I can imagine this has happened to a few people...

I just installed (standard profile) 7.14 on Amazon EC2 SLES linux server with all system requirements met and all optional core modules are disabled when you press the save config button (only once is required to see the effect). I have to delete the DB and reinstall to get back but can't enable any new modules. The password hange screen also complains about undefined index with pass2 not defined.

The install didn't go completely smoothly either. The site config screen keeps asking for a email and password even though they were entered on the screen. I had to hard code them to force the screen to continue. I have an install script if you want to recreate the issue. Very frustrating.

Can someone check and see if this is happening on 8.x please? Fixes go to 8.x first and are backported to 7.x later on.

What I noticed is that the first optional module in the list is enabled only so if I select 10 modules, the first module in the list is the only one that get's enabled and all other optional (core or contrib) modules get disabled. Hope this helps.

Happened to me as well. Weired thing is that not ALL modules are disabled, but the majority.

See #10 please. We already know it's a bug in 7.14.

I can reproduce in D8. (Trying to enable Views UI with Views disabled.)

While this surely is a bug, there are a good deal of errors that can be produced by double clicking on a submit button, and its been broken since D6.

If someone with a real debugger wants to step through this, start in system_modules() and system_modules_confirm_form(). I'm used to using dpm(), but of course devel is disabled while reproducing :)

Also, I attempted to modify http://api.drupal.org/api/drupal/core%21modules%21system%21system.test/f... to simulate a double-click, but drupalPost() is too smart for it.

This is a real pain...glad to know it's in core tho and not hidden in some dark, dank, dastardly, devious drupal contrib corner. A new issue tag would be nice for this sort of bug: evil

So, if we can prevent double-click submissions, we might fix this? I found #1705618: Double click prevention on form submission, which proposes this feature.

Yes, I can confirm this bug on Drupal 7.19 (and Google Chrome). I've dived into it and found out why it happens.

• When a dependency to some other module(s) is detected a confirmation form is shown. The confirm_form saves the to-be-submitted module settings to the cache_form table for later submission.
• When you first click on the button a request is started which reads the cache and starts enabling a module.
• This is a rather slow process; may take 20 seconds or so.
• Then you click on the button for the second time. Google fires up a new request while the current one is still running.
• It seems that either Drupal (or Chrome, but probably Drupal) queues the second request until after the first request has cimpleted (maybe some locking mechanism on the module system?)
• When request one finishes, the form is cleared from the cache (in drupal_process_form).
• Only then, the second request starts... and now bad things start to happen!
• First, the cache is checked, but nothing is found, so the form_state will not contain the module settings
• This in itself wouldn't be a major issue, but because of the confirm_form $form_state['#input'] contains values, but not the module settings (only the confirm form settings, such as the name of the clicked button).
• This tricks the form_builder into thinking that input must be processed (see line 1780 in form.inc in Durpal 7.19).
• The individual module checkbox-elements are processed, but no input is available. Therefor NULL is used as the input value.
• In _form_builder_handle_input_element, the value is set to 'NULL' which, in checkbox elements, is taken as 'FALSE'
• The function system_modules_submit is invoked as input is processed and the confirm button was clicked with the incorrect values for the module settings.
• All modules are disabled.

The problem is quite obviously in the caching mechanism / confirm_form combination. Imho, confirm_form forms should always invalidate when the cached form could no longer be loaded.

The next step would be to think of a solution. I'd rather let the core maintainers think of one, but personally I think this could be fixed by adding a validation function in confirm_form which checks if the original form could be loaded from cache when submitting the confirmation form.

Good luck system.module maintainers!

This is normal as #14.

I came across this issue too, but without dubble cliking on the submit/confrm button.

- set up a clean Drupal 7.22 install,
- uploaded our pack of modules to /sites/all/modules/,
- enabled a few modules without requirments
- so far so good
- then i enabled a bunch of modules which did not have their dependent modules enabled. (some had 10+ requirements).
- i clicked once on 'confirm' on the next page,
- all the modules were disabled, except the core dependencies

This is a nasty, nasty bug! Is their any patch or progress on this issue?

The bug needs to be fixed in 8.x first then backported to 7.x that's how it works.

If you don't see any patch on this issue there is probably not patch existing for it. You're welcome to contribute :)

There is a more general discussion in #1705618: Double click prevention on form submission

It has a patch taken from a non generic #483876: Disable install button once clicked

As #1705618: Double click prevention on form submission is now fixed for 8.x please retest and close.

#1705618: Double click prevention on form submission is scheduled for backport too.

I can confirm this is still happened, I just had it happen to me. I am also using Google Chrome.

@mattbus what is happening exactly. In my case not all modules are suddenly disabled. See my steps in the summary.

Also for node/x/delete

@clemens I enabled a module, then was taken to the "the module you want to enable requires this module enabled" page. I clicked confirm. While I am not positive that I double clicked (I can't remember), I unintentionally double click confirmation buttons all the time because my clicking finger is very spazzy so it is very likely that I did double click it). So after hitting confirm, when I was taken back to the /modules page, the majority of my modules were disabled. I was running google chrome, and also had module filter enabled at the time of the error, though I'm not sure if that is relevant.
After I realized what had happened and did my best to re-enable the modules, I was perplexed and went searching on google in order to find out what may have caused this when I came across this discussion which described my issue pretty much to the tee. Additionally, I tried to test the issue on our test version of that particular site and was unable to reproduce the results of the bug.
P.S. I'm not sure exactly on the protocols of these types of discussions, so if there is any other information I should provide, just let me know.

@mattbus thanks. I now understand you use D7. The procedure is to fix this for D8 first then backport the fix to D7.

It would help to test this on a bare D7 and name/add the D7 equivalent for HAL module into 'steps to reproduce' into this issues summary.

I'm not able to reproduce the issue as described in 9.3.x. Steps:

1. Install Drupal
2. Go to admin/modules and select a module with a dependency to install, e.g. Content moderation, which requires Workflows
3. Click Install
4. On the next page, click 'Confirm' multiple times
5. Result: Both modules are enabled

Tested also clicking multiple times with the Uninstall form but it did not cause any issues.

More information about this issue was asked for in #37, 10 months ago after 6 years of inactivity. No additional information has been supplied. In the same comment, pameeela reported that this was not reproducible, since there have been no further information, closing as cannot reproduce.

If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!