The gstreamer plugin should provide information about the video- and audio-codec in use by the video. This information should be accessible for running videos (presumably via context menu) and in particular for videos the codec for either video and/or audio is missing, because it currently is a big problem to find out "what is wrong", if a video doesn't play.
If the video doesn't load there won't be a context menu for it. I think the right solution is to use GStreamer's codec-installer infrastructure like suggested in bug 34085. *** This bug has been marked as a duplicate of bug 34085 ***
I don't see how your answer relates to this issue. The point of this report is to provide either such a context menu or a message in place.
(In reply to comment #2) > I don't see how your answer relates to this issue. The point of this report is to provide either such a context menu or a message in place. If we provide a proxy to the codec-installer via WebKit (the MediaPlayerClient suggested in bug 34085 would do that), the browser could take action: - display a message or popup - trigger a codec-installer program integrated with the user's distro, like gnome-codec-install in Debian.
(In reply to comment #3) > - trigger a codec-installer program integrated with the user's distro, like gnome-codec-install in Debian. The MediaPlayerClient could have an API to call gst_install_plugins_async(). Anyway, yes maybe we could display the codecs used somewhere. But as I say in comment 1 if the video fails to load there won't be any contextual menu for the element, AFAIK.
*** This bug has been marked as a duplicate of bug 34085 ***
You make it sound as if Webkit was to rely on something else to provide the context menu. Why do you think Webkit could not display a context menu?!
(In reply to comment #6) > You make it sound as if Webkit was to rely on something else to provide the context menu. Why do you think Webkit could not display a context menu?! Looks like there's another misunderstanding then. WebKit can display context menus, and browser implementations can as well :) But the GTK port would be the first to display video infos in such context menu, AFAIK. I'm not saying it's a bad thing, it just probably requires some thinking and discussion with the other developers involved in WebKit Media area.