| Summary: | Button click does not work in cascaded scrolled composite when the outer composite jumps on focus out. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Lucas Koehler <lkoehler> | ||||
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eneufeld | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 3.5 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: |
https://git.eclipse.org/r/115277 https://git.eclipse.org/c/rap/org.eclipse.rap.git/commit/?id=128a41f563efa5d93fb877186117fbd1097bd573 |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
I can reproduce it with the attached example. Investigation of the problem is pending... The issue is the following - the button "Selection" event is send by the client on mouseUp event. In our example, on mouseDown event the ScrolledComposite scrolls to show the focus control and the button is moved. As a result the mouseUp event is no longer on the Button and "Selection" event is not send to the server. The same event order is in SWT - mouseDown, mouseUp, Selection. What is the expected bahaviour? ScrollComposite to not scroll? Because from my point of view the missing Selection event is expected as mouseUp event is not on the Button. Try in SWT to do on a Button: 1: mouse down without release 2. move the mouse outside the Button 3. mouse up.... Selection event is not fired in SWT too. The expected behavior would be, that the event is fired on the button when I click on it. SWT and RAP have different behavior here, as SWT doesn't scroll on click as the click is already in a visible area. So in SWT the mouseUp is triggered on the button. RAP scrolls first (which is weird by itself) and thus doesn't fire the expected event. I'm currently looking into the scrolling code in order to fix it if possible. New Gerrit change created: https://git.eclipse.org/r/115277 Gerrit change https://git.eclipse.org/r/115277 was merged to [master]. Commit: http://git.eclipse.org/c/rap/org.eclipse.rap.git/commit/?id=128a41f563efa5d93fb877186117fbd1097bd573 |
Created attachment 271863 [details] Sample application and scroll bar screenshot When two scrolled composites are cascaded this might lead to buttons not working when the composites scroll on focus out. Thereby, the click of the button is not registered. It seems like the scrolled composite captures the event: When we set setShowFocusedControl(false) of the scrolled composite (indirectly) containing the button, the problem does not occur. To reproduce the issue I created a small demo application that produces the problem when executing the following steps. I reproduced the problem in Chrome as well as Firefox. The used RAP version was 3.3. 1. Import the bundles from the attached archive into your workspace and set the target makeithappen_RAP.target located in the project org.eclipse.emf.ecp.makeithappen.application.sample.rap 2. Execute the application by running the MakeItHappen Sample RAP Application.launch in the same project (For this RAP Tools need to be installed in the IDE) 3. Do not run the browser in a maximized window. 4. Right click on User Group and then User in the tree on the left of the sample application and select the newly created element in the tree. 5. In the detail view of the tree, create a new object in the Tasks table by clicking the plus button and select the created table entry. 6. Scroll completely to the bottom. You should see a table named Sub Tasks. Also, there should be two scroll bars on the right. 7. Click the outer of the two scroll bars and manually scroll up a bit. (See the screenshot in the attached zip for the position of the scroll bars before clicking the button) 8. Click the plus button of the Sub Tasks table. Normally this would create an entry in the table. But now, no entry is created and the outer scroll bar jumps back to the bottom. 9. Optional: You can click the plus button again. Now an entry should be created in the table and no “jumping” occurs.