Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1071322

Summary:	[Admin Portal] Left-pane tree not uncollapsed to previous width after web page refresh with button click
Product:	[Retired] oVirt	Reporter:	Jiri Belka <jbelka>
Component:	ovirt-engine-webadmin	Assignee:	Alexander Wels <awels>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jiri Belka <jbelka>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.4	CC:	ecohen, gklein, iheim, mgoldboi, pstehlik, rbalakri, yeylon
Target Milestone:	---
Target Release:	3.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	ux
Fixed In Version:	ovirt-3.5.0-alpha1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-10-17 12:22:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	UX	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jiri Belka 2014-02-28 13:38:51 UTC

Similar as BZ1071316.

Description of problem:

Left-pane tree does not uncollapse to its previous width size with button click after web page refresh. See following TCMS case:

* Setup

  Have >= 3.4 Admin Portal, left pane is not-visible/collapsed, before
  collapsing the left pane its width was half-screen width size.

* Actions

  - refresh the entire page. click on the button

So, one has left-pane tree half-screen width size, then you collapse it (button, dragging...), refresh the page  (^r), then uncollapse with clicking on collapse/uncollapse button, its width size would be the default one, not previous half-screen width size.

So it looks like when left-pane tree width is zero then refresh makes lose its previous width and thus it is uncollapsed to its default size.

Version-Release number of selected component (if applicable):
beta3 ovirt-engine-webadmin-portal-3.4.0-0.11.beta3.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. left pane its width is half-screen width size, then collapse left pane with collapse button
2. refresh the entire page, click on the button
3.

Actual results:
uncollapse to defualt size

Expected results:
should uncollapse to its previous width

Additional info:

Comment 1 Jiri Belka 2014-02-28 14:03:59 UTC

Both Firefox and IE.

Comment 2 Itamar Heim 2014-03-02 05:42:43 UTC

Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

Comment 3 Sandro Bonazzola 2014-03-04 09:19:22 UTC

This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

Comment 4 Einav Cohen 2014-03-05 14:29:42 UTC

medium severity issue - setting Target Release to 3.5. 
@Alexander - please discuss with me if you think that this is worthy backport to 3.4

Comment 5 Alexander Wels 2014-03-05 14:34:42 UTC

I will have to review the TCSM case again, but I know I specifically mentioned this would happen. I am pretty sure we even have a case testing that this exact thing happens. In other words this is doing exactly what we are expecting it to do. The reason for this is the following:

1. We collapse the system tree, and thus we store the width as 0 in the browser storage.
2. We specifically refresh the entire page and thus we lose the previous size information in memory of the browser.
3. Since the stored width is 0 and the original size is lost due to the refresh, we have to set the expanded size to the default size.


So all in all this is expected and designed behavior and thus not a bug.

Jiri I want to close this as a wontfix/worksasdesigned.

Comment 6 Einav Cohen 2014-04-08 18:36:21 UTC

after discussing with Alex: 
we will improve the behavior so that the last expanded panel width is persisted across sessions; 
note that expanded width = max(width of the panel, 100px [or another width that we will set as minimal expanded width])
due to a technical limitation, it is difficult to keep the expanded width before manual dragging, however the behavior will be reasonable.

Comment 7 Jiri Belka 2014-07-14 14:38:40 UTC

ok, ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch

tried both with FF and IE10.

Comment 8 Sandro Bonazzola 2014-10-17 12:22:22 UTC

oVirt 3.5 has been released and should include the fix for this issue.