After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 112779 - Implement multi-screen support
Implement multi-screen support
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: General
unspecified
Other Linux
: Low enhancement
: ---
Assigned To: Epiphany Maintainers
Marco Pesenti Gritti
: 122677 128880 148133 319450 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-05-11 18:42 UTC by Edd Dumbill
Modified: 2015-09-29 03:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
first attempt (18.31 KB, patch)
2003-11-03 13:23 UTC, Marco Pesenti Gritti
needs-work Details | Review

Description Edd Dumbill 2003-05-11 18:42:37 UTC
Forwaded from http://bugs.debian.org/192221

From: 	Jerry Haltom <wasabi@larvalstage.net>

Package: epiphany-browser
Version: 0.5.0-rel-3
Severity: normal

Epiphany, and most other Mozilla based browsers use some sort of instance
manager, that lets one open multiple windows without creating two
instances. Typing epiphany from the prompt, when epiphany is already open,
opens a new window using the preexisting session.

When using a multihead display, the original session could be on the wrong
screen! Thus, the new window, could pop up where not expected. Very confusing.

Not going to get into Xinerama. :D
Comment 1 Dave Bordoley [Not Reading Bug Mail] 2003-05-11 20:39:30 UTC
I believe there is an X manager selection way of doing this. Ccing
greg as he actually understands this stuff.
Comment 2 Gregory Merchan 2003-05-13 16:43:49 UTC
I think this can be handled by checking the environment variable
'DISPLAY'. I don't know how this works with CORBA.
Comment 3 Dave Bordoley [Not Reading Bug Mail] 2003-06-02 03:25:20 UTC
*** Bug 114219 has been marked as a duplicate of this bug. ***
Comment 4 Dave Bordoley [Not Reading Bug Mail] 2003-07-08 16:40:14 UTC
1.0 if we have time.
Comment 5 James Willcox 2003-07-20 18:55:17 UTC
I made a feeble attempt at trying to solve this a long time ago. 
There are basically two approaches to fixing this.

1)  Make epiphany run an instance per screen.  This is the way gedit
does it.  This would work for epiphany too, but some other things
would need to be changed (like sessions_crashed.xml would need to be
renamed to sessions_crashed-$DISPLAY:SCREEN or something).

2)  Make epiphany a truly multihead app.  This would probably involve
adding 'screen' arguments to miscellaneous places, etc.

I tried approach 1) because I thought it would be easier.  In
retrospect, I think we should go with 2).  I don't have a multihead
setup right now (I loaned my second monitor to someone), but when I
get it back I'll give it another shot.
    
Comment 6 Marco Pesenti Gritti 2003-07-20 22:11:47 UTC
1 could be hard to implement. I'm not sure if you can have multiple
process using the same mozilla profile for example.
About "truly multihead", is there any docs about it ?
I have not even idea about how a multihead setup looks :/
Comment 7 Marco Pesenti Gritti 2003-07-23 14:53:56 UTC
Snorp, do you think this should stay on the 1.0 radar ? I have no idea
about the complexity, but I have the impression it's a bit too late.
Comment 8 Marco Pesenti Gritti 2003-11-03 13:22:49 UTC
Going to attach the first attempt to a patch. Chpe, would be nice if
you could review.
The problem that I have no idea how to solve is session management.
The session is per display.
Comment 9 Marco Pesenti Gritti 2003-11-03 13:23:44 UTC
Created attachment 21155 [details] [review]
first attempt
Comment 10 Bernardo Silveira 2003-12-01 12:01:08 UTC
*** Bug 122677 has been marked as a duplicate of this bug. ***
Comment 11 Christian Persch 2003-12-09 10:46:26 UTC
*** Bug 128880 has been marked as a duplicate of this bug. ***
Comment 12 Christian Persch 2004-03-22 11:59:04 UTC
*** Bug 137907 has been marked as a duplicate of this bug. ***
Comment 13 Mark McLoughlin 2004-03-26 08:45:14 UTC
Marco, jrb pointed me at this. Some comments:

  + You need to think about whether you want multi-screen or multi-display
    support. I see that you've started implementing multi-display support
    but this could cause all sorts of weird problems.

    Effectively, what will end up happening is that you've an epiphany 
    instance running in the environment of one session but displaying stuff
    to another session. So, $SESSION_MANAGER, $SSH_AGENT, $GNOME_KEYRING,
    $DBUS_SESSION_BUS etc. will be all wrong when displaying stuff in the
    other session.

  + The way you decide whether you want epiphany to have an instance per-screen,
    per-display or per-host is by fiddling with the registration environment
    passed to bonobo_activation_register_active_server (). e.g. if you want 
    to do it per-display, you would do

