This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Try to run attached test case. It seems like popup menu is invoked, but jemmy cann't find it (menu is visible - but on wrong place). I have filed issues against popup menu in the IDE ( issue 28360, issue 28561), but it should has no impact on looking for menu by jemmy.
Created attachment 7883 [details] test case
It seems like a problem in jemmy. If you run test case attached by Marian, it doesn't work (method JPopupMenuOperator.callPopup(Component, int, int, int ,int) is the place where it cannot find popup). If you use JPopupMenuOperator popup = new JPopupMenuOperator(); instead of testNode.performPopupAction("Add|Separator"); and you invoke popup by hand, it works. In this case a different code is used for waiting in JPopupMenuOperator (constructor JPopupMenuOperator(Operator env)). So, what is wrong in callPopup()?
Problem showed by attached testcase is not related to 28360 and 28561 issues. Behavior described in those issues is related to opening popup with "wrong" coordinates passed to JPopupMenu.show(Component, int, int) method. Let me show what's going on during attached testcase execution. First, tree component which is used to keep tree data is not visible - it's created in memory and then rendered into first table column. This component is used as a target for event dispatching during action reproducing. It's working for mouse clicks because, normally (say during manual using), any mouse event which appears on first table column is passed to this component for processing. Thus, passing our event to the component works. However, as I said, component is not really visible. So, approach does not work very well for the actions where its visibility matters. For example, it does not work well for popup opening, because java needs to know absolute coordinates to show popup. It is not possible, so popup is opened in wrong location. Popup visibility is also necessary for popup finding, because JPopupOperator.callPopup(*) methods wait for a popup having "invoker" property being either super- or sub-component of a component on which popup was invoked. So, actually, there are two problems: first how to display popup in right position (i.e. how to dispatch events to the right component, which is TreeTable), second is how to find popup. Simpliest solution would be to change Action so that it would not use JPopupOperator.callPopup(*), but ComponentOperator.clickForPopup(*) and JPopupMenuOperator constructor. This is not very good, because we would lost one stabilization point: test could find wrong popup - the previous popup which has not been collapsed yet due to delay in new popup showing events processing. Besides that, popup would not be showing in the right place. I have full solution - I already implemented and tested it (TreeTableOperator is attached). It looks very complicated, however it is most accurate solution I can come up with. 1. Create new operator class - subclass of JTreeOperator (RenderedTreeOperator in attach). This operator supposed to be used for that invisible tree component. 2. Declare new MouseDriver for RenderedTreeOperator (RenderedMouseDriver). This driver simply redirects all mouse events to "real" component - to TreeTable. It allows popup to be expended in the right place. It also guarantees that we will not meet any more problems with tree invisibility. 3. Override callPopupOnPaths(TreePath[], int) in RenderedTreeOperator so popup will be invoked on TreeTable component. It allows to find popup without losing a stability point. I agree that this sounds very complicated, so let me know if you have better approach. Otherwise, if noone objects, I'll integrate solution I implemented.
Created attachment 7916 [details] Modified TreeTableOperator
Will this work for jellytools.nodes.Node? A Node only knows about JTree and tree path. Currently it is not possible to open popup menu by mouse click on a node in TreeTable. I reopened issue 28561, which fix caused this behaviour. I think better fix of 28561 should solve problems in jelly but I am not sure.
Yes, it will work. That's exactly the point - to create JTreeOperator subclass which would work correct way even though this particular tree is not visible. By registrating new MouseDriver and overriding callPopupOnPaths we allow to treat this tree exactly like any other tree. Events will be readirected on the low-level, popup will be searched for TreeTable - no difference from interface point of view. I do not know what wrong 28561 fix did. Why do you think this two problems are connected? I can just say that even 3.4 behaves as described - popup is opened in wrong location and it can not be found. With proposed fix it works.
I have spoken with responsible developer about 28561 and he wants to fix TreeTable to work even in automated tests. I don't know if it is doable, or if only your new TreeTableOperator can solve this. If we use your code, we will probably save his time. I have no objections against integrating your TreeTableOperator.
Fixed as described.
verified