Fullscreen Firefox windows fail to refresh normally

[esheltone]

This is easy to reproduce:

• Start playing a YouTube video in Firefox.
• Try to display fullscreen.
• The Firefox window occupies the entire screen, but the video does not. It becomes difficult to interact with the expanded window, and you basically have to shut down Firefox.

Everything works as expected in Google Chrome.

[marmarek]

"becomes difficult to interact" means also window isn't refreshing normally (at least on my system) - only at desktop switch, window resize, focus switch etc. It looks like damage notifications are not delivered anymore (for this window, others are ok).

[marmarek]

"becomes difficult to interact" means also window isn't refreshing normally (at least on my system) - only at desktop switch, window resize, focus switch etc. It looks like damage notifications are not delivered anymore (for this window, others are ok).

[cooloutac]

Same exact thing is happening now on debian firefox-esr and whonix tor-browser. I think since the latest debian updates around when iceweasel was dropped.

[cooloutac]

Same exact thing is happening now on debian firefox-esr and whonix tor-browser. I think since the latest debian updates around when iceweasel was dropped.

[andrewdavidwong]

Note that this occurs whenever you try to enter fullscreen (e.g., by pressing F11) in Firefox, not just when watching fullscreen videos.

[andrewdavidwong]

Note that this occurs whenever you try to enter fullscreen (e.g., by pressing F11) in Firefox, not just when watching fullscreen videos.

[marmarek]

Found it!
It happens only when VM is not allowed to enter full screen, otherwise full screen works fine.

This is because when Firefox (or any other application) request window manager to make the window full screen, window manager acknowledge this by adding _NET_WM_STATE_FULLSCREEN to _NET_WM_STATE window property. If VM is not allowed to have fullscreen windows, nothing like this happens. And apparently Firefox is waiting for this.

It's easy to check it manually:

1. Try to switch Firefox to full screen (F11) - the window will stop responding

2. Open some terminal in the same VM

3. Set _NET_WM_STATE to _NET_WM_STATE_FULLSCREEN:

   xprop -f _NET_WM_STATE 32a -set _NET_WM_STATE _NET_WM_STATE_FULLSCREEN 
   

   Then click on Firefox window.

I don't see any way in the protocol how window manager could reject fullscreen request. So, there are two options:

1. inform the VM at startup whether fullscreen is allowed or not, so gui-agent may decide on adding _NET_WM_STATE_FULLSCREEN to _NET_WM_SUPPORTED on root window (advertise fullscreen support or not)
2. when application request fullscreen, but VM is not allowed to do so, add _NET_WM_STATE_FULLSCREEN, then instantly remove it

