.uploader-window doesn't disappear

[ericlewis]

I've noticed this a few times recently.

I drag a file into to the Media modal, after which I can't interact with the modal at all.

This just happened to me, and I see .uploader-window is still covering the modal.

[ericlewis]

I'm gonna close this because I can't write good enough steps to reproduce. I'm seeing it intermittently on a development site of mine, and can't trace the bullet all the way.

Debugging notes A deferred object is created in media.view.UploaderWindow.hide via media.transition which isn't getting resolved, hence never hitting the callback to hide() the UploaderWindow's $el.

[nacin]

Re-opening for review. Someone with more familiarity with this code may be able to track it down with this info.

Was this with stable 3.8.1, or trunk?

[ericlewis]

Replying to nacin:

Was this with stable 3.8.1, or trunk?

trunk

[kovshenin]

What browser and OS are you using? Looks like it might be related or a duplicate of #22974.

[ericlewis]

Replying to kovshenin:

What browser and OS are you using?

Chrome 33 on OS X

[kovshenin]

This was pretty fun to reproduce. Not really :)

tldr: You have to be super lucky, and there's a patch.

All you have to do is drag a file, and drop it *right* when the overlay opacity is 1, but the transition.end event hasn't fired yet. As soon as you drop the file you'll call UploaderWindow's hide() method, where media.transition() attaches the deferred resolution to the transition.end event, which happens right about... now!

Our deferred is resolved when the opacity:1 transition ends and the opacity:0 transition has just begun, at which point the opacity is right around 0.9-ish and our function in .done() just bails.

You can watch all of this in action by logging transition end events:

this.$el.on( $.support.transition.end, function() {
    console.log( 'ended transition' );
});

And some others, like when hide() is called and when the element is actually hidden. You'll see two "ended transition" entries in a row when you're lucky enough. It'll take a while... Setting the transition time to 1500ms in media-views.css for .uploader-window and the background opacity to 1.0 can also help :)

I'm not sure what the best fix would be, but I have an idea.

In media.transition() we have a deferred resolution on _.delay() which is fired if transition.end never happens. This can saves us from when someone drops a file very very quickly before the dropzone is even shown. But it doesn't account for when transition.end in misfired earlier.

So the idea is something very similar, only in UploaderWindow, see 27341.diff​.

[kovshenin]

This is a pretty rare case, not a regression and fairly late for 3.9. If anyone manages to reproduce and can verify the patch works as expected, please leave a comment. Moving to future release for now.

[RMarks]

I had this issue reported to me on a production installation. I found this ticket and applied the patch which has prevented the issue from happening again.

[wonderboymusic]

This happens to me constantly

[ericlewis]

Replying to RMarks:

I found this ticket and applied the patch which has prevented the issue from happening again.

This issue is really hard to reproduce to begin with, so we really need to test this, hopefully get exact steps to reproduce, and make sure this is the right fix.

@kovshevin thanks for diving deep on this one.

[dimagsv]

Patch works for me.

[wonderboymusic]

In 28838:

Race conditions can cause .uploader-window to be visible with opacity of 0. It will cause the user to have to refresh the page or inspect the element to hide it. Add a delay in wp.media.view.UploaderWindow.hide() to ensure that the uploader window is indeed hidden.

Props kovshenin.
Fixes #27341.