Bug 1098598 - [Admin Portal] "Unresponsive script" error on login
Summary: [Admin Portal] "Unresponsive script" error on login
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.6.0
Assignee: Nobody
QA Contact: Pavel Stehlik
Whiteboard: ux
Depends On:
TreeView+ depends on / blocked
Reported: 2014-05-16 15:52 UTC by Evgheni Dereveanchin
Modified: 2019-04-28 10:01 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-03-18 08:14:05 UTC
oVirt Team: ---
Target Upstream Version:

Attachments (Terms of Use)
screenshot displaying error (41.61 KB, image/png)
2014-05-16 15:53 UTC, Evgheni Dereveanchin
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1123396 medium CLOSED Admin Portal: Unresponsive script leading to Virtual Machines not being displayed any more 2020-10-14 00:28:05 UTC

Internal Links: 1123396

Description Evgheni Dereveanchin 2014-05-16 15:52:47 UTC
Description of problem:
when logging into the RHEV-M Admin Portal, firefox displays a "Unresponsive script" warning message

Version-Release number of selected component (if applicable):
RHEV-M 3.2, 3.3
RHEL 6.5 client
Firefox 24

Steps to Reproduce:
1. open rhev-m admin portal
2. log in as admin

Actual results:
after some time, a "Unresponsive Script" warning is displayed. Dismissing it does not load the portal. Refreshing the page is required to actually work.

Expected results:
user is able to log in

Comment 1 Evgheni Dereveanchin 2014-05-16 15:53:26 UTC
Created attachment 896460 [details]
screenshot displaying error

Comment 3 Einav Cohen 2014-05-20 12:42:45 UTC
sounds related to bug 1054242. 
Evgheni: which FF24 exact version are you using? 
can you please make sure that you are using the one distributed via the errata linked to bug 1054242?

Comment 4 Evgheni Dereveanchin 2014-05-21 08:42:50 UTC
Einav, I'm using the latest firefox build available in the repo. This new BZ was opened specifically because in BZ#1054242 it was recommended to open a new bug about performance issues. The memory leak seems to have been fixed, but I still see the stuck script warning.

# rpm -qi firefox
Name        : firefox                      Relocations: (not relocatable)
Version     : 24.5.0                            Vendor: Red Hat, Inc.
Release     : 1.el6_5                       Build Date: Tue 22 Apr 2014 04:31:09 PM CEST
Install Date: Wed 30 Apr 2014 11:24:03 AM CEST      Build Host: x86-026.build.eng.bos.redhat.com
Group       : Applications/Internet         Source RPM: firefox-24.5.0-1.el6_5.src.rpm
Size        : 83232863                         License: MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : RSA/8, Mon 28 Apr 2014 08:52:43 AM CEST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.mozilla.org/projects/firefox/
Summary     : Mozilla Firefox Web browser
Description :
Mozilla Firefox is an open-source web browser, designed for standards
compliance, performance and portability.

Comment 5 Einav Cohen 2014-05-22 09:58:47 UTC
Thanks, Evgheni. What happens when you are trying to run the RHEV-M GUI on FF17 on the same client / another identical client?
[need to understand if this is a FF regression, or if this always have been the state of the GUI for such client]?

Comment 6 Evgheni Dereveanchin 2014-05-22 12:17:45 UTC
Einav,just checked, I also get the error on FF17:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: https://<hostname>/webadmin/webadmin/703514569DB8B555E64E057CF39EEA11.cache.html:10762

The steps were (on the same RHEL 6.5 machine):
# yum downgrade firefox-17.0.10-1.el6_4
# useradd ff17user
# passwd  ff17user

Then I took the "sux" shellscript from debian to save myself from logging into new sessions and ran firefox from there:

$ sux ff17user
$ firefox

The first attempt to log in did not display the warning, but logging out and then back in did the trick.

Comment 7 Einav Cohen 2014-05-22 15:02:33 UTC
Thanks, Evgheni. 

