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.
Created attachment 922259 [details] User modified columns
Created attachment 922260 [details] After reopening tab - part 1
Created attachment 922261 [details] After reopening tab - part 2
Workaround: 1. Open Developer Tools > Resources tab 2. Open Local Storage > http://localhost 3. Delete all keys Columns return to their default values.
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"
Created attachment 922335 [details] Another example with developer tools open, showing stored values
Created attachment 922336 [details] Example 2 - before reopen
Created attachment 922337 [details] Example 2 - after reopen
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)
Alexander - MODIFIED?
(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)?
We could backport it, I didn't due to the fact that the bug was targeted at 3.6
Can we proceed with backporting it to 3.5? Seems pretty straight forward and it blocks bug 1148440 and bug 1148424.
(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.
This has been backported.
This is an automated message: This bug should be fixed in oVirt 3.5.1 RC1, moving to QA
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.