MySQL Bugs: #72332: MySQL Workbench resultsets columns autofit miserably broken

Bug #72332	MySQL Workbench resultsets columns autofit miserably broken
Submitted:	13 Apr 2014 19:03	Modified:	30 Sep 2014 7:15
Reporter:	Teodor Hadjiev	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S2 (Serious)
Version:	6.1.4	OS:	Windows (Windows 7 x64)
Assigned to:		CPU Architecture:	Any
Tags:	autofit, columns, ResultSet, width

Description:
Just upgraded from 6.0.8 to the latest 6.1.4 to find out that the resultset columns widths in SQL editor no longer autofit when executing a query.
The resultset is displayed in a small table where nothing could be read without spending valuable seconds EVERY time a query is run, to resize all the columns widths.
This tremendously breaks productivity and usability to the point of dropping WB usage at all, or downgrading to the old version.
I see an old thread from 2012 when this was in a stage of Feature Request, and it was perfectly working so far.
Please please fix this, I don't want to downgrade just because of this.

How to repeat:
Open a SQL editor to a server and execute a query that returns some text fields, the columns don't autofit to a reasonable width to display as much as they can (or set in the Preferences as I believe 256 bytes..). Instead they are displayed in a super narrow table taking 1/20 of the screen width.

Suggested fix:
Restore the autofit like it was in 6.0.8 and before it (not sure about 6.0.9, I skipped it).

Just downgraded to the good ol' 6.0.8 and it works like a charm.
From now on I'll test very extensively the new versions in a virtual environment before taking the plunge to upgrade.
The filesize of 6.0.9 is about 2MB smaller than 6.0.8 and the filesize for 6.1.4 is very close to that of 6.0.9 (2MB smaller than 6.0.8) so I suspect 6.0.9 would have the same bug so I restored the perfectly working 6.0.8 for now.

Thank you for the bug report.

This is still in 6.1.4.

Like Teodor, I am about to uninstall and go back to the version I had before that worked.

This version cuts too much into my productivity. I find myself running fewer queries because I don't want to spend the time expanding the results so that I can read them.

Kindly let me know when this is fixed, and I will upgrade to that version.

Seriously? 6.1.6 and this is still happening.
Given the fact a new version comes out once in a while, I find this unacceptable. This should be very easy to fix since it was working in so many versions so far.
I can 'accept' many other bugs, and I do it (there are many), but they are not hindering productivity by such collosal margin.
I'm going to pay for (another) software that just works. Still hoping this will be fixed and never broken again, to at least restore working state. Thanks.

I confirm the issue in 6.1.6 (it was present since 6.1.x) and that it's quite annoying, because it was one of the very useful features. It's irritating that such functionalities silently disappear with upgrades to minor version (i.e. the feature existed and worked very well in 6.0.x).

It didn't just disappear, it is a bug because you still have the corresponding option in Settings.
It is critical for me and I'll stick to 6.0.8 until and if this gets ever fixed.
I find myself already using other software for almost everything except for some backup/restore/user_management/permissions functions.
What a disappointment. Also mysql forks and derivatives emerge and they seem better, I just wait for a less buggy new *sql management tool.

This should be treated with highest priority. I am on OS X using 6.1.7.11891 build 1788.

If you are dog fooding this product, I cannot imagine how you can put up with this. It's kills the UX completely. I was spending half my time resizing columns, and instantly dropped the product.

It's the kind of bug that makes you want to grab the person who introduced this bug and have him use the broken UI for a week so he can realise how frustrating this is.

Hi every body.
Need some help please.
Due to this issue I want to down grade as well
However, I afraid to lose my work.

Can any one tell me or redirect me to the knowledge regarding this?
thank u all
Uriya

This is still present in 6.1.7.11891 build 1788. Come on Oracle! Fix this already!

Autofit seems to be ignoring the setting in:
  Workbench Preferences -> SQL Queries -> Query Results -> Max. Field Value Length to Display (in bytes)

NOTE: This is NOT only the case for query results, but also when entering/modifying data.  Columns used to autofit after each column of data was entered; now it does not.

Between this bug (Bug #72332) and
2) that NULLS are returned for filtered non-matching rows (Bug #72214), and
3) Filter Rows no longer works on partial matches (Bug #73465),

I am uninstalling the new version and reinstalling 6.0.6

Workaround I am using for autofit:
When I want to autofit the result grid, I add a bogus change (e.g. type a character somewhere into the last/empty row), and then click Apply, Cancel, Cancel.  (The second cancel removes the bogus change).

This triggers autofit for the result grid.

Posted by developer:
 
fix confirmed in 6.2.1. Aside from trying to optimize column-width on new query-resultgrids, Workbench now stores column sizes for queries and restores them whenever a query is executed.

Fixed as of the MySQL Workbench 6.2.0 release, and here's the changelog entry:

Column widths in the results view window would sometimes not fit, thus
requiring the columns to be resized manually. 

In addition to the autofit function being fixed, adjusted column widths 
are now preserved.

Thank you for the bug report.

User preserved - very good, but should be as option to on or off it, or reset it, at least. Why autofit can't work as it was in 6.0.9? I think, bug not closed yet.

Yes, I concur. Not to be closed yet.
Remembering of column widths should be optional. Why showing 600px column when the longest text takes only 50px for example. Or when I run one query that enlarges some column extraordinarily off the screen, then 99% of my next queries don't require more than 200px for example.
The up-to-6.0.8 behavior was perfect and concise.
Just make the second change optional please.

Just to add my vote for Teodor's request. The fixed sizing of columns doesn't make much sense (just tried it in 6.2.1) and should be optional, disabled by default if I may complement the request.

Tried the new 6.2.7.
Somewhat fixed but still not quite right. Still there are cases when column contents is cut off even though the contents is far shorter than the maximum length specified in settings. Then I resize the offending column and it gets fixed for subsequent queries even if the contents is larger and won't fit - very annoying altogether.
I guess I'll stick with 6.0.8 for quite a while just because of this sensitive bug.