Bug 1144449

Summary: always fullscreen for SPICE-xpi
Product: Red Hat Enterprise Virtualization Manager Reporter: Tomas Pelka <tpelka>
Component: ovirt-engine-userportalAssignee: Nobody <nobody>
Status: CLOSED DUPLICATE QA Contact: Pavel Novotny <pnovotny>
Severity: high Docs Contact:
Priority: high    
Version: 3.5.0CC: dblechte, ecohen, gklein, iheim, jjongsma, lsurette, michal.skrivanek, mkalinin, mkrcmari, ofrenkel, rbalakri, Rhev-m-bugs, sherold, tjamrisk, tspeetje, uril, vehrlich, yeylon
Target Milestone: ---   
Target Release: 3.5.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Copied from bug 1155764: Cause: CONTROLLER_AUTO_DISPLAY_RES flag is always set when using the RHEVM portal. When CONTROLLER_AUTO_DISPLAY_RES is set the client is opened in full screen mode. Consequence: Client is always opened in the full screen mode. Fix: Ignore CONTROLLER_AUTO_DISPLAY_RES flag. Result: Client is opened in full screen mode only when is set to full screen (CONTROLLER_SET_FULL_SCREEN flag is set)
Story Points: ---
Clone Of:
: 1149352 (view as bug list) Environment:
Last Closed: 2014-10-30 15:25:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1149352, 1155764    
Bug Blocks:    

Description Tomas Pelka 2014-09-19 12:13:03 UTC
Description of problem:
UserPortal passing always fullscreen=1 option, even if .vv file includes fulscreen=0. 

Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization Manager Version: 3.5.0-0.10.master.el6ev

How reproducible:
100%

Steps to Reproduce:
1. have a win guest with tools installed 
2. uncheck "Open Full Screen" in console oprions
3.

Actual results:
guest system start in fullscreen

Expected results:
guest system should start in window

Additional info:

Comment 1 Tomas Pelka 2014-09-19 13:15:44 UTC
I forgot to mention that I got this issue on:

Client: Rhel7.1
Host: Rhel6.6
Guest: W7 64b

Comment 2 Vaclav Ehrlich 2014-09-22 11:14:29 UTC
Same here:
Client RHEL6.6, spice-xpi-2.7-25.el6.x86_64
Guest Windows 7 32b

Comment 3 Frantisek Kobzik 2014-09-22 12:24:13 UTC
Guys, could someone check if this behavior is reproducible also without guest tools? 

(I did a quick naive test with spice-xpi from fedora 20 and FF 32 and it seems ok.)

Comment 4 Vaclav Ehrlich 2014-09-22 12:39:58 UTC
Yes we can ...

Comment 5 Vaclav Ehrlich 2014-09-22 12:47:15 UTC
Without RHEV-Tools (3.5.2) it seems to work (also with spice-xpi) ... work means connect in window mode then 'Open in Full Screen' is not checked

Comment 6 Michal Skrivanek 2014-09-24 13:40:54 UTC
RHEV sends the correct value as well (fullscreen=0,admin_console=0, when tools _are installed_)
Then the XPI "logic" kicks in, note it's unchanged for a long time, at least 3.1:

SendValue(CONTROLLER_FULL_SCREEN,
     (m_fullscreen == PR_TRUE ? CONTROLLER_SET_FULL_SCREEN : 0) |
     (m_admin_console == PR_FALSE ? CONTROLLER_AUTO_DISPLAY_RES : 0));

so ultimately what's sent to SPICE is correct (CONTROLLER_FULL_SCREEN == 2)

there were some changes in the interpretation of this value in 3.3(3.4?) IIRC…so maybe that's it?

Comment 7 Jonathon Jongsma 2014-10-03 19:19:00 UTC
upstream virt-viewer has a fix for this: 7212c8745a4853e99e9a5a1473aa45ce141c2506

Comment 10 Michal Skrivanek 2014-10-03 21:42:59 UTC
moving to 3.5.1 for now due to dependency on virt-viewer fix

Comment 11 Frantisek Kobzik 2014-10-09 08:26:18 UTC
*** Bug 1147926 has been marked as a duplicate of this bug. ***

Comment 14 Vaclav Ehrlich 2014-10-29 15:53:48 UTC
(In reply to Tomas Pelka from comment #0)
> Description of problem:
> UserPortal passing always fullscreen=1 option, even if .vv file includes
> fulscreen=0. 
> 


Ok now it seems to work, but only if you use *.vv file. Via XPI problem persists
RHEVM 3.5.0-0.17.beta.el6ev

Comment 15 Michal Skrivanek 2014-10-30 15:25:30 UTC

*** This bug has been marked as a duplicate of bug 1149352 ***