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

Bug 365396

Summary:

IRunnableWithProgress does not correctly reset the focus

Product:

[RT] RAP

Reporter:

Steffen <steffen>

Component:

RWT

Assignee:

Project Inbox <rap-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

ivan, oliver, steffen

Version:

1.4

Target Milestone:

1.5 M4

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Source-Snippet (Example)	none
Patch that fixes the issue	none

Description Steffen

2011-12-02 03:16:07 EST

Hello,

Forum-Link:
http://www.eclipse.org/forums/index.php?t=rview&goto=760299#msg_760299

RAP-Version:
1.4SR1

Perequisites:
- use IRunnableWithProgress in an ApplicationWindow
- a progress will be executed by a SelectionListener of a "Text"-control

See my example to reproduce.

Description for my example:
Type in some text in the "Text"-control and press enter key. Now the progress will be started and will end after 2.5 seconds.

According to the java-source now the following should happen:

// It's necessary to restore focus after reenabling the controls
// because disabling them causes focus to jump elsewhere.
// Use forceFocus rather than setFocus to avoid SWT's
// search for children which can take focus, so focus
// ends up back on the actual control that previously had it.
currentFocus.forceFocus();

For Firefox and Internet Explorer i have found different behaviors after pressing enter key which will be described in the following:

Firefox 8.0:
The cursor is visible and it is possible to edit the text of the Text-control by keyboard.
If you try to use the mouse cursor to mark some text you can see that this is not possible. Only in the case that you explicit reset the focus by clicking elsewhere and then back to the text-control you are able to mark some text.
Next thing which is curious is the fact that you have to press enter key two times to start the progress a second time.

Internet Explorer 8 and 9:
The cursor is not visible but you are able to press enter one time to restart the progress again. However, editing text is NOT possible.

Remarks:
Safari and Opera seems to work as expected.

Comment 1 Steffen

2011-12-02 03:16:38 EST

Created attachment 207824 [details]
Source-Snippet (Example)

Comment 2 Ivan Furnadjiev

2011-12-08 08:51:32 EST

I can reproduce all your findings. Chrome is working as expected too.

Comment 3 Ivan Furnadjiev

2011-12-08 11:47:10 EST

After a short investigation I found the following:
1. Firefox first Enter down does not work issue -  this is related to the workaround in EventHandlerUtil.js#getEventPseudoTypes for not processing the first "keydown" in Firefox due to some Firefox bug in the past. First solution will be to remove this check if it is not necessary any more. Second (more as a workaround if first solution is not possible ) - move the code that sends widgetDefaultSelection in TextUtil.js from "_onKeyDown" to "_onKeyUp". Tim, what do you think?
2. Selection issue in Firefox is still under investigation.
3. IE focusing issue - when a focused text field (HTML input field) is disabled in IE the focus is transfered somewhere else. One possible solution will be to visualize the focus after the widget gets enabled again - in Widget.js#_applyEnabled add:
....
} else {
  this.removeState("disabled");
  if( this.getFocused() ) {
    this._visualizeFocus();
  }
}
...
But first, we have to check what is happening when a focused control is disabled in SWT.

Comment 4 Ivan Furnadjiev

2011-12-08 12:01:42 EST

I checked in SWT and the focused control loose the focus when it is disabled. In RAP the focused control didn't change. From the comment in the Control#setEnabled method it seems that this is a known issue in RAP. In SWT (Windows) Control#setEnabled there is some code related to fixing focus. Probably we should adopt this code in RAP too.

Comment 5 Ivan Furnadjiev

2011-12-09 03:09:34 EST

Created attachment 208138 [details]
Patch that fixes the issue

This patch adopt the focus handling code in Control#setEnabled from SWT and remove the focus from disabled focused widget on the client.

Comment 6 Ivan Furnadjiev

2011-12-09 03:10:52 EST

Applied patch to CVS HEAD. All described issues have been fixed with this patch.

Comment 7 Steffen

2011-12-13 10:32:37 EST

(In reply to comment #6)
> Applied patch to CVS HEAD. All described issues have been fixed with this
> patch.

I tried your patch with RAP-Version 1.4SR1 but i can still reproduce the described issues.

Comment 8 Ivan Furnadjiev

2011-12-13 11:06:40 EST

(In reply to comment #7)
> I tried your patch with RAP-Version 1.4SR1 but i can still reproduce the
> described issues.
Could you try it against CVS HEAD? When I have time I will test it against 1.4SR1.

Comment 9 Ivan Furnadjiev

2011-12-13 11:29:06 EST

BTW... as the patch changes the javascript file Widget.js, are you sure that you are using the patched file for your tests? Did you rebuild the client.js or you are running your tests with "debug" library variant?

Comment 10 Steffen

2011-12-14 03:07:03 EST

(In reply to comment #9)
> BTW... as the patch changes the javascript file Widget.js, are you sure that
> you are using the patched file for your tests? Did you rebuild the client.js or
> you are running your tests with "debug" library variant?

This could be my failure. I will try it again.

Comment 11 Steffen

2011-12-14 04:33:03 EST

Ok, now everything works as expected.