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

Reply via email to