Community
Participate
Working Groups
Build Identifier: 20100917-0705 When a CellEditor is active in a table on a MultiPageEditor page and a TreeViewer is used to switch pages using a selection listener the cell editor is not correctly deactivated and enters a broken state. The only two fixes I have found to reset the celleditor control is to activate the celleditor in another cell below/above it in the table or dispose of its parent control. Reproducible: Always Steps to Reproduce: Using the soon to be provided snippet... 1. Click the first item in the tree viewer (to make sure it is selected) 2. Click in the first cell in the table to activate the cell editor. 3. Click the second item in the tree viewer. This will switch to the second tab. 4. Click back on the first tree item or the first tab to get back to the table 5. The cell editor is broken. The only way to make the control disappear is to activate the cell in the table below it. You may notice the cursor for the text box is flashing and hovering above where it should be and not in the actual text box. Also happens with ComboViewerCellEditors and is more pronouced as the drop down list hovers in the top left cover of the screen
Created attachment 182844 [details] IEntryPoint to reproduce the issue
Forgot to add, happens in IE6 and IE8. Doesn't happen in Firefox. No other browsers tested.
I did some more testing with the attached snippet and I can reproduce it in IE only too. Tested with FF 3.6.12, Chrome 7, Opera 10.63 and Safari 5.02 on Windows 7.
There is a workaround available Wrapping the code in the selection listener in a Display.getCurrent().timerExec(int, Runnable) will make the cell editors behave normally. asyncExec is not enough to fix the problem. A timerExec with 1ms delay works
This bug is valid with IE9 too.
This is a client-side issue only. When you switch the folder tabs with activated (visible) cell editor control the following javascript is rendered: var w = wm.findWidgetById( "w9" );w.setVisibility( false ); -> this is the Table var w = wm.findWidgetById( "w14" );w.setVisibility( false ); -> this is the Text (cell editor) This shows that we set the visibility to false on the widget (Text), which parent is already invisible (Table). IE is well known to behave strange in such a cases - modify property on a div which parent is invisible.
I can't reproduce the issue anymore with the current CVS HEAD. Tested with IE9 and IE8. We fixed couple of similar issues in IE recently. Please reopen if the bug persists with CVS HEAD.
