Apache OpenOffice (AOO) Bugzilla – Issue 68585
ContextMenu doesnt always close under Solaris.
Last modified: 2017-05-20 11:11:38 UTC
Unfortunately, while the bug in i67013 was fixed, the fix seems to have caused another focusing-problem, which causes the context-menu to stay open in another testcase. Attached: a testcase which shows the problem. Happens both under Linux and Solaris. Reminder Fredrikh: Remove workaround when task is fixed.
Created attachment 38488 [details] Testtool-script
Correction; this is a "Solaris only"-bug. The problem is that the context menu is open when the testtool tries to close the document, which results in an errormessage.
adjusted title accordingly
pl->gh: I'm not sure how this is supposed to work. As far as i can see, the "gMouseClick" statement of the script will be evaluated in automation/source/server/statemnt.cxx and basically calls the Click method of a window. However the popup menus are closed in the window frame proc (how system events get evaluated). The correct method to post mouse events would IMHO be Application::PostMouseEvent. However that one is asynchronous which might be why it is not used in automation ? The solution could be a synchronous "CallMouseEvent" on Application; however my first naive try to simply make PostMouseEvent synchronous failed miserably. I don't know who closes the popups in most cases, but it is not the click event as far as i can see. Please advise.
this problem has nothing to do with the fix of i67013 as it is also in m177 the correct method to close a menu without selecting anything is menuselect 0 which I tried and it worked to PL: it is planned to switch to Application::PostMouseEvent (and Application::PostKeyEvent) soon but thorrough testing has to be done (scheduled for XMas 2006)
.
Directly after i67013 was fixed, several tests failed due to context-menus which stayed open, where they earlier without any menuselect (0) had closed. The workaround is, as you mention a menuselect (0), but since this wasn't needed before i67013 was fixed, I see this as a regression.
Set target milestone to 2.2
Reopening this issue. It is neither resolved nor invalid. Furthermore, MenuSelect(0) is not a valid call because slot 0 is not a valid slot. It leads to a crash with shells that do not support any slots. These shells have to provide at least one entry in their slot map. This by default is one for slot 0, which is an invalid id that must not be dispatched. See issue 71300 for more details.
set target to 2.3 as it does not seem possible to implement this until the 2.2 code freeze
moved to 2.4 because of too little time left
3.0
retargeted to 3.x
Reset assigne to the default "issues@openoffice.apache.org".