{
  char   *display_name, *p;
  GSList *reg_env;

  display_name = g_strdup (gdk_display_get_display_name (display));

  /* strip off the screen portion of the display */
  p = strrchr (display, ':');
  if (p)
    {
      p = strchr (p, '.');
      if (p)
        p [0] = '\0';
    }

  reg_env = bonobo_activation_registration_env_set (
               NULL, "DISPLAY", display_name);
  bonobo_activation_active_server_register (
       AUTOMATION_FACTORY_IID, 
       BONOBO_OBJREF (shell->priv->automation_factory),
       reg_env);
  bonobo_activation_registration_env_free (reg_env);
}

    If you wanted to make epiphany per-screen, just remove the code to strip
    off the screen part. No need to do anything to make it per-host, that's
    the default behaviour

  + Looking up displays with the display string is going to be inherently
    error prone since you're not guaranteed to display names pointing at
    the same display will match - e.g. 127.0.0.1:0 vs. localhost:0 or
    piglet.blah.net:0 vs piglet:0. I don't have a good solution for that
    (and bonobo-activation suffers from the same problem) but there may be
    some reliable way of normalising the display names.

  + If you go with per-display rather than multi-display, pass the screen number
    via EphyAutomation:load_url() rather than the display name.

  + In ephy-automation.c, you're opening a new display for each screen and
    then using the default screen. That's going to very expensive so you're
    much better of using gdk_display_get_screen (display, screen_number);

  + I don't see you handling multi-screen with menus anywhere, but unlesss the
    menu is attached to a widget (gtk_menu_attach_to_widget()).

  + The clipboard is per-display, so if you're doing per-display you need to
    use gtk_clipboard_get_for_display()

  + Icon sizes are a GtkSetting, and GtkSettings are per-screen. You'll need
    to do gtk_icon_size_lookup_for_settings (gtk_display_get_screen (d, n), ..)

  + If doing per-display need to use gdk_display_pointer_is_grabbed instead
    of gdk_pointer_is_grabbed. Same for pointer_ungrab

  + Looks like startup notification isn't going to work with multi-display. It
    looks to me like we'll end up send the startup_complete xmessage to a root
    window on the wrong display. Prolly needs to be fixed in gtk

  + The fullscreen code needs work to handle different screens.

  + The about dialog needs to be displayed on the correct screen.
Comment 14 Mark McLoughlin 2004-03-26 08:52:22 UTC
Oh, btw, I know the problem here is that mozilla isn't happy with multiple
instances using the same problem etc. I think we need a solution to that rather
than doing the multi-head thing to work around it. The work around isn't going
to fix multiple sessions using the same NFS mounted homedir from different
machines for example :/

Also, I'm not sure whether there are potential multi-display problems with
mozilla itself - e.g. can plugins handle multiple displays at the one time?
Comment 15 Marco Pesenti Gritti 2004-03-26 10:29:10 UTC
Mark, I stopped to work on that patch because I was starting to see hardly
solvable problems. Now you add a lot more of them so ... yeah the make epiphany
multi-display hack isnt going to work well :/

On the other side allowing multiple instances is not simple. We store a lot of
data in our profile and additionally there is the problem that we have to
address it in two different platforms (mozilla and epiphany).
See http://www.mozilla.org/projects/embedding/shared_profiles.html to start
feeling the pain.

Problems are technically solvable but they would need extensive changes to
mozilla code to be done correctly. Without a strong buy in of the mozilla
developers that doesn't seem very likely to happen. Obviously this is a serious
issue for Firebird/Mozilla too.

Possible solutions in detail.

Mozilla:

Cookies - IPC
Cache - A major rewrite necessary to deal with file sync issues. Having a
separate cache for each instance sounds like a pain for users.
Certificates - Upgrade db would be enough ?
Preferences - IPC if done on the mozilla side. Maybe it would be worth to
implement mozilla preference service using gconf instead which would solve some
other issues.
Password Manager - Same as cookies I guess.

Epiphany:

History - Definately a data server or a multi process database.
Bookmarks - Ideally data server. Maybe a reload-when-file-changed hack could
work too.
Comment 16 Marco Pesenti Gritti 2004-03-26 10:42:16 UTC
Something that would help me is to understand the use cases of multi-display.
I can think only to multiple users logged in on the same machine.

For this case it seem that the ability to share data would is not necessary (why
would you login with the same user two times ?) but we need at least to avoid
memory corruption. To do that we could just lock the whole profile, show a
warning and exit if an user try to start multiple instance of epiphany using the
same profile.

Anyway I think we should start implementing multi-screen support in any case.
That at least solve part of the problem.
Comment 17 Marco Pesenti Gritti 2004-03-26 10:49:16 UTC
s/memory corruption/data corruption

BTW Mark thanks to have looked into this, it's very useful.
Comment 18 Marco Pesenti Gritti 2004-03-26 11:16:58 UTC
>To do that we could just lock the whole profile, show a
>warning and exit if an user try to start multiple instance of epiphany using the
>same profile.

Obviously that isnt necessary, being bonobo-activation an user daemon it already
starts an instance per user.

/me <- dork

>Something that would help me is to understand the use cases of multi-display.

http://bugzilla.gnome.org/show_bug.cgi?id=114219 has an use case.

