Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 328864

Summary:

textcelleditor text control lost focus after setfocus on cocoa when text is empty

Product:

[Eclipse Project] Platform

Reporter:

Andrew Bachmann <AndrewBachmann>

Component:

SWT

Assignee:

Scott Kovatch <skovatch>

Status:

RESOLVED FIXED

QA Contact:

Silenio Quarti <Silenio_Quarti>

Severity:

normal

Priority:

CC:

Alfredo.Bencomo, arash.aghevli, ivy.deliz, skovatch, tom.schindl

Version:

3.6

Target Milestone:

3.7 M4

Hardware:

Macintosh

OS:

Mac OS X

Whiteboard:

Attachments:

Description	Flags
N/A	none
Screencast reproducing it	none
Fix	none

Description Andrew Bachmann

2010-10-27 13:27:49 EDT

Build Identifier: I20100921-1024

Problem exhibited in Eclipse 3.6 and 3.6.1, only under Cocoa builds (32 and 64 bit).

I tried overriding the TextCellEditor to change doSetFocus to not call setFocus and in this case, the text control appears as normal and does not defocus/dismiss. Of course there is no cursor in the text control. However, I do note that if "tab" is hit at this point, focus will go to the text control and it does not defocus/dismiss.

I also tried a variety of other tactics including modifying the enablement of the control, using other select mechanisms instead of setFocus/selectAll. I also tried doing the setFocus in an async display runnable, and other actions in the runnable. I also tried changing the text content to temporarily not be empty in doSetFocus. (and change it back immediately after setFocus, or later in async runnable)

Only one thing worked to behave "somewhat correctly":

in doSetFocus, avoid calling setFocus. instead, create a timed display runnable to call setFocus later. if (later <= 550 milliseconds) this doesn't work. if (later >= 700 milliseconds) it seems to work reliably. if (later == 600 milliseconds) it works sometimes.

Is this perhaps related to Bug 313208

Reproducible: Always

Steps to Reproduce:
1. On a Tree, use a TextCellEditor for editing the cell
2. Click on the cell to activate the editor for a cell which has an empty string as value
3. The text control appears and has normal behavior
4. Deselect the editor by clicking in the empty part of the Tree
5. Click on the same cell again
6. The text control appears and the cursor flashes
7. After about 50 milliseconds the text loses focus and disappears

Comment 1 Andrew Bachmann

2010-10-27 13:59:04 EDT

Since the time involved was close to Display.getToolTipTime() I also tried using reflection to make the Display.hoverTimer a no-op.  This didn't help.

Comment 2 Andrew Bachmann

2010-10-27 14:06:52 EDT

Another thing I tried was to issue SWT.TRAVERSE_TAB_NEXT programatically, first instead of the setFocus, and then also in a later async display runnable.  This had the same behavior as setFocus. (I saw the cursor, and then the Text disappears, defocuses)

Comment 3 Al B

2010-10-27 17:02:03 EDT

Created attachment 181884 [details]
N/A

The attached screencast reproduces this problem; which only manifests on cocoa.

Note: No, I am not pressing escape/return, it leaves the focus automatically.

Comment 4 Al B

2010-10-27 17:23:52 EDT

Created attachment 181887 [details]
Screencast reproducing it

Comment 5 Arash Aghevli

2010-10-28 13:32:52 EDT

I also saw this problem with CCombo when using org.eclipse.emf.common.ui.celleditor.ExtendedComboBoxCellEditor

After focus, the combo loses focus.  The workaround of waiting in a timedExec seems to work somewhat.

Comment 6 Scott Kovatch

2010-10-29 17:36:06 EDT

(In reply to comment #0)
> 
> in doSetFocus, avoid calling setFocus.  instead, create a timed display
> runnable to call setFocus later.  if (later <= 550 milliseconds) this doesn't
> work.  if (later >= 700 milliseconds) it seems to work reliably.  if (later ==
> 600 milliseconds) it works sometimes.
> 
> Is this perhaps related to Bug 313208

313208 deals with how we send MouseDoubleClick events. I still see this in 3.7, so that's not related.

Comment 7 Scott Kovatch

2010-10-29 18:10:19 EDT

Here's what I'm seeing:

-- Click happens on the Tree.
-- MouseDown is fired, so ColumnViewer activates and sets focus on the TextCellEditor.
-- NSTableView determines that the cell is editable, so it tries to put up its own NSTextField for editing purposes. To do that, it first resets the first responder back to the NSTableView.
-- When the first responder goes back to the NSTableView it removes it from the TextCellEditor
-->> TextCellEditor is deactivated/hidden.

It's not clear to me why it only happens when there's no text, but it looks like the solution is to implement tableView:shouldEditTableColumn:row to return false so Cocoa's default table editing doesn't occur.

Comment 8 Scott Kovatch

2010-10-29 18:27:35 EDT

Interestingly enough we already do this for Table but forgot to do it for Tree. The method to implement is outlineView:shouldEditTableColumn:item:

Comment 9 Scott Kovatch

2010-10-29 18:33:22 EDT

Created attachment 182088 [details]
Fix

Added override as described, and cleaned up the unnecessary overrides in Table and List; we never want Cocoa's cell editing behavior to occur.

Waiting for 3.7 M3 declare, then I'll check it in.

Comment 10 Scott Kovatch

2010-11-01 11:47:11 EDT

Fixed > 20101101.