MySQL Bugs: #69793: Dragging SQL Editor Tabs can cause strange behavior.

Bug #69793	Dragging SQL Editor Tabs can cause strange behavior.
Submitted:	19 Jul 2013 14:28	Modified:	10 Sep 2014 10:06
Reporter:	Franz Gans	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S3 (Non-critical)
Version:	6.0.3.11035	OS:	Windows
Assigned to:		CPU Architecture:	Any
Tags:	drag, editor, move, strange, workbench

Description:
When using the MySql Workbench I've encountered a bug that occurs after dragging the Query ("SQL File") tabs.
It happens with both the latest stable version and the new version 6 beta.

What I did was drag one of the tabs to the right, overtaking 2 other tabs in the process. The bug only occurs when dragging the tabs in a specific way. If you keep the mousse pointer within the boundaries auf the tab bar while dragging a tab, the bug doesn't occur.
However, if you click, drag and move the mouse to the top (where the toolbar is) or the bottom (where the SQL Editor text box is) and then move it overtaking 2 other tabs it does occur. What then happens is that the 2 tabs (let's call thenm "Tab A" and "Tab B") get somehow "switched". By that I mean if I execute a select query in Tab A, the result will display in Tab B and the Workbench will switch focus to Tab B. At the same time if I execute a select query in Tab B the results will display in Tab A and again the Workbench switches the focus to Tab A.

How to repeat:
1) Open MySQL Workbench and connect to a database
2) Select a schema if none ist selected
3) Open at least 3 query ("SQL File") tabs.
4) Put a different "select" queries in each tab.
5) Click and hold the left mouse button on the leftmost tab.
6) Leave the tab bar by moving to the top or the bottom.
7) Move the mouse below or above (depending on what you did earlier) the rightmost tab.
8) Move the mouse ont he rightmost tab and realease.
9) The bug occurs.

Thank you for the bug report. I can't repeat or I have not understanding your how to repeat steps, so are you able to provide a picture(s) for?. Thanks.

I've created a small Youtube video that demonstrates this bug:
http://www.youtube.com/watch?v=ixGcjjucaRM

Pay close attention to the mouse movement to reproduce the bug.
If the mouse cursor stays withing the confines of the tab bar while dragging, the bug doesn't occur.

Please try version 6.0.5. Thanks.

I've tested it with version 6.0.5. Unfourtunality the bug still remains.
If my youtube video was a bad way of showing it or I didn't explain it very well then please let me know, I'll try to do it better.

Please try version 6.0.7. Thanks.

Tested it and the bug still occurs.

I have personally just stumbled over this somewhat obscure bug on 6.0.7 on GNU/Linux.  I can also offer some better reproduction instructions that illustrate the problem:

---

1) Open Workbench and connect to a database (I'm using a local connection)

2) In the first SQL tab type/paste the following query:

SELECT 'Tab 1', RAND() FROM DUAL;

3) Open a new SQL tab (EG: using 'Ctrl + t' keyboard shortcut).  In that second tab, type/paste the following query:

SELECT 'Tab 2', RAND() FROM DUAL;

4) Switch to the first tab (with the 'Tab 1' query) and execute it, such as by pressing 'Ctrl + Enter'.  Make a note of the random number that appears (it will have erroneously changed later on).

5) Switch to the second tab (the 'Tab 2' query) and execute it in the same way.

Results panes for both queries will be open, indicating tab 1 and tab 2, with a random number on each as well.  You will also see in the 'Action Output' pane below that the desired queries have been executed.

6) Now (with 'Tab 2' selected) drag-drop the tab handle for SQL 'Tab 2' so that its position in the tab list is swapped with 'Tab 1'.

7) Without further switching between tabs, re-execute that query ('Ctrl Enter' for example).

The result pane showing 'Tab 2' and the random number does not update (you can see this because the random number does not change) and the 'Action Output' pane shows that the SQL that was executed was actually the 'Tab 1' query, and not the 'Tab 2' query that you are looking at.  You can further demonstrate that the wrong query was executed by now switching back to 'Tab 1' and checking the random number against the one written down earlier.  It will have changed (regenerated) when the wrong query was executed.

---

There is also a workaround for this:

After dragging SQL tabs and re-ordering them, switch tabs a few times without further drag/drop reordering (including between the ones which were displaced by the original reordering).

This should be fixed by now, if not in 6.1 then in 6.2.

I tested this in 6.2.2 and I can confirm it has been fixed.

Fixed