/me <- dork * 2

I'll reopen that one so that we can deal with it separately. I think it's pretty
clear that multi display is not the correct solution for it.
Comment 19 Mark McLoughlin 2004-03-30 12:46:59 UTC
Just saw your blog entry - I've never used an actual multiscreen setup either,
but 'Xnest -ac -scrns 2 :1' was enough for me when doing the panel, nautilus
etc. support ... Dunno whether you've tried that yet ...
Comment 20 Marco Pesenti Gritti 2004-04-01 15:13:39 UTC
Thanks Mark, that works great.

We are already blocked on mozilla pffff

http://bugzilla.mozilla.org/show_bug.cgi?id=239356
Comment 21 Duncan 2004-05-04 20:26:09 UTC
The obvious senario (to me anyway) is not these multi-display machines or the
same user logged into the machine locally more than once, but just using the
same computer both locally and remotly via ssh.

I often move between my home and office but still run apps on my home machine
when I'm in my office (X over ssh). So I have my web browser running in the
morning, go into the office and try to start my web browser to display on my
office desktop (but running on my home machine). This does not work because it
bings up a new window on my home desktop display rather than on my office deskop
display. I have to killall $BROWSER_OF_CHOICE and run it again before it will
display on my office desktop.
Comment 22 j_lozinski 2004-07-22 16:41:24 UTC
*** Bug 148133 has been marked as a duplicate of this bug. ***
Comment 23 Christian Persch 2004-07-25 13:20:52 UTC
Mass-moving Target 1.4 -> 1.6 because of feature and UI freeze. Sorry for the
bugspam, search for "mass-move-1.4-1.6" to filter all of it.
Comment 24 Christian Persch 2004-10-13 10:51:57 UTC
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Comment 25 Christian Persch 2005-02-10 18:23:11 UTC
Mass-moving bugs from Target Milestone: 1.6 to 1.8 because of feature, UI and
string freeze.
Comment 26 Christian Persch 2005-07-17 23:05:07 UTC
Blocking on mozilla not being multi-head safe; setting target to future.
Comment 27 Tim Connors 2005-08-28 04:24:49 UTC
I don't actually use epiphany, but I am following this bug from galeon.

Anyway, for usage scenario, look at how xemacs and gnuclient does it.

Start up xemacs (possibly recent emacs works as well, although gnuclient always
seemed inferior there) on localhost.  Type M-x gnuserv-start.

Ssh into your box.  Run gnuclient from the shell.  Watch in amazement as exactly
the same session pops up remotely.

There is only one process, running on the server.  gnuclient talks to a socket
and/or port, and pipes in an elisp statement to the xemacs server.  The xemacs
server runs that elisp code, which basically contains the display name/number to
use, along with possibly any security details (Xauthority settings, permission
files, etc).  A new frame pops up on the remote display.  The new frame still
has any environment variables and settings and filesystem from the xemacs
server, but I don't know what it does about fonts on the remote Xserver.  None
of this messing about with $SESSION_MANAGER, $SSH_AGENT, $GNOME_KEYRING,
$DBUS_SESSION_BUS etc, because everything is taken from the server process (and
this works very much well enough for xemacs, so I don't see why it wouldn't work
for a browser).  When you close the file being edited, the gnuclient process is
told it can exit.  Hence gnuclient is very lightweight, it just asks to open a
file or display, or other elisp code on the server, and waits around until it is
told it can go.  Hell, xemacs seems to handle you destroying windows on some
displays and not others if an Xsession crashes, without itself crashing!

Funny thing is, it can even do terminals.  Although I don't think epiphany is
compiled with AA support :)

If this doesn't work, read the SECURITY section of the manpage for gnuclient. 
It has been so long since I set this up for myself, and it has worked ever since
without a problem, that I may have forgotten some useful information...
Comment 28 Christian Persch 2005-10-22 09:17:06 UTC
*** Bug 319450 has been marked as a duplicate of this bug. ***
Comment 29 Christian Persch 2005-12-31 20:53:38 UTC
Gecko needs to be fixed first; I posted the summary of a irc conversation with roc at http://wiki.mozilla.org/Widget:Gtk2:MultiHead .
Comment 30 Sebastien Bacher 2007-05-25 09:47:34 UTC
Ubuntu bug https://bugs.launchpad.net/epiphany-browser/+bug/86933
Comment 31 Diogo Campos 2015-09-29 02:54:33 UTC
Obsoleted by the backend change?
Comment 32 Michael Catanzaro 2015-09-29 03:15:04 UTC
(In reply to Diogo Campos from comment #31)
> Obsoleted by the backend change?

I don't think so, but in GNOME 3, you know you're not going to get a new window unless you select the New Window option, so it's just an obsolete problem in general.
Comment 33 Michael Catanzaro 2015-09-29 03:15:45 UTC
And yeah, if you create a new window, it should appear on the current screen. (If that isn't happening, then we should reopen this.)