Bugzilla – Full Text Bug Listing
| Summary: | [GTK] pure gdk implementation in Display.post(Event) does not work for menu items | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Seele <mseele> | ||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | akurtakov, ericwill, xixiyan | ||||
| Version: | 4.7 | Keywords: | triaged | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: | https://git.eclipse.org/r/132225 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Michael Seele
I can reproduce this on GTK3.22, 4.8 M6, and Fedora 27. Now it's even worse: Under SWT S-4.10M1-201810101800 there is no "TEST BUTTON CLICKED" and no "ITEM CLICKED" output. So no click works with the "new" OS.gdk_test_simulate_button. Is there anybody who looks into this? For us it's a real showstopper :( Xi, please investigate. New Gerrit change created: https://git.eclipse.org/r/132225 (In reply to Eclipse Genie from comment #4) > New Gerrit change created: https://git.eclipse.org/r/132225 After some investigation, I found that: 1) For GTK3.14 and below, using gdk_test_simulate_button the snippet will output only "TEST BUTTON CLICKED" as when the bug was first reported. After GTK3.16, there is no "TEST BUTTON CLICKED" output and no "ITEM CLICKED" output. So I did a git bisect and found that this GTK commit broke the receiving of clicked signal for simulated button events: https://gitlab.gnome.org/GNOME/gtk/commit/a4e0de183967d51f5ef7ec602f96ad6c33456701 It looks like for some reason, simulated button release invokes the cancel callback which does not emit a "clicked" signal, and hence the gtk_clicked method does not get invoked on the SWT side which means no SWT.Selection event are sent. 2) The same behaviour happens with a native GTK snippet, no callback is invoked on button "clicked" signal when using gdk_test_simulate_button to fake the mouse click. 3) Replacing the gdk_test_simulate_button with the XSendEvent API also does not emit the signals since gdk_test_simulate_button is implemented using XSendEvent on the GTK level. However, I noticed that these method does indeed "clicks" the button and menu since the button shows visually it is being clicked and the menu bar is opened, but since no signals are sent, it doesn't makes sense to use them. 4) By occasion, I noticed that using XSelectInput to request the X server to report ButtonPressedMask event (which was being used by the implementation of gdk_test_simulate_button) makes the "clicked" signal sent again for the Button widget. (i.e. we are back to the behaviour in GTK3.14..). See the patch attached. But this still does not fix the issue with menu items. Since gdk_test_* API are removed in GTK4, I think it maybe makes more sense to use the old XTestFakeButtonEvent to deal with this bug. (In reply to Xi Yan from comment #5) > (In reply to Eclipse Genie from comment #4) > > New Gerrit change created: https://git.eclipse.org/r/132225 > > After some investigation, I found that: > > 1) For GTK3.14 and below, using gdk_test_simulate_button the snippet will > output only "TEST BUTTON CLICKED" as when the bug was first reported. After > GTK3.16, there is no "TEST BUTTON CLICKED" output and no "ITEM CLICKED" > output. So I did a git bisect and found that this GTK commit broke the > receiving of clicked signal for simulated button events: > > https://gitlab.gnome.org/GNOME/gtk/commit/ > a4e0de183967d51f5ef7ec602f96ad6c33456701 > > It looks like for some reason, simulated button release invokes the cancel > callback which does not emit a "clicked" signal, and hence the gtk_clicked > method does not get invoked on the SWT side which means no SWT.Selection > event are sent. > > 2) The same behaviour happens with a native GTK snippet, no callback is > invoked on button "clicked" signal when using gdk_test_simulate_button to > fake the mouse click. > > 3) Replacing the gdk_test_simulate_button with the XSendEvent API also does > not emit the signals since gdk_test_simulate_button is implemented using > XSendEvent on the GTK level. However, I noticed that these method does > indeed "clicks" the button and menu since the button shows visually it is > being clicked and the menu bar is opened, but since no signals are sent, it > doesn't makes sense to use them. > > 4) By occasion, I noticed that using XSelectInput to request the X server to > report ButtonPressedMask event (which was being used by the implementation > of gdk_test_simulate_button) makes the "clicked" signal sent again for the > Button widget. (i.e. we are back to the behaviour in GTK3.14..). See the > patch attached. But this still does not fix the issue with menu items. > > Since gdk_test_* API are removed in GTK4, I think it maybe makes more sense > to use the old XTestFakeButtonEvent to deal with this bug. Using XTest is not an option on Wayland which is more and more the default. > Using XTest is not an option on Wayland which is more and more the default.
Why not supporting both, depending on the gtk version (or if wayland is used)?
(In reply to Michael Seele from comment #7) > > Using XTest is not an option on Wayland which is more and more the default. > > Why not supporting both, depending on the gtk version (or if wayland is > used)? I'm not sure this is feasible especially if someone runs eclipse under wayland via XWayland, in which case there will be X11 but with some of the wayland security constraints thus XTest might work or not (to be tested) but definetely not easy to handle as there is no way to detect running under XWayland AFAIK. XTest does not work on Wayland. In fact, I don't think Wayland supports simulating any key or mouse events due to security constraints. gdk_test_* methods are also implemented for X11 only. I'm not sure if we can generate any low level keyboard and mouse events on Wayland at all. *** This bug has been marked as a duplicate of bug 540809 *** |