GNOME Bugzilla – Bug 114219
Shouldn't reuse existing process if DISPLAY is different
Last modified: 2015-09-24 18:42:58 UTC
I just ssh'ed into a machine which had epiphany running on the local display. When I ran epiphany again, it said it was going to use the existing process instead of creating a new one. Epiphany should check to make sure that DISPLAY is the same before doing that.
*** This bug has been marked as a duplicate of 112779 ***
*** Bug 137907 has been marked as a duplicate of this bug. ***
Allowing multiple instances of epiphany to share the same profile 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.
Would it be simpler to modify the Mozilla source to allow different DISPLAY's for different windows? I'm not that proficient at X coding so I'm not sure how hard this would be. I would imagine the code in Mozilla to be layered so that we have: Window handling code Display handling code (font issues, rendering, etc.) <- does this exist? Cache and network code Basically cache and network code should be DISPLAY independent. The other layers should be DISPLAY dependent, but never write directly to file. This would avoid the problem of having multiple instances of Epiphany/Mozilla using the same directory. In this specific instance I think that is all that's required. I only comment because this is a problem for me as well (I SSH into my laptop from where I run Epiphany).
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
*** Bug 463515 has been marked as a duplicate of this bug. ***
You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you please check again if the issue you reported here still happens in a recent version and update this report by adding a comment and adjusting the 'Version' field? Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE after 6 weeks.
This 'works' with the current epiphany-webkit package in Debian unstable, but I don't think this is what we want - Epiphany starts thinking it crashed the last time it was run. This sounds like data loss _will_ happen to me to people trying to use this 'feature'. Maybe we need to turn this into a bug to have Epiphany disallow running two processes in this case.
(In reply to comment #8) > This 'works' with the current epiphany-webkit package in Debian unstable, but I > don't think this is what we want - Epiphany starts thinking it crashed the last > time it was run. This sounds like data loss _will_ happen to me to people > trying to use this 'feature'. Maybe we need to turn this into a bug to have > Epiphany disallow running two processes in this case. Maybe use libunique ( http://live.gnome.org/LibUnique ) library could be a solution?
(In reply to comment #9) > Maybe use libunique ( http://live.gnome.org/LibUnique ) library could be a > solution? Not sure. Epiphany already does what libunique would do (connect to the session bus, try to grab its well-known name, call a method to open a new window instead of launching a new process). I think the problem here is that the ssh session doesn't know about the user's desktop session, so it doesn't see an instance is already running.
Reopening as the information requested in comment #7 has been provided.
Yes, it is still valid. epiphany --version WWW 3.4.2 How to reproduce: As root: X -ac :2 As user: DISPLAY=:2 epiphany & epiphany Second command should open window in the current display, but it does not.
=> Resetting NEEDINFO.
(In reply to Stanislav Brabec from comment #13) > Second command should open window in the current display, but it does not. Is this different from the behavior of other GtkApplications?
Closing old NEEDINFO bugs