Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#27899 closed defect (bug) (fixed)

No items found during loading playlist preview

Reported by: pavelevap's profile pavelevap Owned by: nacin's profile nacin
Milestone: 3.9.1 Priority: normal
Severity: normal Version: 3.9
Component: Media Keywords: has-patch commit fixed-major
Focuses: javascript Cc:

Description

For a quick while after opening post with inserted playlist, there is message "No items found." It is only for a sec, but it catching my attention. After a sec, there is nice playlist. But this message is not needed, I guess. Maybe loading indicator would be much better (or simply white box)? And display message only when there are really no items...

Attachments (5)

Preview_No_items_found.jpg (5.7 KB) - added by pavelevap 10 years ago.
27899-01.patch (3.0 KB) - added by gcorne 10 years ago.
27899.diff (4.5 KB) - added by wonderboymusic 10 years ago.
27899.2.diff (5.9 KB) - added by wonderboymusic 10 years ago.
27899.3.diff (6.3 KB) - added by gcorne 10 years ago.

Download all attachments as: .zip

Change History (15)

#1 @nacin
10 years ago

  • Milestone changed from Awaiting Review to 3.9.1

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


10 years ago

@gcorne
10 years ago

#3 @gcorne
10 years ago

  • Focuses javascript added
  • Keywords has-patch dev-feedback added

27899-01.patch adjusts how rendering is handled for the playlist wpview to simplify the code and also to fix this issue and an issue where the undo stack would get "stuck."

@wonderboymusic should probably give this a read and do some testing before it is committed.

#4 @wonderboymusic
10 years ago

  • Keywords dev-feedback removed

27899.diff is my revision - I think your patch was stale against trunk, it wouldn't apply. However, I pulled the necessary pieces out and revised the player unsetting logic to always assume an array, players are always pushed onto a stack when added. Due to the possibility of multiple editor instances, each View instance is always responsible for potentially multiple shortcode instances.

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


10 years ago

@gcorne
10 years ago

#6 @gcorne
10 years ago

For those following along, I think the issue with 27899-01.patch not applying was because I based the patch off the 3.9 branch.

Nonetheless, 27899.3.diff takes the improvements that @wonderboymusic made in 27899.2.diff and switches to the unsetting the players using unbind(), which should work a bit better when the full DOM is rebuilt by TinyMCE. Everything else seems to be working well.

#7 @wonderboymusic
10 years ago

In 28182:

Refinements for asynchronous rendering in wp.mce.media.PlaylistView:

  • Add visibility: hidden as an inline style to <audio> tags, there is a race with the stylesheet which can get enqueued in the body and loaded in the footer.
  • When creating new instances of MediaElementPlayer, always push them onto a stack. Lone views can be responsible for multiple instances of the same shortcode on render.
  • Rename wp.media.mixin.unsetPlayer() to wp.media.mixin.unsetPlayers() to reflect the above.
  • Call wp.media.mixin.unsetPlayers() on the view's unbind() method, instead of inline in the render() method
  • Make sure WPPlaylistView is instantiated for each editor instance
  • Ensure that the No Items Found view state is not rendered when attachments actually do exist.

Props gcorne, wonderboymusic.
See #27899.

#8 @wonderboymusic
10 years ago

  • Keywords commit fixed-major added

#9 @pavelevap
10 years ago

Nice, no more annoying message, media items are loaded gradually in editor. I did not find any problem...

#10 @nacin
10 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 28272:

Refinements for asynchronous rendering in wp.mce.media.PlaylistView.

Merges [28182] to the 3.9 branch.

props gcorne, wonderboymusic.
fixes #27899.

Note: See TracTickets for help on using tickets.