https://tcms.engineering.redhat.com/run/51326/#caserun_1811923 Version-Release number of selected component (if applicable): 24.4 Steps to Reproduce: Working RHEVM environment. Change refresh rate to some value in User/PowerUser portal, hover over refresh button and check if it is the value you selected. Then change to some other application window (like terminal...), go back to the browser and hover over refresh button - it shows 60 seconds. Clicking anywhere inside browser having portal opened makes the hovering over refresh button showing good value again. It impacts also real refreshing of objects. Tested RHEL6 FF 10.0.11 and F17 FF 16.0.2. WinXP IE 8 is OK. Actual results: #FIXME Expected results: Hovering over refresh button should show valid value.
when the user-portal is "blurred" (i.e. user-portal window is not in focus), I believe that we change its refresh rate to be the maximal (i.e. 60 seconds). however, when returning the user-portal window to be focused, the refresh-rate should change immediately to the last refresh-rate from before "blurring" the user-portal. From the description, it seems that returning to the user-portal window isn't enough - you need to actively click on something in that window to return it to "focused" mode again. Not sure if this is a user-portal bug or a firefox bug - needs investigation.
Hi Jiri, can you please supply more detailed steps to reproduce? specifically, what do you mean by "change to some other application window" and "go back to the browser"? what were the exact mouse-clicks involved? was a minimize/maximize/restore involved? a video (preferabrely ogv) will be great here. [the exact details are needed in order to figure out if there is an actual bug here, or if this behavior is expected. thanks.]
I cannot reproduce anymore this, but I see refresh rate is independed in each tab in User Portal - Basic and Extended keep its own refresh rate, is this intended?
Jiri, the refresh rate should not be independent so that is a bug. We have general refresh logic rewrite bug already that should include fixing this particular issue: https://bugzilla.redhat.com/show_bug.cgi?id=858166 If you can't reproduce this issue any more could you close the bug?
(In reply to comment #4) > Jiri, the refresh rate should not be independent so that is a bug. We have > general refresh logic rewrite bug already that should include fixing this > particular issue: > https://bugzilla.redhat.com/show_bug.cgi?id=858166 Bug 858166 is actually on a different issue: it is about sync'ing the refresh rate of the different sections in the web-admin (main-tab grid, sub-tab grids, events bottom section) - my bad for referring you (Alex/Jiri) to this BZ - sorry about that. For the matter itself: I don't think that the refresh rate in the Basic view and Extended view should be different, therefore, I think it is a bug. @Tomas: Any chance that you remember if different-refresh-rates in Basic view and Extended view of the user portal is by design or a bug? [@Jiri: please don't close this bug yet; thanks]
Well, this behavior of userportal is common also for webadmin (e.g. userportal's: UserPortalSimpleActionTable inherits this behavior from common SimpleActionTable). So the behavior is the same also for webadmin - all the tabs has their own refresh rates. As far as I remember we did not change this behavior when creating gwt-common project so I guess this was the original implementation. So unless the very first implementation was buggy, it is by design.
Thanks Tomas; it seems to me like there is a bug in the design :) ux-wise: as Jiri implied in his question in Comment #3, I believe that the refresh rate should be the same across the tabs. as the original issue doesn't reproduce - changed the BZ subject to document the new issue. seems to me that it is related to Bug 858166, probably makes sense to take care of both of them together.
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
re-opening; now that bug 858166 is solved, we want to make sure that the refresh rates across the different parts of the application are identical. that means that the refresh rate should be the same across the: - main tabs - sub-tabs - bottom section (Events/Alerts/Tasks)
removing RFE/Feature/Improvement notion from this BZ: Issue was originally reported about the main-tabs that should share the refresh-rate, rather than having a refresh-rate per each main-tab. I expanded the scope of this BZ to take care of sub-tabs and Events bottom section as well - today Events bottom section refresh rate is 5 seconds "hard-coded", which is a bug.
1. When WebAdmin/UserPortal browser tab loses focus, either because you switch to another browser tab or because you focus another application window, refresh rate of currently active (visible) data grid will be set to 60s. When WebAdmin/UserPortal browser tab gains focus, original refresh rate will be restored from browser's local storage. This mechanism exists to throttle HTTP data poll requests when the WebAdmin/UserPortal browser tab isn't focused. 2. Up to now, by design, each main tab's model had its refresh rate controlled separately. For example, you could have VM list refreshed with 5s and DataCenter list refreshed with 30s. I agree that this design isn't very intuitive so unifying refresh rate seems like a good idea to me.
verified with Red Hat Enterprise Virtualization Manager Version: 3.4.0-0.2.master.el6ev
during further testing something odd showed up, I've recorded in on video Host main tab along with its network interfaces tab acts weird in 0:18 -> there is two refresh buttons one for host tab and second for network interfaces subtab in 0:28 -> after clicking on Host main tab refresh button network interfaces just disappear for approx seconds (I believe that progress bar should be shown) in 0:53 -> after window looses focus, refresh button for Network Interfaces disappears in 1:04 -> after clicking on Host main tab refresh button, second refresh button reapears, network interfaces is gone until , Host main tab refresh button is clicked again in 1:24 I did clear cache on FF and reproduced the issue I was also able to reproduce the behavior also with chrome browser
Created attachment 864628 [details] video
tested on Red Hat Enterprise Virtualization Manager Version: 3.4.0-0.2.master.el6ev
(In reply to Martin Pavlik from comment #14) > during further testing something odd showed up, I've recorded in on video > > Host main tab along with its network interfaces tab acts weird > > in 0:18 -> there is two refresh buttons one for host tab and second for > network interfaces subtab > > in 0:28 -> after clicking on Host main tab refresh button network interfaces > just disappear for approx seconds (I believe that progress bar should be > shown) > > in 0:53 -> after window looses focus, refresh button for Network Interfaces > disappears > > in 1:04 -> after clicking on Host main tab refresh button, second refresh > button reapears, network interfaces is gone until , Host main tab refresh > button is clicked again in 1:24 > > I did clear cache on FF and reproduced the issue > I was also able to reproduce the behavior also with chrome browser Martin, thank you for the detailed problem explanation and for the video. however, this is not related to this BZ, which is about sync'ing the *automatic* refresh rate across the different parts of the GUI (your issue is about *manual* refresh) - can you please move this BZ back to VERIFIED (assuming that the *automatic* refresh is behaving correctly) and open a new BZ on the issue that you found? thanks in advance.
Sorry, opening new BZ for issue from comment 14, putting this back to verified.
This bug is referenced in ovirt-engine-3.4.0-beta3 logs. Moving to ON_QA
Alex, can your patch http://gerrit.ovirt.org/#/c/24213/ for this bug be a cause for Bug 1066979 - [RHEVM] [wbadmin] event logs do not auto refresh ?
Yes it is the cause, I am working on a fix right now. http://gerrit.ovirt.org/#/c/24409/ is the current state of the patch. It is almost ready to be merged.
(In reply to Martin Pavlik from comment #18) > Sorry, opening new BZ for issue from comment 14, putting this back to > verified. Thanks, Martin. [just for tracking purposes: the BZ for the manual refresh problem is Bug 1066827 (ovirt)]
since patch [1]/[2] caused a lot of problems, we are in the process of reverting it from the 3.4 repo (patch [3]). We will fix [1] (master) in following patches (which we may or may not backport to ovirt-engine-3.4) - currently re-flagging for 3.5. [1] http://gerrit.ovirt.org/#/c/23605/ (master) [2] http://gerrit.ovirt.org/#/c/24213/ (ovirt-engine-3.4, backport of [1]) [3] http://gerrit.ovirt.org/#/c/24835/ (ovirt-engine-3.4, revert of [2])
I see still strange issues: - Admin Portal 1. change refresh rate in Admin Portal to 20 secs 2. hover over the icon to see it shows 20 secs 3. move mouse cursor to titlebar of another X11 window and click on the titlebar (thus activate another X11 window) 4. move mouse cursor without any clicking to Admin portal window and hover over the refresh icon 5. you should see 60 secs but when expanding refresh rate list you will see 20 secs as defined IMHO it should be failed QA. - refresh between Admin Portal and User Portal 1. changing refresh rate in Admin Portal caused changed refresh rate in User Portal (and visa-versa). * login to AP, change refresh to 10 secs * logout * login to UP, check refresh rate (it is set to 10 secs, thus overwritten by changing in Admin Portal)
ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140821064931.gitb794d66.el6.noarch ovirt-engine-userportal-3.5.0-0.0.master.20140821064931.gitb794d66.el6.noarch
after discussion the current issue is one described in #9. this is not reproducible anymore with versions in #25. the "strange" issue described in #24 works as expected. > 14:12 <awels> Since if you click outside of the browser window, the refresh is > set to 60 seconds. So hovering over it will show the 60 seconds as expected, > but then when you expect the drop down, you set focus on the browser and thus > the refresh is set to what it was before, and you see that reflected.
So your original issues is actually works as designed. Aka if the browser does not have focus, the tooltip will show 60s, but when you expand drop drown it will show the current value, as the browser now has focus. After some comments this bug turning into, the refresh rate should be the same across the board. Aka if I change it to 10s in one tab, and I switch to another tab, that tab should also show 10s. You should also see the refresh of hidden active models be the same. For instance the event refresh should match the refresh rate selected in the drop down. You can verify this by watching the log and seeing the same couple of requests come in at the same time.