The first option is more elegant, but requires minor protocol change (so can't be backported to stable releases). The second option may result in Firefox changing window size, which may be annoying. But at least it will not freeze. It's easy to see that - to remove the _NET_WM_STATE_FULLSCREEN value, replace it with empty string.

@andrewdavidwong @esheltone @cooloutac any opinion?

[marmarek]

Found it!
It happens only when VM is not allowed to enter full screen, otherwise full screen works fine.

This is because when Firefox (or any other application) request window manager to make the window full screen, window manager acknowledge this by adding _NET_WM_STATE_FULLSCREEN to _NET_WM_STATE window property. If VM is not allowed to have fullscreen windows, nothing like this happens. And apparently Firefox is waiting for this.

It's easy to check it manually:

1. Try to switch Firefox to full screen (F11) - the window will stop responding

2. Open some terminal in the same VM

3. Set _NET_WM_STATE to _NET_WM_STATE_FULLSCREEN:

   xprop -f _NET_WM_STATE 32a -set _NET_WM_STATE _NET_WM_STATE_FULLSCREEN 
   

   Then click on Firefox window.

I don't see any way in the protocol how window manager could reject fullscreen request. So, there are two options:

1. inform the VM at startup whether fullscreen is allowed or not, so gui-agent may decide on adding _NET_WM_STATE_FULLSCREEN to _NET_WM_SUPPORTED on root window (advertise fullscreen support or not)
2. when application request fullscreen, but VM is not allowed to do so, add _NET_WM_STATE_FULLSCREEN, then instantly remove it

The first option is more elegant, but requires minor protocol change (so can't be backported to stable releases). The second option may result in Firefox changing window size, which may be annoying. But at least it will not freeze. It's easy to see that - to remove the _NET_WM_STATE_FULLSCREEN value, replace it with empty string.

@andrewdavidwong @esheltone @cooloutac any opinion?

[andrewdavidwong]

No strong personal opinion, but from a UX perspective, the first option is probably to be preferred. The reason is that, with the second option, most users probably won't know (or think to ask) why the Firefox window is changing size whenever they try to enter fullscreen. They'll just think it's a Qubes bug/quirk. (In fact, the new behavior would probably get reported as "new" bug at some point.)

[andrewdavidwong]

No strong personal opinion, but from a UX perspective, the first option is probably to be preferred. The reason is that, with the second option, most users probably won't know (or think to ask) why the Firefox window is changing size whenever they try to enter fullscreen. They'll just think it's a Qubes bug/quirk. (In fact, the new behavior would probably get reported as "new" bug at some point.)

[marmarek]

Actually, there is third option:
3. Add _NET_WM_STATE_FULLSCREEN anyway (and do not remove it), even if the window was just maximized

Will will result in maximized window (so decorations will still be visible), which will behave as fullscreen one (address bar etc will be hidden).

[marmarek]

Actually, there is third option:
3. Add _NET_WM_STATE_FULLSCREEN anyway (and do not remove it), even if the window was just maximized

Will will result in maximized window (so decorations will still be visible), which will behave as fullscreen one (address bar etc will be hidden).

[andrewdavidwong]

How exactly do the first and third options differ from the user's perspective? I understand how things will appear to the user with the third option but not the first one.

[andrewdavidwong]

How exactly do the first and third options differ from the user's perspective? I understand how things will appear to the user with the third option but not the first one.

[marmarek]

1. (not advertising fullscreen support at all): Firefox window isn't resized at all. But still hides address bar.
2. (adding then instantly removing fullscreen flag): Firefox window is maximized, then returns to the normal size. Address bar is not hidden.
3. (adding fullscreen flag, even though the window is just maximized): Firefox window is maximized, address bar is hidden. Window decorations are still visible (so, it isn't real fullscreen).

Anyway, you can try using the above xprop commands.

[marmarek]

1. (not advertising fullscreen support at all): Firefox window isn't resized at all. But still hides address bar.
2. (adding then instantly removing fullscreen flag): Firefox window is maximized, then returns to the normal size. Address bar is not hidden.
3. (adding fullscreen flag, even though the window is just maximized): Firefox window is maximized, address bar is hidden. Window decorations are still visible (so, it isn't real fullscreen).

Anyway, you can try using the above xprop commands.

[andrewdavidwong]

IMHO, the third option is by far the best. No contest.

The first two options unintuitively flout the user's intention and are likely to be interpreted as bugs. (We would have to add some kind of pop-up to explain to the user what just happened, and that would only be "less bad" from a UX perspective.)

Window decorations still being visible in the third option is a feature, not a bug, IMHO. Window decorations should always be preserved unless the user explicitly gives permission to hide them, since that's one of the main security features of Qubes.

[andrewdavidwong]

IMHO, the third option is by far the best. No contest.

The first two options unintuitively flout the user's intention and are likely to be interpreted as bugs. (We would have to add some kind of pop-up to explain to the user what just happened, and that would only be "less bad" from a UX perspective.)

Window decorations still being visible in the third option is a feature, not a bug, IMHO. Window decorations should always be preserved unless the user explicitly gives permission to hide them, since that's one of the main security features of Qubes.

[dmoerner]

Friendly request to push this to current-testing :)

[dmoerner]

Friendly request to push this to current-testing :)

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-dom0-3.2.9-1.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-dom0-3.2.9-1.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[dmoerner]

Unfortunately, I do not see this bug fixed with qubes-gui-dom0-3.2.9-1.fc23 from qubes-dom0-current-testing.

[dmoerner]

Unfortunately, I do not see this bug fixed with qubes-gui-dom0-3.2.9-1.fc23 from qubes-dom0-current-testing.

[marmarek]

Have you restarted VM after applying update?

[marmarek]

Have you restarted VM after applying update?

[dmoerner]

Yes, I have restarted the whole computer and tested in a dispVM. Maximizing any Youtube video causes the problem.

[dmoerner]

Yes, I have restarted the whole computer and tested in a dispVM. Maximizing any Youtube video causes the problem.

[marmarek]

What Firefox version do you have? Which template? What version of qubes-gui-vm package there?

[marmarek]

What Firefox version do you have? Which template? What version of qubes-gui-vm package there?

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-dom0-3.2.9-1.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-dom0-3.2.9-1.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[dmoerner]

Fedora 24, Firefox 51.0.1-2.fc24, qubes-gui-vm 3.2.13-1.fc24. This is on a dispVM on a fresh Qubes R3.2 install.

[dmoerner]

Fedora 24, Firefox 51.0.1-2.fc24, qubes-gui-vm 3.2.13-1.fc24. This is on a dispVM on a fresh Qubes R3.2 install.

[marmarek]

Ok, I've reproduced it. It happens only when Firefox window was already maximized. If not - then F11 make the Firefox window maximized and it's still alive. Also, when it's frozen (because of F11 while it was already maximized), then exiting fullscreen (F11 again) make the window alive again and also not maximized anymore. And then you can try again hitting F11 and this time it will work.

@dmoerner can you confirm it?

Really strange behavior...
While it probably can be somehow fixed, it's getting more and more complex. I propose to fix it as "wontfix" and document somewhere this workaround (if Firefox window freeze, press F11 twice). @andrewdavidwong what do you think?

[marmarek]

Ok, I've reproduced it. It happens only when Firefox window was already maximized. If not - then F11 make the Firefox window maximized and it's still alive. Also, when it's frozen (because of F11 while it was already maximized), then exiting fullscreen (F11 again) make the window alive again and also not maximized anymore. And then you can try again hitting F11 and this time it will work.

@dmoerner can you confirm it?

Really strange behavior...
While it probably can be somehow fixed, it's getting more and more complex. I propose to fix it as "wontfix" and document somewhere this workaround (if Firefox window freeze, press F11 twice). @andrewdavidwong what do you think?

[andrewdavidwong]

Really strange behavior...
While it probably can be somehow fixed, it's getting more and more complex. I propose to fix it as "wontfix" and document somewhere this workaround (if Firefox window freeze, press F11 twice). @andrewdavidwong what do you think?

Agreed. I'll add it to the FAQ.

[andrewdavidwong]

Really strange behavior...
While it probably can be somehow fixed, it's getting more and more complex. I propose to fix it as "wontfix" and document somewhere this workaround (if Firefox window freeze, press F11 twice). @andrewdavidwong what do you think?

Agreed. I'll add it to the FAQ.

[dmoerner]

@marmarek Yes, I can confirm that the problem only arises when the window is already maximized in xfce4.

My apologies, I neglected to say that I was doing this testing on i3 in dom0, which seems to have different behavior from xfce4.

I do see slightly different behavior on i3 - after trying to make Firefox full screen, Firefox is non-responsive as in the initial bug report. I cannot exit fullscreen by hitting F11 to make the window alive again. So here the F11 twice trick does not work.

However, on i3, you can fix the behavior by pressing "$mod-f", to fullscreen the frame, after you've fullscreened the Youtube video. This is not ideal, but works well enough in practice.

[dmoerner]

@marmarek Yes, I can confirm that the problem only arises when the window is already maximized in xfce4.

My apologies, I neglected to say that I was doing this testing on i3 in dom0, which seems to have different behavior from xfce4.

I do see slightly different behavior on i3 - after trying to make Firefox full screen, Firefox is non-responsive as in the initial bug report. I cannot exit fullscreen by hitting F11 to make the window alive again. So here the F11 twice trick does not work.

However, on i3, you can fix the behavior by pressing "$mod-f", to fullscreen the frame, after you've fullscreened the Youtube video. This is not ideal, but works well enough in practice.

[marmarek]

Dropping "wontfix" label, as issue was fixed, partially.

[marmarek]

Dropping "wontfix" label, as issue was fixed, partially.