The tab is opened by process(), so you definitely won't see the tab containing ConnectPanel shows up if you put sleep(5000) in front of process().  If you put sleep(5000) after process(), then you will get what you were looking for.

Another way to verify a thread did get created is to set a breakpoint at the line after the process(), i.e. the line containing EventQueue.invokeLater(new Runnable()...), then create a database/table from the schema tree, when that breakpoint is hit, in Intellij/Debug/Threads tab, you will see the name of the active thread is SchemaDatabaseNew/SchemaTableNew.

In my environment, Eclipse/Windows, if I set a breakpoint at the line after process() and when that breakpoint is reached, I usually can see the tab containing a ConnectPanel is displayed but this never happened on Intellij/Ubuntu.  The tab is opened by CommonSchemaTab.openDialog(Runnable, JComponent) (line# 1121); in my environment, if I set two breakpoints, one at the line after BackgroundThread.process(), one at the very first statement in CommonSchemaTab.openDialog(Runnable, JComponent), then after 'Create Database' is selected from the schema tree, Eclipse shows there are two threads have hit breakpoint and stopped, one in EDT, one in SchemaDatabaseNew, I can choose any one of these two to continue.  On Intellij/Ubuntu, if I do this, i.e. setting 2 breakpoints, the control is stopped at the line after BackgorundThread.process(), but the one in CommonSchemaTab.openDialog() is never reached until the breakpoint in BackgroundThread is cleared. This behavior probably explain why you never see the tab containing the ConnectPanel is displayed in this particular case.

It seems that timing could be a factor here and requests queued in Swing EDT all get processed together. Made change to work around this problem.  SVN r28901.  After r28901 is applied, the following is expected after opening a visual editor:

(1) A tab is opened with a Connect panel displayed, the content of the Connect panel would be:
     Animated-Icon  [Cancel-Button]  Preparing...
When this is seen, it indicates the background thread is still running and performs some DB operations.

(2) Once background thread is done with DB operations, the content of the Connect panel will be replaced with the following:
     Initializing, please wait...
When this is seen, it indicates the Swing EDT has become the active thread and is constructing dialog.

(3) Dialog is displayed inside the tab once constructed. Note that constructing a dialog might take time because some dialogs have DB operations mixed with dialog's init method.

The workaround made by r28901 tries to get (1) and/or (2) be always seen. In most cases, you probably will only see (2) but not (1).  If it takes a while for background thread to complete its DB operations in (1), then you likely will see both (1) and (2).

However, since there is a timing issue involved; sometimes, you will see (1) and then found the Cancel button won't respond; when this happens, it is likely because Swing EDT has become the active thread and is processing (2) and (3) together.  I am sure this undesired behavior can be removed with more code change, if we have time.

I made some additional change, SVN r28914, in all of table related threads so that the table dialog object is created in the non-Swing thread, and Swing EDT is only used to add the table dialog object to the panel view.  I did some test on create/view/edit table with this change, it seems that there is no side-effect.

This approach will provide a much better user experience on opening visual editor as well as canceling a visual editor while the status panel is displayed. In the old approach, if dialog object takes time to construct, then user might experience some undesired behavior; for examples, in the item (3) above, once Swing EDT takes over control, user cannot do anything; while status message is displayed, user might want to cancel the request by clicking the x icon, it won't work; clicking the displayed message might end up pops up a message dialog, etc.

Please test table visual editor in all areas to make sure it behave correctly, especially the UI behavior on Linux. If r28914 works, we can modify other editors accordingly (if needed).

The original issue was only perceived as a problem for the same reason as issue #7217 was.  It seems that on Linux the JVM has a performance problem when .validate()/repaint().  Since this is in the EDT it pauses the application for a few seconds.