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
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]
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();
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
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
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
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
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]
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
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
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.