Community
Participate
Working Groups
Build Identifier: 4.2.0.v20120315-1300 We, the Jubula team, currently check the compatibility of testing 3.x applications / plugins with e4.2 + compatibility layer and noticed that we have problems accessing menus from the Workbench and toolbar: the items / framework do not fire the SWT.Show event anymore. To correctly synchronize with the application we make use of global filters via Display.addFilter() and SWT.Show events for menus when e.g. remote controlling those. We are using this event to check if items from the menu are shown (e.g. after a click on the menu), but for RCP workbench menus and toolbar items with sub menus these events do no longer get fired / propagated. This results in the problem of not being able to detect that the menu has been opened successfully, and hence cannot correctly test the workbench and toolbar item menus at all. Does the new 4.2 UI use other events or are we missing something here? Reproducible: Always
They are being eaten by the framework. MenuManager IMenuListeners are still fired, but most SWT.Show events are now consumed by org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRendererFilter PW
(In reply to comment #0) > Build Identifier: 4.2.0.v20120315-1300 > > This results in the problem of not being able to detect that the menu has been > opened successfully, and hence cannot correctly test the workbench and toolbar > item menus at all. > Is this part of your testing framework, or part of Jubula? What is it you're trying to do within the SWT.Show event? PW
Thank you for your response. As our testing framework is a part of Jubula: Yes, and Yes :) We are using the SWT.Show event to get notified as soon as the menu is opened (so that we are able to continue testing / clicking e.g. on a sub-menu entry). If the SWT.Show event does not occur our remote control is not able to properly synchronize with the AUTs (application under test) menu expansion state.
(In reply to comment #3) > We are using the SWT.Show event to get notified as soon as the menu is opened > (so that we are able to continue testing / clicking e.g. on a sub-menu entry). > If the SWT.Show event does not occur our remote control is not able to properly > synchronize with the AUTs (application under test) menu expansion state. We consume SWT.Show events as part of our Eclipse4 framework (the renderers are an implementation details). As it's a fundamental part of our renderer processing, I'll have to think if I can even address this. PW
Hi Marvin, What's the impact to Jubula if I address this for Juno SR1? I think I can modify our filter framework, but the risk at this point in the development cycle is phenomenal. PW
Hi Paul, The impact on Jubula is that we cannot test menus from the workbench and toolbar of RCP e4 applications. On the other hand it has no impact on other parts of Jubula, so we are okay with it if it is addressed for Juno SR1. MM
Started looking at a more localized IMenuListener on pwebster/bug375826 PW
Ok, I've pushed a prototype to pwebster/bug375826 It allows us to do Eclipse4 pre and post event processing within the MenuManager's response to those events themselves, moving it out of the filter. That way, the SWT Show and Hide events do not have to be filtered out. The filter is still there, it just does some simple pre-processing and then allows the events to proceed. PW
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=724d1d83a3b1790ae852bc1101bd7dff873a8896 Marvin, we should be able to test this after this week's M build. PW
Hey Paul, thanks for your work. I successfully tested this with the latest maintenance build M20120822-1200. So its working now! MM
*** Bug 391255 has been marked as a duplicate of this bug. ***
