Description of problem: if spice-activex is not present, wait with setting the ticket till it downloads and installs Version-Release number of selected component (if applicable): si16.2 How reproducible: always Steps to Reproduce: 1. on "pristine" VM, launch a console from IE 2. delay the download+installation time for 2+ minutes 3. Actual results: remote-viewer launches asking for password (because tiket validity has expired) Expected results: remote viewer either connects successfully or closes with error ==> add the check to the portal if the ticked didn't already expire before actual client launch and if it did, ask backend for a new one Additional info:
(In reply to comment #0) <snip> > 1. on "pristine" VM, launch a console from IE "pristine _client Windows machine_ of course
I'm missing why this wasn't an issue with previous versions? can you reproduce this with 3.0 and its active x version of spice (pre virt-viewer)? can you reproduce this with 3.0 and the new version of virt-viewer?
(In reply to comment #2) > I'm missing why this wasn't an issue with previous versions? Because spicec used to silently exit without even launching a window - after installation, user just seen nothing happening and launched the client once more. Because of design changes (interactive password entry to prevent password being typed on command line), virt-viewer behaves differently and I don't see much space for fix on its side. > can you reproduce this with 3.0 and its active x version of spice (pre > virt-viewer)? can you reproduce this with 3.0 and the new version of > virt-viewer? Based on info above, I guess the answers are "no" and "yes". Actually, > ==> add the check to the portal if the ticked didn't already expire before > actual client launch and if it did, ask backend for a new one is probably wrong suggestion, it would be better not to ask for ticket at all if activex is not installed and ask for it just right before client launch.
Moving this BZ to rhev-m future. We'll create BZ's on remote-viewer and active-X to mirror the old behaviour
Bug occurs on clean installation of si19, too. Notes for reproducing it: 1) if you connect to your RHEV-M via low-bandwidth connection such as VPN on another continent, you're much more likely to hit the bug. 2) because of bug 857038, it's quite easy to repeat the bug on 64b client just by switching to the other IE (64b if you reproduced on 32b)
*** Bug 868958 has been marked as a duplicate of this bug. ***
From the duplicate: =================== I have seen it be more reproducible by making a remote-viewer connection and closing it before the display is brought up and then trying to bring up the remote-viewer window again. But I have also seen it come up just connecting to it for the first time in a browser session. *Tested on Win 7 64 client, I've seen it a occur 4 or 5 times. I also tested on a Win 7 32 bit client, but never saw it on that client. =================== Andy, this seems to be pretty serious ux regression, surely something not to be resolved in -future, so I'm resetting the flag to rhevm-3.1.0? again.
seems it's doable on our side too and it would provide a better user experience. We also need to have some visual feedback for the time between the click and activex initialization
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
finally we care about activex less and less. Let's hope it dies in a terrible agony really soon