- IIUC, the problem is just with the initial loading of the application. i.e. when refreshing the page, the problem goes away, correct?

- Can you please try testing RHEV-3.4 and also ovirt-3.5.0-alpha? There is a chance that after the frontend refactoring + PatternFly adoption that we did, initial-loading performance has changed (hopefully improved).

Comment 8 Evgheni Dereveanchin 2014-05-22 15:43:29 UTC
I will try to test this out, however I do not remember any versions of oVirt displaying this warning, even when corresponding RHEV versions of RHEV did so.

Comment 10 Evgheni Dereveanchin 2014-06-10 12:41:22 UTC
Just tried a 3.4 Admin Portal and the warning is still there for me

Comment 11 Einav Cohen 2014-06-27 22:16:23 UTC
since this is not a regression (happening as early as 3.2), I am pushing for 3.6 for now. I am not sure if we will be able to do anything about it - maybe the lazy initialization approach [1] will help?

also: we never outlined minimal client requirement (though "core2duo CPU and 4 gigs of RAM" sounds reasonable for a client). 

[1] http://gerrit.ovirt.org/#/c/29078/

Comment 16 Evgheni Dereveanchin 2014-07-29 14:46:13 UTC
I still get the warning each day on my RHEL6 machine when opening a 3.4 portal.

Maybe I've described what happens but let me reiterate:
1) I log in (no matter if local or LDAP user is used)
2) I get the warning message
3) I press the "stop script" button
4) I am left staring at a gray page and URL https://<rhevm>/ovirt-engine/webadmin/?locale=en_US#login in the address bar
5) if I refresh the page nothing happens
6) if I remove "#login" from the URL, I am forwarded to the portal without being prompted for a password again. This means authentication happens successfully, and there's something after it which freezes the process.

Comment 32 Evgheni Dereveanchin 2015-01-02 16:27:16 UTC
FYI I upgraded the my test RHEL desktop to an HP Z400 (8G RAM, quad core Xeon W3550, nvidia quadro FX 380 & 304 series driver) and still see warning popups daily.

So faster hardware made no difference in my case.

Comment 33 Alexander Wels 2015-01-06 13:09:19 UTC

I don't think getting faster hardware will help much, getting faster hardware on the engine and getting a faster network connection will help. The problem basically is that the application tries to open 80+ connections at once to download a piece of code to execute. Browsers have a limit of the number of concurrent connections allowed. So each connection after the first 4-8 has to wait for the previous one the be done before proceeding, this can take some time and causes the popup to appear.

Depending on the browser this limit is somewhere between 4 and 8. You could try tweaking the number to be higher in the undocumented settings of firefox to see if it help, but I doubt it.

For 3.5 we have solved the issue of it opening so many connections at the same time so it should be much better.

Comment 34 Evgheni Dereveanchin 2015-01-06 17:01:33 UTC
Just tried to open an oVirt 3.5 portal and indeed the message does not seem to show up after re-login. The interface freezes for 20 seconds after clicking on anything for the first time, but that's probably something unrelated.

Let's wait till 3.5 is released to confirm the issue is completely gone and then  close this BZ.

Comment 35 Yaniv Lavi 2015-03-12 15:01:50 UTC
Can you try to recreate it on 3.5?

Comment 36 Pavel Novotny 2015-03-17 16:57:55 UTC
(In reply to Yaniv Dary from comment #35)
> Can you try to recreate it on 3.5?

I cannot reproduce it on 3.5.0 nor 3.5.1 (vt14).
I used RHEL 6 client with firefox-31.5.0-1.el6_6.x86_64 and 4 GB RAM (2,9GB free).
I logged into Webadmin portal, worked in it for a while, then logged out & logged in again. I repeated it three times and didn't encountered any "unresponsive script" dialog.

Comment 37 Yaniv Lavi 2015-03-18 08:14:05 UTC
Closing due to comment #34 and comment #36.

Note You need to log in before you can comment on or make changes to this bug.