Steps to reproduce:
0) Startup gnome-shell if needed
1) Ensure that totem isn't running.
2) Double-click on a video file in nautilus.
3) Note that the video opens up in the foreground (i.e. raised and with
   focus).
4) While video is playing, go back to the nautilus window and
   double-click on another video file.

Expected:
- The second video replaces the first video and plays in the foreground,
  raised and with focus, much as was done for the first video.

Actual:
- The second video replaces the first video and plays, but it is not
  raised or focused.
- With totem versions before commit da365fae, a "Movie player is ready"
  notification is presented by gnome-shell.  After that commit, no
  notification appears. 
- If the video is sufficiently obscured by other windows (such as the
  nautilus window), then the naive user, who was ready to watch the
  second video, concludes that their computer failed to open the video.

I'm aware that this is the intended behavior (bug 664492), but I fear
that is is a usability problem.  The "naive user" scenario actually
happened when my mom tried to browse a collection of videos using a
Debian stable system running Gnome (totem version == 3.0.1).  In this
case, the second video was fully obscured by the nautilus window,
leaving her flustered and confused ("Daniel! It's not working!").

When I tried to explain that the video was playing in the backgrounded
totem window, she didn't understand it ("What window?  Where?").  We
could hear the audio playing, but neither that nor the "Movie player is
ready" notification were enough to clear up the confusion.  I ended up
taking the laptop and raising the window myself.

This could easily have happened with later totem versions, including git
master, as they exhibit this behavior as well.

Speaking for myself, I would prefer that totem present itself when the
video is replaced: I'm opening the video 'cause I wanna *see* it. :)  In
many other apps (including gedit, evince, and epiphany), opening a
document/image/whatever brings that thing to the foreground regardless
of the app's prior state; that's generally what I want and expect.

FYI: while Debian's totem precedes the commit that officially introduces
this behavior (da365fae), it also precedes commit bc677491, which fixes
startup notification.  That might account for why mutter/gnome-shell
generates a notification instead of raising the window.

Thanks,
Daniel