Apache OpenOffice (AOO) Bugzilla – Issue 87538
X11 window and AppleEvent timeout on startup of OO 2.4.0 for OSX on Leopard - approved
Last modified: 2010-03-27 21:16:29 UTC
Running OSX 10.5.2 "Leopard" on new-style iMac (Intel chipset) Running OpenOffice 2.4.0 (OSX Intel) released version On startup of OpenOffice: (1) a window appears, for the application X11, headed "xterm" and containing a single line of text "bash-3,2$". It would be better to hide this window. (2) after a short delay, a pop-up window appears, headed "OpenOffice 2.4", with the text "AppleEvent timed out". This is not fatal, but it is not pretty. OpenOffice then opens up into the Writer application, which appears to work successfully, as does opening up the other applications.
Known issue, click "OK" and ooo should start, as you have found. This won't be fixed due to that aqua release for 3.0, and the fact that 2.4 is the last X11 release, and there wasn't enough time to find a fix before the release of 2.4.
smsm1: Can I close this as WONTFIX? Or should we at least attempt to fix it for 2.4.1? James McKenzie
http://shaunmcdonald131.blogspot.com/2008/03/ooo-possible-fix-for-command-timed-out.html looks like the fix.
Raising priority since this issues will become more important once the next X11 update is out with the next Mac OS X 10.5.x update, which will be before the 2.4.1 release. Even if the average mac user at the moment only sees a command time out the situation will change once the next updates of X11, which already can be downloaded from http://trac.macosforge.org/projects/xquartz really prevent OOo from launching. I launched OOo and waited about two minutes for the timeout message, confirmed this message with OK and waited another 30 minutes one time and an hour the second time but OOo wouldn't come up. See the comment from smsm1 for the fix. Additionally an apple employee suggested to check from OS version to "Is $DISPLAY set?" Any chance to get this fixed for 2.4.1?
The correct solution is detailed here: http://shaunmcdonald131.blogspot.com/2008/03/ooo-possible-fix-for-command-timed-out.html I would make one small chanege. Instead of doing a check on the OS version, you should do a check on whether or not $DISPLAY is already set. If it is, assume it's valid. This has been not working with Leopard for months now, and the fix is trivial. The situation will be even worse once we merge the XQuartz changes into the X11 shipped with Leopard. This is a *MUST* fix if you want to support Leopard!
I have just checked on Mac OS X 10.5.2, std install with developer tools, and the $DISPLAY is set. shaun-mcdonalds-computer:~ shaunmcdonald$ echo $DISPLAY /tmp/launch-eQi7Tn/:0 Just changing that if is not enough, because the applescript would still try to launch X11 when the $DISPLAY variable is set, which is what causes the timeout. Letting the command to start X11 itself is a better solution, rather than manually checking that X11 is started, and manually starting it. The Applescript doesn't manually change the $DISPLAY variable at any point. Adding this issue to the 2.4.1 blocker tracking issue. Anyone got a CWS that can be used for this change?
Re: "Letting the command to start X11 itself is a better solution, rather than manually checking that X11 is started, and manually starting it." You should not ever need to manually start X11 on Leopard. It is started automatically for you if it is not already running. DISPLAY is set in your droplet. That is why it isn't working on OSX with the newer versions of X11 (http://xquartz.macosforge.org).
TM->PL: please have a look.
assign to macport owner
added "approved" to the title, because it will be easier to work with the 2.4.1 meta issue during release status meetings.
SBA: Set issue target (OOo 2.4.1). Is anyone working on this? Please drop a comment then.
This issue just need the changed mentioned on the blog post to be done. I don't have the time to create a CWS and do the change.
adding mox to CC as obr mentioned this might interest him
If someone can setup a CWS for this for ooo 2.4.1, I can make the requiired commit.
What modules would you need ?
Set myself to CC Pleas contact if you need QA Raphael
After moving around for a while, I think the applescript files are located in the instsetoo_native module, which would be the only one needed for this fix. instsetoo_native/macosx/application/main.applescript
Mox: thanks for the file location. http://lxr.go-oo.org/source/installation/instsetoo_native/macosx/application/main.applescript
*** Issue 90483 has been marked as a duplicate of this issue. ***
*** Issue 90521 has been marked as a duplicate of this issue. ***
This bug has become a show-stopper. As far as I can tell OpenOffice simply doesn't work anymore if you install it on OS X 10.5.3. Apple broke X11 in their latest update. If you install the recommended fix to X11, v2.2.3 from xquartz.macosforge.org, then you've got X11 working again on 10.5.3 but OpenOffice.org does not start unless you install Shawn McDonald's patch mentioned in this bug report. Currently the message in the popup is "Command timed out" and not "AppleEvent timed out"
10.5.3 did not contain any updates to the X11 bits in Leopard, thus I highly doubt that 10.5.3 "broke" X11 for you. The fact that OpenOffice is not working with some X11s in OSX is an OpenOffice bug, not us "breaking" X11. I've been trying to get you guys to fix this bug with since December, and I'm glad it's finally getting addressed.
*** Issue 91892 has been marked as a duplicate of this issue. ***
*** Issue 94432 has been marked as a duplicate of this issue. ***
Any motion on this? It's quite an embarrassing blotch on OO.o that it doesn't work with Leopard. We've made multiple attempts to get you to integrate the fix, and 2 releases have been made since then (2.4.0 and 2.4.1). Please get this integrated.
I have pasted the content of Shaun proposal, and I'll have a look today. I have created macx11leofix, and I'll commit a fix (I expect to find a working solution) by today Anybody to do the QA ? Starting point of my code will be the following lines, Shaun posted on his blog : Then replace the code block "on openSoffice(aFile)"...."end openSoffice" with the following: on openSoffice(aFile) if (atLeastOSXVersion(10, 5, 0)) then -- if we have leopard, we don't need to manually start the X server first set theCmd to "sh " & (quoted form of (POSIX path of getOOProgramPath() & "soffice")) & " " do shell script theCmd & aFile & shellTerminator() else set theDisplay to startXServer() if (theDisplay is equal to "error") then return end if set theEnv to "DISPLAY=" & theDisplay & " ; export DISPLAY; " set theCmd to "sh " & (quoted form of (POSIX path of getOOProgramPath() & "soffice")) & " " do shell script theEnv & theCmd & aFile & shellTerminator() -- logEvent("open CMD: " & theEnv & theCmd & aFile) end if end openSoffice
@all : Can you confirm the following change works for you ? => just replace the old openSoffice() with the one below : on openSoffice(aFile) if not (atLeastOSXVersion(10, 5, 0)) then set theDisplay to startXServer() if (theDisplay is equal to "error") then return end if set theEnv to "DISPLAY=" & theDisplay & " ; export DISPLAY; " end if set theCmd to "sh " & (quoted form of (POSIX path of getOOProgramPath() & "soffice")) & " " do shell script theEnv & theCmd & aFile & shellTerminator() -- logEvent("open CMD: " & theEnv & theCmd & aFile) end openSoffice
Issue fixed in macleofix4x11 cws Waiting for approbation before to set the cws as ready for QA
I just made this code swap last night, and it worked perfectly, with no problems whatsoever. I did restart my Mac before I re-opened OpenOffice. And it's still working today. I also have to say: since incorporating this fix, OOo 2.4.1 opens much faster. It's not stuck on the X11 window for as long as it used to be. Many thanks to Shaun for the fix!
Important: macleofix4x11 is based on OOH680_m17 == 2.4.2 base
@kgwritenow My change is not exactly what Shaun proposed (less lines). Can you please confirm it works too? Thanks :-)
the previous fix was not correct (theEnv was undefined) A new fix has been commited : on openSoffice(aFile) set theEnv to "" if not (atLeastOSXVersion(10, 5, 0)) then .. and so on
That's the error message I got: "The variable theEnv is not definted." I will try this new-new fix later tonight, and I'll post back. Thanks!
@ericb -- I had an extra five minutes and added the new code. Worked perfectly! Everything is fixed. Many thanks again. :)
@kgwritenow Please verify with the latest change ericb2 did. For me this works but only the first start. If I close OOo via File->Quit and start it a second time the whole OOo seems to be slowed down, not significantly but noticeable. However if I close X11 too and let OOo start both X11 and OOo I'm back to full speed. Strange. MacMini 1.83GHz CoreDuo, 2GB Ram, Mac OS X 10.5.5, X11 2.3.1
@maveric-- I did add ericb's revised code. I echoed what you did and found the same issue you did. After I quit OOo with X11 still open, I couldn't restart OOo. After I quit X11, OOo restarted just fine and very quickly. OOo now opens so quickly, I can quit X11 every time I quit OOo and not lose any time ... as long as OOo opens (which it is now doing). Let me know if I should test anything else -- happy to be part of the trouble shooting -- it benefits everyone if this gets figured out.
*** Issue 94050 has been marked as a duplicate of this issue. ***
correct target, set to verified (verification was actually done by ericb)
add blocker
@pl : my code was correct, and after I discussed with Eric Hoch, the slow down was caused by some corruption in the prefs. BTW, why isn't macleofix4x11 not integrated in 2.4.2 ? ( or I missed something ... )
Considering: * issue 88367 as a possible duplicate (or partial duplicate) of this issue 87538 * observation in 88367 that Shaun's fix (as it's known) did not resolve; http://www.diigo.com/annotated/746afb5e75086682f4d0d966a97dfebb for a highlight * the possibility of a secondary issue in 88367.
The vast majority of people found the fix helped, there were a few people who either it didn't work for, or they couldn't manage to get it to work.
That other bug looks like two issues... one of which is a dupe of this (the fact that launch timed out waiting for the X server)... and another which is obscure to me (that once he includes this fix to connect to the X server, only a limited functionality window is visible)
@ericb: it's not integrated because no integration was done. There is no newer build yet, so I guess it will go into the next OOH build. They're not doing them very often.
@pl : Ok, thanks for the information. I was afraid we missed the gate. Now I know :-)
Sorry, I just talked to mh and it seems the CWS really missed the gate. 2.4.2 was released (without much fanfare on 28th of october, OOH680m18 indeed was the release build as far as I can see). The CWS is nominated and will go in a 2.4.3 build when there is one.
That really isn't good enough. You need to release a 2.4.2.1 for OSX with this fix. It can't wait 6 months for 2.4.3. This issue was reported initially against 2.4.0 with a fix back in February (yes, this bug report postdates when I initially notified you guys of the problem). OpenOffice.org 2.x will not work (AT ALL) on OSX 10.5.5. If you're serious about letting people use OOo on OSX, you need to fix this brown-bag style.
Actually I think people should use the very nice 3.0 version we have for MacOSX now. Which runs fabulously without using an Xserver at all. I understand your issue about this being not fixed for quite a while, though. But please take this up with the release committee available at the releases@openoffice.org mailing list.
Maybe just release unofficial 2.4.2 with the added fix to the script. You don't have to build anything, just get the official 2.4.2.dmg, open it and make the changes. Then provide link to that on the mac@porting pages. Should be enough for those that still want to use 2.x and not 3.0.
It may be the case that someone has an extension or something else that prevents them from using version 3, rather than 2.4, therefore we should get this released asap.
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues
This issue is NOT fixed in the Apple/X11 version of OOo. Please reopen, since I do not have permissions to reopen this issue. This is a *HIGHLY TRIVIAL* issue to fix, and the fix was reported over a year ago!
Reopening as requested. Just ignoring issue does not make it become fixed.
changed target and set to fixed again , as cws macleofix4x11 has ben integrate in 2.4.3 branch
I don't know, if this issue is fixed at the 2.4.3 release. However, it don't make sense to let this issue open. Because 2.x is end of life and 3.x use X11 anymore. So, close the issue
That would be great if 2.4.3 was actually released, but it hasn't been released. The latest version for Mac/PPC is 2.4.0! This is horrific that a trivial bug found and reported in 2007 (yes, I emailed OOo months before this bug report) is still not fixed in 2010!
Normaly we are now at OOo 3.2 and at the 3.x versions, this fix makes non sense. X11 is no longer requested Many native language teams released OOo 3.x versions. The en-US is not relesed at all :-( I will change this, and release a 3.2.0 version for en-US. But I need your help. If you want help to test, write a Email at rbircher@openoffice.org, thanks
*** Issue 88367 has been marked as a duplicate of this issue. ***