Bug 1124546 - Resized columns in main tabs do not save their user configured size
Summary: Resized columns in main tabs do not save their user configured size
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-webadmin
Version: 3.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.5.1
Assignee: Alexander Wels
QA Contact: Pavel Stehlik
URL:
Whiteboard: ux
Depends On:
Blocks: 1148424 1148440
TreeView+ depends on / blocked
 
Reported: 2014-07-29 18:29 UTC by Nir Soffer
Modified: 2016-02-10 19:46 UTC (History)
8 users (show)

Fixed In Version: ovirt-3.5.1_rc1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-21 16:03:08 UTC
oVirt Team: UX


Attachments (Terms of Use)
User modified columns (113.71 KB, image/png)
2014-07-29 18:31 UTC, Nir Soffer
no flags Details
After reopening tab - part 1 (93.25 KB, image/png)
2014-07-29 18:32 UTC, Nir Soffer
no flags Details
After reopening tab - part 2 (79.64 KB, image/png)
2014-07-29 18:32 UTC, Nir Soffer
no flags Details
Another example with developer tools open, showing stored values (219.19 KB, image/png)
2014-07-29 20:21 UTC, Nir Soffer
no flags Details
Example 2 - before reopen (231.08 KB, image/png)
2014-07-29 20:30 UTC, Nir Soffer
no flags Details
Example 2 - after reopen (223.52 KB, image/png)
2014-07-29 20:30 UTC, Nir Soffer
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 32831 master MERGED userportal,webadmin: ensureColumnPresentFix Never
oVirt gerrit 34283 ovirt-engine-3.5 MERGED userportal,webadmin: ensureColumnPresentFix Never

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.


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