Issue 15229

Summary: Trouble with OOo instances on seperate displays
Product: General Reporter: sanchezr <sanchezr>
Component: codeAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P2 CC: issues
Version: OOo 1.1 RC3   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 81913    

Description sanchezr 2003-06-03 03:28:53 UTC
When logged in (using display :0) and with OOo running, I cannot open a new
instance on a separate display exported via VNC (using :1).

What happened was that I left my machine logged in with OOo open to a document.
 I left to go somewhere and needed to gain remote access.  I SSHd into my
computer, started the VNC server and exported display :1.  When I tried to open
a new instance of OOo several times, nothing happened.  I killed the VNC session
and logged out.  When I returned home I found seven new documents (Untitled1
through Untitled7) open on display :0.

I am not sure if this is supposed to behave in this manner, but it doesn't correct.

-Roberto Sanchez
Comment 1 thorsten.martens 2003-09-18 11:23:27 UTC
Please check if this behaviour is still reproducible in a more recent
build like a RC3 or RC4. Thanks !
Comment 2 sanchezr 2003-09-18 12:23:45 UTC
Yes, this is still reproducible as of RC3 (Debian package).  I login
into one computer and pull up an OOo application.  Start a VNC session
to the same machine from a remote computer, and any attempts to open
another (or the same) OOo app cause the new window to appear on
display :0, instead of the exported VNC display :1
Comment 3 thorsten.martens 2003-09-25 14:20:58 UTC
TM->PL: as far as I know we´ve had a problem with opening staroffice
tasks in different displays in the past. Can you please have a look,
if this might be the same ? Thanks !
Comment 4 philipp.lohmann 2003-10-07 09:40:02 UTC
As long as the applications insist that only one instance can run at
any  time this problem cannot be solved.
Comment 5 thorsten.martens 2003-10-15 11:59:22 UTC
As Philipp mentioned, this issue won´t be fixed. Of course a wish for
an enhancement may be written instead of this issue.
Comment 6 philipp.lohmann 2003-10-15 12:09:33 UTC
So let's use this one ? The enhancement wish is clear; OOo should be
capable of running multiple instances out of one installation.
Comment 7 philipp.lohmann 2003-10-15 12:10:03 UTC
reassigning as enhancement to bettina
Comment 8 mci 2006-04-03 10:20:32 UTC
*** Issue 15448 has been marked as a duplicate of this issue. ***
Comment 9 richardneill 2008-01-24 17:55:04 UTC
I've just run into this today, as follows:

1)My desktop machine happens to have a copy of OOo running, with a document open.

2)I'm sitting at my laptop, and receive a word document by email. I scp it to
the desktop, and open it by running oowriter over SSH.(*). This normally
displays the document fine on my laptop's screen.

3)In this instance, the oowriter command simply exited, without appearing to do
anything (and of course, the document opened on the wrong display). 

As a minimum workaround, can I suggest that if the startup script detects an
existing Ooo process, but on a different $DISPLAY, it should print a message to
stderr. I understand the reason why the document opens in the existing process,
but the principle of "least surprise" would strongly suggest printing a message.
As well as stderr, display this message (on the expected $DISPLAY) via xdialog
(or kdialog, or zenity, whichever is installed).

A suitable message might be:
 "You have tried to open the file $DOCUMENT on display $DISPLAY (on host $HOST).
However, an instance of OpenOffice is already running on that machine (on
display $DISPLAY2), so this file has been opened in the existing OOo process.

[If you want it to open on this $DISPLAY, please close the other document.
killall -15 oowriter will force an auto-save]"

 #is that actually true about killall -15? I hope so, but I haven't checked:-)

(*)Why do I do it this way? The desktop is much faster, I have gigabit ethernet, 
and the laptop has an issue that clicking the file menu in Ooo usually causes X
to hang.
Comment 10 spwalmsley 2008-07-21 21:00:27 UTC
We've run into this issue using:

 - StarOffice 8 Update 10 ( ~ OpenOffice 2.4)
 - on Sunray thin clients
 - running Solaris 8 (10 as well)
 - multiple users logged in using the same login id on different Sunrays

Note that in this case, you have multiple login sessions for the same user on a
single machine, but each user has a different $DISPLAY environment variable.

In this case, the first user to open StarOffice is fine, but the second and any
subsequent users can't open documents since they display on the first user's screen!

We've tried setting -display and (after a bit of spelunking in the source)
-clientdisplay but neither overrides OO's single minded determination to open
everything on one display.

We *CAN* open separate instances if we use the the -env parameter as follows:
-env:UserInstallation=file://$HOME/.staroffice8/<some unique identifier>.

Unfortunately, this isn't a great solution for us because it would necessitate
maintaining a larger number of separate staroffice configs (e.g. printer setup,
first start wizard, etc.). This workaround might be sufficient for users who
generally use display :0 and occasionally want a second display :1. 
Comment 11 spwalmsley 2008-07-21 21:21:01 UTC
Found a similar complaint related to Sunrays in the general discuss forum:

For example, I have an office with SunRay terminals on a Solaris server. If I'm
there and grab my smartcard (leaving the session running on the server) and then
later on login remotely through Sun Secure Global Desktop (as I would do if
suddenly called away from the office) I can't use OpenOffice! If I open OO from
my SSGD session, the window appears on my SunRay session!

That's just the most common instance where it's annoying. It does the same thing
the other way around, including not opening in the right place when opened in a
window in SSGD and Full Desktop SSGD session at the same time, when SSH sessions
used, etc. What makes it especially annoying is that I haven't run across any
other application that exhibits the same behaviour! All the other apps are smart
enough to open on the session that fired them off!

Comment 12 kavol 2008-10-23 12:52:14 UTC
still present in OOo 3, I just run into it ...
Comment 13 kavol 2008-11-01 21:10:25 UTC
I've just found that it happens even between different users - i.e. when user A
is working on machine X locally and has some OOo application open, then user B
ssh from machine Y to machine X as user B, and then user B opens some OOo
application on machine X, the application is not displayed on machine Y using
x11 forwarding, but the newly opened application shows to user A on his display
on machine X, thus exposing user B to a GREAT SECURITY RISK!
Comment 14 spwalmsley 2010-03-05 16:04:16 UTC
Problem still exists in OOo 3.2 and Staroffice 9.2.

Why is this issue still marked as "UNCONFIRMED" 9 years after first being
reported, and after multiple reports on multiple operating systems?

Are there any plans to make Openoffice respect the $DISPLAY environment variable
like any other well behaved application?
Comment 15 bettina.haberer 2010-05-21 14:57:52 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements". 
Comment 16 sesshomurai 2010-07-25 11:38:41 UTC
*** Issue 15229 has been confirmed by votes. ***
Comment 17 sesshomurai 2010-07-25 12:09:29 UTC
Can someone please fix this? In this age of virtual servers and remote desktops, 
this is a bigger problem and getting bigger.

I'll volunteer to fix it if no one has 8 hours to do it.