Launchpad has imported 19 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=578265.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2010-07-13T03:07:48+00:00 Compboy07 wrote: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1 After opening a <video> in fullscreen, when using integrated volume knob (ie. on keyboard), fullscreen closes and video resumes in window (Ubuntu 10.04/Firefox 4b1) Reproducible: Always Steps to Reproduce: 1.Start playing video 2.Open fullscreen by right-clicking and clicking 'Full Screen' 3.Use keyboard volume knob to adjust volume Actual Results: Fullscreen closes and returns to window Expected Results: Fullscreen remains open with volume adjusted This bug is specific to Ubuntu, and may have something to do with the volume graphic popping up in GNOME NotifyOSD (the volume widget that appears in the upper-right corner) Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/0 ------------------------------------------------------------------------ On 2011-09-05T19:30:51+00:00 From-bugzilla2 wrote: Created attachment 558327 Testcase based on python-xlib This also happens with my volume knob on LXDE powered by Audacious Media Player and my keybindings (the ones which don't create or show new windows) powered by xbindkeys. It seems that the problem is Firefox killing Fullscreen mode for videos on detection of any input event not directed to it. (In this case, keypresses reserved by XGrabKey) I don't have time to determine how Firefox actually decides what a noteworthy event is, but I've attached a testcase based on python-xlib which demonstrates the issue using the keybinding Ctrl+Super+Spacebar. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/1 ------------------------------------------------------------------------ On 2012-01-02T01:22:09+00:00 Josh Triplett wrote: I just checked with xev, and the hardware volume keys do not result in any key event delivered to Firefox. However, hitting the volume keys causes a window to pop up showing the volume, and the current window receives a couple of FocusOut events followed by a FocusIn event. Firefox automatically un-fullscreens when it loses focus. The same behavior occurs for hardware brightness keys, or anything else that causes a window to pop up. I checked with GNOME2, and KiBi on #xorg-devel confirmed that the same behavior occurs with GNOME3. I suspect that LXDE, Unity, and other desktop environments have the same behavior. I'd actually suggest that a more sensible fix would involve changing the volume display window and similar on-screen display popups to not take focus, since they don't need to accept input. I don't see any way that Firefox can distinguish between losing focus to the volume display window and losing focus due to Alt-Tab or some other reason that should cause un-fullscreening. I've marked this Firefox bug as INVALID, because I don't think Firefox can fix it. I've filed https://bugzilla.gnome.org/show_bug.cgi?id=667110 on gnome-settings- daemon to get this fixed in GNOME 3. Users of other desktop environments should file similar bugs. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/2 ------------------------------------------------------------------------ On 2012-01-05T00:38:40+00:00 Josh Triplett wrote: OK, after further exploration and some discussion on #xorg-devel, it turns out that this bug really does need fixing in Firefox, not in gnome-settings-daemon and similar programs that listen for keys. The FocusOut event occurs as an inherent part of grabbing a keyboard key. gnome-settings-daemon or anything else listening to specific keys such as the hardware volume/brightness keys has to register a passive grab on those keys. A passive grab causes X to start an active grab when the grabbed key occurs. That active grab generates a FocusOut event to the currently focused window, and then the end of the grab generates a FocusIn event. However, the FocusOut event actually indicates the nature of the lost focus, in the .mode field. When a grab occurs, the FocusOut event will have NotifyGrab set. Other types of FocusOut events have NotifyNormal (a normal focus change) or NotifyWhileGrabbed (focus changed while under a grab, so the window won't get it back when the grab ends; occurs in Alt-Tab for instance). xterm, as usual, gets this right. It shows its cursor as hollow when it loses focus, and solid when it has focus. Hitting a grabbed key such as the hardware volume/brightness keys or Alt-Tab does not cause xterm to show the hollow cursor, but actually switching to another window (with Alt-Tab or by clicking on the other window) does. Looking at the source to xterm, in misc.c, in the FocusOut case of HandleFocusChange: /* * XGrabKeyboard() will generate NotifyGrab event that we want to * ignore. */ if (event->mode != NotifyGrab) { unselectwindow(screen, ((event->detail == NotifyPointer) ? INWINDOW : FOCUS)); } I think Firefox needs to apply the same logic: ignore FocusOut events if they have NotifyGrab set. Any actual focus change that Firefox cares about will occur with one of the other flags set. NotifyGrab just means some other program just captured a magic hotkey that Firefox shouldn't care about; that shouldn't cause un-fullscreening. Unfortunately, GDK doesn't currently expose the .mode field of FocusOut events in its GdkEventFocus structure. So, handling this case requires touching the X event directly. Firefox already does this for several other types of events. The simplest fix seems a GDK event filter (gdk_window_add_filter) which returns GDK_FILTER_REMOVE for any FocusOut with mode NotifyGrab. I've discussed this issue with people in the Xorg and GTK+ communities, who also plan to look into the broader issue with other GTK+ applications getting this wrong; for instance, unlike xterm, gnome- terminal shows its hollow not-focused cursor momentarily when pressing grabbed keys. A future GDK may start translating the .mode field of the FocusOut event as part of GdkEventFocus, and GTK+ may change its generation of focus-out-event to handle NotifyGrab differently. However, I still think it makes sense to go ahead and fix this in Firefox. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/3 ------------------------------------------------------------------------ On 2012-01-08T17:27:15+00:00 Alexhultman-0 wrote: Adobe Flash player had a similar bug for years that made it exit fullscreen when changing volume because of the appearing notification. If I watch HTML5 video in fullscreen in Firefox 10b3 and change volume, it too exits fullscreen. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/4 ------------------------------------------------------------------------ On 2012-01-08T19:34:08+00:00 Josh Triplett wrote: (In reply to alexhultman from comment #4) > Adobe Flash player had a similar bug for years that made it exit fullscreen > when changing volume because of the appearing notification. If I watch HTML5 > video in fullscreen in Firefox 10b3 and change volume, it too exits > fullscreen. In this case, though, Firefox exits because of the focus change, not the notification window. That focus change happens independently of the notification window. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/5 ------------------------------------------------------------------------ On 2012-01-20T12:16:33+00:00 Konstartyom wrote: Why does Firefox need to exit fullscreen mode when the focus is lost? I think it is a bad idea because of many reasons. 1. People with multimonitor configurations can't watch a video in fullscreen and work on another monitor at the same time. 2. There are some problems with popups. 3. (annoying for me) When I switch to another desktop with compiz or minimize window to do some little task focus is lost and I need to return to fullscreen again and again... Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/6 ------------------------------------------------------------------------ On 2012-04-25T23:46:23+00:00 Riles wrote: *** Bug 749025 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/7 ------------------------------------------------------------------------ On 2012-08-17T14:36:20+00:00 C-bugz-e wrote: Created attachment 652764 Add filter removing offending events This patch adds extra filtering function, which drops processing of grab notifications events. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/8 ------------------------------------------------------------------------ On 2012-08-20T04:52:59+00:00 Karlt wrote: *** Bug 705363 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/9 ------------------------------------------------------------------------ On 2012-08-20T06:43:40+00:00 Karlt wrote: Comment on attachment 652764 Add filter removing offending events Thanks very much for everyone's analysis here. Bear in mind that GrabKeyboard can also cause a FocusOut event with NotifyGrab mode. While passive grabs are typically short, GrabKeyboard would normally be for longer. I see that Flash remains fullscreen after FocusOut with NotifyGrab, but it does exit fullscreen on a subsequent FocusOut with NotifyWhileGrabbed. Unfortunately, we can't just ignore NotifyGrab because GDK will ignore NotifyWhileGrabbed and we won't get a FocusOut event if focus changes during the grab. Perhaps this approach could be adjusted to synthesize a NotifyGrab FocusOut when one with NotifyWhileGrabbed is received, but I fear that the change in focus behaviour could confuse GTK widgets and menus that use gdk_keyboard_grab and may expect the grab window to have focus. These are used only in dialogs that Gecko opens. My preferred fix here would be to fix bug 724554 by not exiting fullscreen on focus out. (Even if a message is shown on focus in, that need not require explicit acceptance of fullscreen again and so could be transient, or it could even be shown only if focus is lost for some period of time.) If that doesn't work out, I'd prefer a timeout in browser-fullScreen.js, so that it only exits fullscreen if focus is lost for some period of time. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/10 ------------------------------------------------------------------------ On 2012-08-20T22:06:01+00:00 Cpearce-t wrote: (In reply to Karl Tomlinson (:karlt) from comment #10) > My preferred fix here would be to fix bug 724554 by not exiting fullscreen on > focus out. (Even if a message is shown on focus in, that need not require > explicit acceptance of fullscreen again and so could be transient, or it > could even be shown only if focus is lost for some period of time.) Not exiting fullscreen upon blur and showing the "$domain is now fullscreen" warning for a short period of time when when focus returns to a fullscreen window seems like an acceptable compromise to me. I've gotten a lot of feedback from users that they want to be able to blur a fullscreen window (primarily use case is watching a fullscreen video while doing something else in another window/app), so I think this is a good idea. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/11 ------------------------------------------------------------------------ On 2012-09-18T22:47:21+00:00 Cpearce-t wrote: *** Bug 791978 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/12 ------------------------------------------------------------------------ On 2012-11-05T18:25:43+00:00 Dao wrote: *** Bug 743564 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/13 ------------------------------------------------------------------------ On 2012-11-05T23:09:12+00:00 Cpearce-t wrote: (In reply to Chris Pearce (:cpearce) from comment #11) > (In reply to Karl Tomlinson (:karlt) from comment #10) > > My preferred fix here would be to fix bug 724554 by not exiting fullscreen > > on > > focus out. (Even if a message is shown on focus in, that need not require > > explicit acceptance of fullscreen again and so could be transient, or it > > could even be shown only if focus is lost for some period of time.) > > Not exiting fullscreen upon blur and showing the "$domain is now fullscreen" > warning for a short period of time when when focus returns to a fullscreen > window seems like an acceptable compromise to me. I've gotten a lot of > feedback from users that they want to be able to blur a fullscreen window > (primarily use case is watching a fullscreen video while doing something > else in another window/app), so I think this is a good idea. I posted to mozilla.dev.security to request feedback from the security guys about changing to not exit fullscreen on blur, and show a warning on re-focus of fullscreen windows: http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/bcb45e15657af746# I'll see if there's any opposition from the security guys, otherwise I will move ahead with making this change. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/14 ------------------------------------------------------------------------ On 2013-02-05T10:09:48+00:00 Paul-silaghi wrote: *** Bug 836331 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/15 ------------------------------------------------------------------------ On 2013-04-30T09:37:18+00:00 Deletesoftware+moz wrote: *** Bug 866414 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/19 ------------------------------------------------------------------------ On 2013-04-30T09:46:50+00:00 Niburu1-k wrote: Has this issue been fixed post Firefox 20? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/20 ------------------------------------------------------------------------ On 2013-04-30T13:53:33+00:00 Hub-g wrote: It works fine in Nightly now, which is Firefox 23. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1165649/comments/21 ** Changed in: firefox Status: Unknown => Confirmed ** Changed in: firefox Importance: Unknown => Medium ** Bug watch added: GNOME Bug Tracker #667110 https://bugzilla.gnome.org/show_bug.cgi?id=667110 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1165649 Title: html5 video exits fullscreen mode when volume key is pressed Status in The Mozilla Firefox Browser: Confirmed Status in “firefox” package in Ubuntu: Confirmed Bug description: When a html5 video is played in fullscreen mode, and I change volume, the unity volume indicator indicates change in volume, but the full screen mode is escaped in the browser. Example of html5 video to reproduce problem: <video width="320" height="240" controls> <source src="movie.mp4" type="video/mp4"> <source src="movie.ogg" type="video/ogg"> Your browser does not support the video tag. </video> This is accessible on http://www.w3schools.com/html/tryit.asp?filename=tryhtml5_video_all, and make fullscreen by right clicking on the video. Now change volume using volume key on your multimedia keyboard. The fullscreen is escaped. This is also true when a youtube.com/html5 is enabled for html5. Then when playing most videos in full screen, if I change volume, the full screen mode escapes. This is extremely irritating as a video in a non- fullscreen mode plays at 360p quality, and when in full screen by default it does at 480p. Now, if I change volume by using its key on keyboard, it will shift to a non-fullscreen mode and change quality and start rebuffering. Please fix this. ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: firefox 20.0+build1-0ubuntu0.12.10.3 ProcVersionSignature: Ubuntu 3.5.0-26.42-generic 3.5.7.6 Uname: Linux 3.5.0-26-generic x86_64 AddonCompatCheckDisabled: False ApportVersion: 2.6.1-0ubuntu10 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: bha1 2340 F.... pulseaudio BuildID: 20130329030352 Channel: Unavailable Date: Sun Apr 7 10:22:27 2013 ForcedLayersAccel: False IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2012-10-18 (170 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) IpRoute: default via 10.4.1.1 dev eth0 proto static 10.0.0.0/8 dev eth0 proto kernel scope link src 10.4.1.121 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 MarkForUpload: True Plugins: Google Talk Plugin Video Accelerator - /opt/google/talkplugin/libnpgtpo3dautoplugin.so (google-talkplugin) Google Talk Plugin - /opt/google/talkplugin/libnpgoogletalk.so (google-talkplugin) Google Talk Plugin Video Renderer - /opt/google/talkplugin/libnpo1d.so (google-talkplugin) Shockwave Flash - /usr/lib/flashplugin-installer/libflashplayer.so IcedTea-Web Plugin (using IcedTea-Web 1.3 (1.3-1ubuntu1.1)) - /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so (icedtea-7-plugin) PrefSources: prefs.js [Profile]/extensions/{bb6bc1bb-f824-4702-90cd-35e2fb24f25d}/defaults/preferences/cookiemanagerplus-preferences.js Profiles: Profile0 (Default) - LastVersion=20.0/20130329030352 (In use) RelatedPackageVersions: google-talkplugin 3.17.0.0-1 icedtea-7-plugin 1.3-1ubuntu1.1 RunningIncompatibleAddons: False SourcePackage: firefox UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/24/2010 dmi.bios.vendor: Phoenix Technologies LTD dmi.bios.version: V1.34 dmi.board.name: JV50_MV dmi.board.vendor: Acer dmi.board.version: Rev dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: N/A dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrV1.34:bd09/24/2010:svnAcer:pnAspire5738:pvr0100:rvnAcer:rnJV50_MV:rvrRev:cvnAcer:ct10:cvrN/A: dmi.product.name: Aspire 5738 dmi.product.version: 0100 dmi.sys.vendor: Acer http_proxy: http://127.0.0.1:8080/ no_proxy: localhost,127.0.0.0/8 To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1165649/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
