Fixed DeCache() overlay, blur, show again

Rasmus Vind

Well-known member
I am experiencing something very weird. I am creating an overlay in which I am allowing the user to drag and drop files into and more. This is done by replacing some of the contents of the form with previews of the uploaded files. This results in the fact that the default XenForo/HTML form reset button cannot fully clear the state of this upload, so I made this:
Code:
<script type="text/javascript">
XenForo.RasampleForm = function($form) {
      new XenForo.MultiSubmitFix($form);
      return $form.bind({
        AutoValidationBeforeSubmit: function(e) {},
        AutoValidationComplete: function(e) {},
        reset: function() {
          var overlay;
          overlay = $form.closest('div.xenOverlay').data('overlay');
          return overlay.close().getTrigger().data('XenForo.OverlayTrigger').deCache();
        }
      });
    };
    XenForo.register('form.RasampleForm', 'XenForo.RasampleForm');
</script>
Pay attention to the 'reset' part in particular.

This worked well for me. When the user clicks "Submit", the form is submitted and if errors occur, he can click the "Overlay" button again and continue where he left. If it finished successfully, the form is cleared by XenForo. If he clicks cancel, my code is DeCaching the form so he can start over.

But... I have compiled a list of steps to make this not work, here goes:
  1. Click "Overlay"
  2. Click "Cancel"
  3. Click "Overlay"
  4. Click outside the box in the grey area
  5. Click "Overlay"
This last time when opening the overlay it will immediately hide again and will continue doing so until the page is refreshed.

I have absolutely no idea what is going on.

I have attached a sample project to test this with and there is a video link at the bottom. If you try my sample, go to this page:

Code:
http://your/xenforo/installation/rasample

https://dl.dropboxusercontent.com/u/323865/2015-01-22 Rasample.mov
 

Attachments

Last edited:
I can reproduce this. I have some slight concerns regarding changing it in case there's something non-obvious relying on the behavior.

The issue is that the underlying overlay library is attaching a click handler to the overlay trigger (though we don't need it). Decaching the overlay ends up leaving things in a slightly weird state. When you click again, another click handler gets registered because it's a new overlay.

There isn't a way to target this click handler explicitly, which is what my workaround adds and then removes any previous overlay load handler on the trigger. I suppose as it doesn't make sense for a trigger to load 2 overlays it should be safe to change.
 
It's not something you can workaround. I have applied the change to the next release though.
 
Top Bottom