Community
Participate
Working Groups
All calls to clickContextMenu when running tests with a e4 platform conclude to a WidgetNotFound.
Some possible reasons: * The SWT events triggered by SWTBot aren't enough to get menu populated => Need to investigate if some additional SWT events are necessary * Populating a menu has become asynchronous and SWTBot should add "wait" conditions on Menu after sending the first event.
Suppose I want to click contextMenu on Expressions View with swtbot2.2.1 or 2.2.2 on e4. After stepping into the code for 'contextMenu', I observed that: ExpressionView class in eclipse has a method 'fillContextMenu'. There it gets 'find' actionitem as null. After exploring little more, I found that 'AbstractDebugView' class gets called for putting actionID for 'find' action for FoucusGained event. Again it gets called for FocusLost event and the 'find' actionID is removed from ExpressionView's fActionMap. After this sequence, 'fillContextMenu' is called where it doesn't get 'find' actionID because it's just has been removed.. The complete stack trace is as follows: Caused by: org.eclipse.core.runtime.AssertionFailedException: null argument:Action must not be null at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85) at org.eclipse.jface.action.ContributionManager.add(ContributionManager.java:76) at org.eclipse.debug.internal.ui.views.expression.ExpressionView.fillContextMenu(ExpressionView.java:89) at org.eclipse.debug.ui.AbstractDebugView$2.menuAboutToShow(AbstractDebugView.java:556) at org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:352) at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:492) at org.eclipse.jface.action.MenuManager.access$1(MenuManager.java:487) at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:519) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:255) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1070) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:782) at org.eclipse.swtbot.swt.finder.finders.MenuFinder.findMenusInternal(MenuFinder.java:152) at org.eclipse.swtbot.swt.finder.finders.MenuFinder.access$0(MenuFinder.java:149) at org.eclipse.swtbot.swt.finder.finders.MenuFinder$2.run(MenuFinder.java:124) at org.eclipse.swtbot.swt.finder.finders.MenuFinder$2.run(MenuFinder.java:1) at org.eclipse.swtbot.swt.finder.finders.UIThreadRunnable$2.doRun(UIThreadRunnable.java:140) at org.eclipse.swtbot.swt.finder.finders.UIThreadRunnable$1.run(UIThreadRunnable.java:89) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) ... 25 more JUnit fails with : org.eclipse.swtbot.swt.finder.widgets.TimeoutException: Timeout after: 5000 ms.: Could not find context menu with text: Disable at org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:412) at org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:386) at org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:374) at org.eclipse.swtbot.swt.finder.widgets.AbstractSWTBot.contextMenu(AbstractSWTBot.java:444) at org.eclipse.swtbot.swt.finder.widgets.SWTBotTreeItem.contextMenu(SWTBotTreeItem.java:559)
It seems I found how to make it work! Actually the problem was caused due to not finding entry in fActionMap (in VariablesView.fillContextMenu()) upon FocusLost event, which gets called as a result of SWTBotTreeItem.notifySelect(). If I comment out the line which sends SWT.FocusOut event in SWTBotTreeItem.notifySelect() method, then context menu click happens without any problem. UI also gets updated, as expected. After commenting out this line, FocusLost routine of VariablesView in eclipse is not called and hence the globalActions (e.g. 'find' action) is not removed. Therefore, fActionMap gets entry for 'find' action in fillContextMenu() method of VariablesView and the further code also executes well. Is this solution okay? Will it have any side-effects? I've one more question-- If I compare implementation of notifySelect() method of SWTBotTableItem and SWTBotTreeItem, I see that- SWTBotTableItem sends only SWT.Selection and SWTBotTreeItem sends a series of SWT events like MouseEnter, MouseMove, Activate, FocusIn and so on. Are all these events required? If I comment-out all events and keep only SWT.Selection in SWTBotTreeItem.notifySelect(), then also context menu click happens okay. Is SWT.Selection alone not sufficient?
(In reply to Aparna Argade from comment #3) > It seems I found how to make it work! > Actually the problem was caused due to not finding entry in fActionMap (in > VariablesView.fillContextMenu()) upon FocusLost event, which gets called as > a result of SWTBotTreeItem.notifySelect(). > If I comment out the line which sends SWT.FocusOut event in > SWTBotTreeItem.notifySelect() method, then context menu click happens > without any problem. UI also gets updated, as expected. > After commenting out this line, FocusLost routine of VariablesView in > eclipse is not called and hence the globalActions (e.g. 'find' action) is > not removed. Therefore, fActionMap gets entry for 'find' action in > fillContextMenu() method of VariablesView and the further code also executes > well. > Is this solution okay? Will it have any side-effects? It sounds good enough (at least much better than current status). Would be cool if you could make a Gerrit patch with it. As long as it doesn't break existing tests, it should be fine to merge it. > I've one more question-- > If I compare implementation of notifySelect() method of SWTBotTableItem and > SWTBotTreeItem, I see that- > SWTBotTableItem sends only SWT.Selection and SWTBotTreeItem sends a series > of SWT events like MouseEnter, MouseMove, Activate, FocusIn and so on. > Are all these events required? To e honest, I don't know... > If I comment-out all events and keep only SWT.Selection in > SWTBotTreeItem.notifySelect(), then also context menu click happens okay. > Is SWT.Selection alone not sufficient? Goal of SWTBot is to mimic as close as possible the sequences of event provided by regular usage of IDE. That's probably why SWTBot sends more events. A general good approach would be to check which events are actually triggered when manually using contextMenu and fix the list of events triggered by SWTBot according to the list of real events.
Gerrit review at https://git.eclipse.org/r/36732
This issue relates to some other bugs and it's tricky to find out which part of those bugs it fixes. @Aparna Do you think you could contribute a test case that reproduces this issue, and highlight the kind of issue your patches fixes?
Please review at https://git.eclipse.org/r/#/c/36878/ which Hudson CI has verified Okay. I'll surely try to contribute a swtbot test for this.
@Aparna: With Gerrit, we don't push a sequence of commits for single functional change (unless we do it in an incremental way). We always work with a single review, which contains a single commit (mapping between review and commit is done thanks to Change-Id). Then when you have some things to improve, you amend your commit to include the change you want to make and you push it again. If Change-Id is already known by Gerrit, it will update the existing review instead of creating a new one. Can you please perform your fixes on https://git.eclipse.org/r/#/c/36732/ instead of creating other reviews?
Patch was merged. This should fix the Bug. Thanks Aparna.
