Bug 1124546

Summary: Resized columns in main tabs do not save their user configured size
Product: [Retired] oVirt Reporter: Nir Soffer <nsoffer>
Component: ovirt-engine-webadminAssignee: Alexander Wels <awels>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Stehlik <pstehlik>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.5CC: awels, derez, ecohen, gklein, iheim, mgoldboi, rbalakri, yeylon
Target Milestone: ---   
Target Release: 3.5.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: ux
Fixed In Version: ovirt-3.5.1_rc1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-21 16:03:08 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:
Bug Depends On:    
Bug Blocks: 1148424, 1148440    
Attachments:
Description Flags
User modified columns
none
After reopening tab - part 1
none
After reopening tab - part 2
none
Another example with developer tools open, showing stored values
none
Example 2 - before reopen
none
Example 2 - after reopen none

Description Nir Soffer 2014-07-29 18:29:58 UTC
Description of problem:

When a user change column size in a table, she expects the size to be persisted. When the same tab is reopened, the size set by the user should be used.

Version-Release number of selected component (if applicable):
oVirt Engine Version: 3.5.0-0.0.master.20140722232056.git8e1babc.fc19

How reproducible:
Always

Steps to Reproduce:
1. Open one of the main tabs
2. Modify the columns width
3. Open another tab
4. Open again the first tab

Actual results:
Columns size is much bigger then set before - see screenshots.
Table is hardly useable because it needs horizontal scrolling.

Expected results:
Modified columns width persisted

Tested on:
- Chrome Version 36.0.1985.125
- Fedora 19, updated in Jul 28.

Comment 1 Nir Soffer 2014-07-29 18:31:18 UTC
Created attachment 922259 [details]
User modified columns

Comment 2 Nir Soffer 2014-07-29 18:32:15 UTC
Created attachment 922260 [details]
After reopening tab - part 1

Comment 3 Nir Soffer 2014-07-29 18:32:45 UTC
Created attachment 922261 [details]
After reopening tab - part 2

Comment 4 Nir Soffer 2014-07-29 18:40:26 UTC
Workaround:

1. Open Developer Tools > Resources tab
2. Open Local Storage > http://localhost
3. Delete all keys

Columns return to their default values.

Comment 5 Nir Soffer 2014-07-29 20:20:33 UTC
After I removed all local storage keys and rebooted the machine, I can reproduce this in a little different way:

- Columns 0 and 1 were resized and have local stored values, but they use the default values instead
- Columns 1, 2, 3 were not resized, but use now huge width - maybe taken from values stored for other columns?

See attachment "stored-values.png"

Comment 6 Nir Soffer 2014-07-29 20:21:23 UTC
Created attachment 922335 [details]
Another example with developer tools open, showing stored values

Comment 7 Nir Soffer 2014-07-29 20:30:08 UTC
Created attachment 922336 [details]
Example 2 - before reopen

Comment 8 Nir Soffer 2014-07-29 20:30:39 UTC
Created attachment 922337 [details]
Example 2 - after reopen

Comment 9 Nir Soffer 2014-07-29 20:33:36 UTC
In "Example 2" attachments, we can see that although all columns values are stored in local storage, most columns use less then the stored values (e.g. 0, 1), and some columns use much more then the stored values (e.g. 2,3,4)

Comment 10 Einav Cohen 2014-09-16 14:08:00 UTC
Alexander - MODIFIED?

Comment 11 Einav Cohen 2014-09-16 14:09:27 UTC
(In reply to Einav Cohen from comment #10)
> Alexander - MODIFIED?

I see that the patch is rather small, maybe worth backporting to 3.5 (the BZ is currently targeted for 3.6)?

Comment 12 Alexander Wels 2014-09-16 14:11:22 UTC
We could backport it, I didn't due to the fact that the bug was targeted at 3.6

Comment 13 Daniel Erez 2014-10-20 15:43:35 UTC
Can we proceed with backporting it to 3.5? Seems pretty straight forward and it blocks bug 1148440 and bug 1148424.

Comment 14 Einav Cohen 2014-10-20 16:54:15 UTC
(In reply to Daniel Erez from comment #13)
> Can we proceed with backporting it to 3.5? Seems pretty straight forward and
> it blocks bug 1148440 and bug 1148424.

at it seems like this issue is heavily-reported, this patch is indeed 3.5-backport-worthy. 
changing status of the BZ accordingly. 
@Alexander - please backport. 

thanks.

Comment 15 Alexander Wels 2014-11-10 13:21:18 UTC
This has been backported.

Comment 16 Sandro Bonazzola 2015-01-15 14:15:13 UTC
This is an automated message: 
This bug should be fixed in oVirt 3.5.1 RC1, moving to QA

Comment 17 Sandro Bonazzola 2015-01-21 16:03:08 UTC
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.