Description of problem: When user selects virt-viewer as default application in Firefox, It still prompts for how to open the file. This happens only when VM portal is used and does not happen with Admin portal. Version-Release number of selected component (if applicable): RHV 4.2 VM portal How reproducible: 100% Steps to Reproduce: 1. Open Firefox settings and set virt-viewer as default application to open .vv file. 2. Open RHV-Manager VM portal and click on VM console. 3. It prompts for application to use for console. Actual results: It prompts window to open console.vv while using VM portal. Expected results: Directly Virt-Viewer/Remote-viewer application should open with VM console. Additional info: 1) I have observed that the "from" part of the prompt is RHV-M FQDN when opened from Admin portal. Where as for VM portal the prompt is having "from" part as "data:" <blank> 2) Also, When I edited the console.vv from Admin portal and VM portal there is difference in URL used. I will attach the prompt window in the case for further understanding.
I duplicated. It only happens on Firefox -- chrome is fine. In admin portal, it's a regular request (cause = 'subdocument' in network tab) for the .vv file. In vm portal, it's an xhr (cause = 'xhr') request. Firefox must not handle that the same.
which Firefox is that exactly?
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
sync2jira
I looked into this a bit awhile ago, here are my thoughts on doing the console.vv on server side: - The console.vv isn't just passed along from the API, it goes through an adjustment. The function is in [0]. - Whatever is done in that function needs to be duplicated on the server code, or it needs to be dropped. - I don't know why the console.vv is adjusted like this, except maybe to adopt some configurations that are stored on web-ui itself. - Webadmin will also generate a console.vv file, but the GWT code does stuff and then routes the browser along to "/ovirt-engine/services/attachment/console.vv" which is [1]. Looks like that servlet just takes POST data and returns it as the response. The bit of GWT code that actually calls it is [2]. Given all of that info, there are a few things that we could do: - Reimplement the GetAttachmentServlet in ovirt-web-ui modeled after the branding jsp [3] - Maybe reuse the one in webadmin. It'll probably work as long as the SSO tokens get passed along, the URL is formed correctly and web-ui is running in the engine. Just need to get the POST request fired in the right way. GWT code inserts a form, submits it and targets the response to open in an iframe (if I saw things happen correctly). - If we want it to work when web-ui is running in dev mode (like how the container does it), something will probably have to be done in the webpack dev server proxy configs to enable access to something other than the rest endpoints. Maybe it can be configured with another proxy for the GetAttachementServlet when running in dev mode. Prod/installed mode would use the jsp or engine's attachment servlet. [0] - https://github.com/oVirt/ovirt-web-ui/blob/master/src/sagas/console/vvFileUtils.js [1] - https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/services/src/main/java/org/ovirt/engine/core/services/GetAttachmentServlet.java [2] - https://github.com/oVirt/ovirt-engine/blob/2b34f2d3b8fa2aea63883e59418148598c4eb05f/frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/vms/ConsoleModel.java#L205-L224 [3] - https://github.com/oVirt/ovirt-web-ui/blob/master/packaging/ovirt-web-ui.war/WEB-INF/branding.jsp
Fix: https://github.com/oVirt/ovirt-web-ui/pull/1243
Steps: 1. Open Firefox settings and set virt-viewer as default application to open .vv file. 2. Open RHV-Manager VM portal and click on VM console. 3. It prompts for application to use for console. Results: Download window is only shown when no default behavior is set in the browser. After changing the settings, virt-viewer is used directly skipping the download prompt window. Verified in: ovirt-engine-4.4.2.3-0.6.el8ev.noarch ovirt-web-ui-1.6.4-1.el8ev.noarch firefox-78.0.2-1.fc31.x86_64
Created attachment 1713354 [details] downloaded console file name
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Red Hat Virtualization security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3807