Closed esheltone closed 7 years ago
"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).
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.
Note that this occurs whenever you try to enter fullscreen (e.g., by pressing F11) in Firefox, not just when watching fullscreen videos.
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:
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:
_NET_WM_STATE_FULLSCREEN
to _NET_WM_SUPPORTED
on root window (advertise fullscreen support or not)_NET_WM_STATE_FULLSCREEN
, then instantly remove itThe 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?
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.)
Actually, there is third option:
_NET_WM_STATE_FULLSCREEN
anyway (and do not remove it), even if the window was just maximizedWill will result in maximized window (so decorations will still be visible), which will behave as fullscreen one (address bar etc will be hidden).
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.
Anyway, you can try using the above xprop
commands.
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.
Friendly request to push this to current-testing :)
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
Unfortunately, I do not see this bug fixed with qubes-gui-dom0-3.2.9-1.fc23 from qubes-dom0-current-testing.
Have you restarted VM after applying update?
Yes, I have restarted the whole computer and tested in a dispVM. Maximizing any Youtube video causes the problem.
What Firefox version do you have? Which template? What version of qubes-gui-vm package there?
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.
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.
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?
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.
@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.
Dropping "wontfix" label, as issue was fixed, partially.
I am having this issue with XFCE on Qubes 4. I am fully up-to-date with dom0, fedora 30, and debian 9. I can reproduce both on firefox-esr and the latest firefox (fedora appvm). If I run under Awesome, I have no issue and it works as expected: selecting fullscreen button causes the web-browser interface to disappear and the video to go in fullscreen mode, but with awesomes window border (or titlebar) still showing (which I understand is desired). In XFCE, it does nothing. If I F11 Firefox and then click the fullscreen button on the vid, it will work (along with XFCE still showing a titlebar at the top as desired); however, coming out of it can create really strange update issues. I haven't been able to duplicate the exact pattern here.
I am aware this is a very old issue, but it is exactly the issue I am having. Should I file a new report?
I am having this issue with XFCE on Qubes 4. I am fully up-to-date with dom0, fedora 30, and debian 9. I can reproduce both on firefox-esr and the latest firefox (fedora appvm). If I run under Awesome, I have no issue and it works as expected: selecting fullscreen button causes the web-browser interface to disappear and the video to go in fullscreen mode, but with awesomes window border (or titlebar) still showing (which I understand is desired). In XFCE, it does nothing. If I F11 Firefox and then click the fullscreen button on the vid, it will work (along with XFCE still showing a titlebar at the top as desired); however, coming out of it can create really strange update issues. I haven't been able to duplicate the exact pattern here.
I am aware this is a very old issue, but it is exactly the issue I am having. Should I file a new report?
If it's exactly the same problem, please do not open a duplicate issue.
Reading the discussion above, it looks like part of this fixed, while the other part is a won't fix
. If the part you're experiencing is a regression of the part that was fixed, we can reopen this. However, if it's the part that was a won't fix
, then unless something significant has changed, that's likely still the answer.
This is easy to reproduce:
Everything works as expected in Google Chrome.