GNOME Bugzilla – Bug 112779
Implement multi-screen support
Last modified: 2015-09-29 03:15:45 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
I believe there is an X manager selection way of doing this. Ccing greg as he actually understands this stuff.
I think this can be handled by checking the environment variable 'DISPLAY'. I don't know how this works with CORBA.
*** Bug 114219 has been marked as a duplicate of this bug. ***
1.0 if we have time.
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.
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 :/
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.
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.
Created attachment 21155 [details] [review] first attempt
*** Bug 122677 has been marked as a duplicate of this bug. ***
*** Bug 128880 has been marked as a duplicate of this bug. ***
*** Bug 137907 has been marked as a duplicate of this bug. ***
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.
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?
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.
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.
s/memory corruption/data corruption BTW Mark thanks to have looked into this, it's very useful.
>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.
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 ...
Thanks Mark, that works great. We are already blocked on mozilla pffff http://bugzilla.mozilla.org/show_bug.cgi?id=239356
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.
*** Bug 148133 has been marked as a duplicate of this bug. ***
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.
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Mass-moving bugs from Target Milestone: 1.6 to 1.8 because of feature, UI and string freeze.
Blocking on mozilla not being multi-head safe; setting target to future.
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...
*** Bug 319450 has been marked as a duplicate of this bug. ***
Gecko needs to be fixed first; I posted the summary of a irc conversation with roc at http://wiki.mozilla.org/Widget:Gtk2:MultiHead .
Ubuntu bug https://bugs.launchpad.net/epiphany-browser/+bug/86933
Obsoleted by the backend change?
(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.
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.)