Community
Participate
Working Groups
Last tested on RAP 2.0.0 M3 Browser used: Mozilla or IE - doesn't matter It's only a RWT issue - SWT-Win32 works fine 1. I'm inside a Text control and press the TAB-Key to move to the next control. 2. *Two* focus-lost events occur while traversing the focus: One from the Text control and one from the next control in order (e.g. another Text or a Button, it doesn't matter). 3a. If this next control is e.g. a Button and press TAB again, another focus-lost occurs. 3b. If this next control is a Text too, no focus-lost event occurs at all when leaving it. So the first error is that Text controls seem to fire not only their own focus-lost, but also a second focus-lost for the following control. And the second error is that in case of tabbing inside multiple Text controls the second focus-lost consumes the next focus-lost event from the following Text control. The same behaviour occurs when I use the mouse to change focus. So it doesn't matter if I press (Shift-)TAB or click inside the next control.
I can't reproduce it with Controls Demo -> Focus tab (tested with Firefox and Chrome on Windows 7). Could you try the Controls Demo too? Please provide a self-running snippet to reproduce the issue.
I now found the reason why this behaviour occurs in my program: During the processing of the focus-lost event I blocked the UI via shell.setEnabled(false) to prevent further input while the entered text is processed. On both SWT and RWT the implication is that the active Text control loses the focus while the shell is disabled and gets it back afterwards. But then RAP behaves differently because tabbing out of that Text control afterwards doesn't fire a new focus-lost - in SWT it does, which is the expected behaviour. My shell disabling might not be a good solution and not even neccessary while using in RAP mode, but I think that this behaviour can be considered a bug in RAP focus control.
(In reply to comment #2) > My shell disabling might not be a good solution and not even neccessary > while using in RAP mode, but I think that this behaviour can be considered a > bug in RAP focus control. If you attach a simple snippet to reproduce the issue we will consider how to handle it. Without a snippet I can't do anything.
Created attachment 223814 [details] Snippet to reproduce the temp-focus-lost behaviour This code tries to emulate the dual threading which we have in our mvc framework - the data processing is not done in the UI-Thread. Enter text in t1 and tab to t2. You can see in the Console-Output that the disabling of the shell during processing leads to an additional focus-lost and -gained in t2. In RAP this leads to a missing focus-lost if you tab back to t1.
Comment on attachment 223814 [details] Snippet to reproduce the temp-focus-lost behaviour Additional Comment: The problem is that it is difficult to reproduce our environment in a small code snippet. On SWT we use dual threading (so this is why I start the new Thread in the snippet. But if in RAP mode we don't use a new thread, so the code you see inside the "big" runnable instance would be called synchronously inside the focusLost. The ayncExecs are also executed directly then. I understand that it's hard for you to comprehend and reconstruct, but I can't boil down our complex setup to a small snippet. If you don't get an idea now what could be different in RAP, please feel free to close this bug as not reproducable. I think we will find a workaround here in this case, because as I already mentioned I don't feel lucky with this shell disabling.
I've tried to reproduce the issue today with RAP 2.0, but without luck. I will close it as WORKSFORME. Please reopen if you have more details about it.
