GNOME Bugzilla – Bug 452063
Does not retain volume level between videos
Last modified: 2007-08-16 18:54:22 UTC
[ Forwarded from http://bugs.debian.org/430467 ] "If I change the volume while watching a video, then go to another page and watch another video, the volume is reset to its original level. It wish it would retain the level I set it to."
Known bug, as we currently just kill the viewer, which doesn't get a chance to save its state.
2007-08-15 Bastien Nocera <hadess@hadess.net> * browser-plugin/org_gnome_totem_PluginViewer.xml: * browser-plugin/totem-plugin-viewer.c: (totem_embedded_save_state): * browser-plugin/totemPlugin.cpp: Call SaveState just before killing the plugin, so that it can save some details (such as the volume), does nothing yet though (Helps: #452063) Just need to write the 3 lines of code to save the volume now.
Does the function on the plugin side actually get called? dbus_g_proxy_call_with_timeout invokes the method async when the programme returns to the mainloop, and by that time we'll already have killed the viewer... (Note that I'm NOT advocating using sync method invocation!)
(In reply to comment #3) > Does the function on the plugin side actually get called? > dbus_g_proxy_call_with_timeout invokes the method async when the programme > returns to the mainloop, and by that time we'll already have killed the > viewer... It did in my (short) tests. I was hoping it was a sync method for which we'd keep a _short_ timeout. The downside being that it might hang if the program hangs for whatever reason, but it's only for a very short time. > (Note that I'm NOT advocating using sync method invocation!) It's either that or updating gconf each time the volume is changed. What do you think is best?
(In reply to comment #4) > (In reply to comment #3) > > Does the function on the plugin side actually get called? > > dbus_g_proxy_call_with_timeout invokes the method async when the programme > > returns to the mainloop, and by that time we'll already have killed the > > viewer... > > It did in my (short) tests. I was hoping it was a sync method for which we'd > keep a _short_ timeout. The downside being that it might hang if the program > hangs for whatever reason, but it's only for a very short time. Actually you're right, it's sync. I was looking at the wrong function in the API docs. That explains that it's actually calling the remote method. We really shouldn't be running a recursive mainloop from plugin code. I didn't rewrite the whole plugin to be async for nothing :) It will hang the programme for 1) a short time _per plugin_ (there may be many many plugins on the page), 2) is a security hole (you don't push a null JS context on the stack), and 3) will cause the weirdest crashes. > It's either that or updating gconf each time the volume is changed. What do you > think is best? In that case, update the gconf key when the volume changes. Or alternatively, don't kill the viewer, and just invoke a "quit" method? (That might fail however if the whole browser is quitting and thus we never enter the mainloop again to send the method invocation.)
I'll revert and go with the GConf changes then.
2007-08-16 Bastien Nocera <hadess@hadess.net> * browser-plugin/org_gnome_totem_PluginViewer.xml: * browser-plugin/totem-plugin-viewer.c: (totem_embedded_save_volume), (property_notify_cb_volume): * browser-plugin/totemPlugin.cpp: Revert "SaveState" patch and save the volume in GConf as soon as it's changed in the UI (Closes: #452063)
*** Bug 359543 has been marked as a duplicate of this bug. ***