Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#27341 closed defect (bug) (fixed)

.uploader-window doesn't disappear

Reported by: ericlewis's profile ericlewis Owned by: wonderboymusic's profile wonderboymusic
Milestone: 4.0 Priority: normal
Severity: normal Version: 3.7
Component: Media Keywords: has-patch needs-testing
Focuses: javascript Cc:


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.

Attachments (1)

27341.diff (468 bytes) - added by kovshenin 10 years ago.

Download all attachments as: .zip

Change History (16)

#1 @ericlewis
10 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

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.

#2 follow-up: @nacin
10 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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?

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.

10 years ago

#4 in reply to: ↑ 2 @ericlewis
10 years ago

Replying to nacin:

Was this with stable 3.8.1, or trunk?


#5 @nacin
10 years ago

  • Milestone changed from Awaiting Review to 3.9
  • Version changed from 3.8.1 to trunk

This ticket was mentioned in IRC in #wordpress-dev by doc-bot. View the logs.

10 years ago

#7 follow-up: @kovshenin
10 years ago

  • Keywords reporter-feedback added

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

#8 in reply to: ↑ 7 @ericlewis
10 years ago

Replying to kovshenin:

What browser and OS are you using?

Chrome 33 on OS X

10 years ago

#9 @kovshenin
10 years ago

  • Focuses javascript added; ui removed
  • Keywords dev-feedback has-patch needs-testing added; reporter-feedback removed
  • Version changed from trunk to 3.7

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.

#10 @kovshenin
10 years ago

  • Keywords dev-feedback removed
  • Milestone changed from 3.9 to Future Release

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.

#11 follow-up: @RMarks
10 years ago

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.

#12 @wonderboymusic
10 years ago

  • Milestone changed from Future Release to 4.0

This happens to me constantly

#13 in reply to: ↑ 11 @ericlewis
10 years ago

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.

#14 @dimagsv
10 years ago

Patch works for me.

#15 @wonderboymusic
10 years ago

  • Owner set to wonderboymusic
  • Resolution set to fixed
  • Status changed from reopened to closed

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 to ensure that the uploader window is indeed hidden.

Props kovshenin.
Fixes #27341.

Note: See TracTickets for help on using tickets.