gedit fails to start on first try, but does on the second

Thanks for your report.

I can confirm this behavior and think bug 808918 is a duplicate. I'm setting to confirmed and targeting for Oneiric because gedit is a core application.

Added a task for unity. It doesn't happen when launched from a terminal.

So that bug and bug 808918 seem to indicate that this is not a problem in either u2d, u3d or bamf, but more a regression in gedit. It was working in natty, and the part of the code that starts applications didn't change in that regard. Besides the anomaly is limited to gedit and other programs don't exhibit the same issue.

As of my updates this morning, gedit is starting correctly from the terminal and the launcher. I think this issue was caused by a combination of libs that have changed. This is fixed for me.

the issue happens when a document file is opened from within the files & folders lense, sometimes gedit would open the other it wont

Just to add - from the files & folder lens - it's exactly every other time here, starting with doesn't, does. doesn't does, ect.

The only exception to that is if another file is open in gedit, whether on the same or a different workspace

I have not experienced this in about a month. The launchpad/console issue is fixed, but the problem appears to have mutated. as stated above the dash is starting gedit as a server. The window will not appear until another instance is started either by running gedit or choosing a document that will run gedit.

I can reproduce this quite easily:

1) Press Alt + F2, type "gedit", press Enter
2) if gedit opens, close it
3) jump to 1)

It really works only every other time. The curious thing is that if I kill unity-applications-daemon, and start it from the console, then the Dash always succeeds in launching gedit.

Can everyone confirm that this only happens when using alt-f2, and *not* when using the normal dash (ie. hit <super> and type 'gedit'). That's the behavior I am seeing here at least.

(forgot to add) ... and *only* for gedit, correct?

correct - when trying to open gedit from Alt+F2 it only opens opens every other time
(same as when trying to open a text file from the files lens which defaults to gedit, if switched to another default editor then no issue in the lens

Seems like it has something to do with unity or how unity is starting gedit at least, Mikkel it seems you started looking at it, do you want to own the bug for the unity team? ;-) If not feel free to unassign or reassign to somebody else in dx

#848631 is a duplicate. I made a comment in there that may or may not be relevant:

In a terminal, run gedit. Nothing will happen. Then, in a second terminal, run gedit again. Now a window pops up. The interesting thing is the second instance exited immediately. The first instance is still running, but now the following message appears on STDERR:

** (gedit:5671): CRITICAL **: _gedit_app_get_window_in_viewport: assertion `GEDIT_IS_WINDOW (window)' failed

I had a similar problem with empathy's chat window not showing up the first time you click Chat (but it does the second time.) Is this perhaps a problem with Unity?

This is because in Unity's environment, DBUS_STARTER_ADDRESS is set. And in gedit (gedit-dbus.c:767), that will trigger gedit to start as a service instead of a standalone window. So it won't show anything, but it will be around to grab and proxy future gedit opens (as you see when you try to launch it the second time).

Not sure of the proper fix for this yet.

Looking at the DBus spec [1], DBUS_STARTER_ADDRESS is used when auto-launching DBus services. So this is arguably reasonable behavior on gedit's part, and it's confusing for applications that Unity will have that variable set for its subprocesses.

I would argue the best fix is for Unity to strip DBUS_STARTER_ADDRESS and DBUS_STARTER_BUS_TYPE from subprocess environments.

[1] http://dbus.freedesktop.org/doc/dbus-specification.html

@Michael: I don't see DBUS_STARTER_ADDRESS set here. I tried starting a gnome-terminal from both the launcher and the dash...

Sorry Michael, Seb just taught me on IRC to use 'strings /proc/$(pidof gedit)/environ | grep DBUS', and lo and behold, my gedit *does* have the starter address set.

fwiw - i bet this behavioral change is related to gedit recently switching from a dbus-glib based single-instancing to a GApplication based one.

I added the following to both apps and files lenses and now everything starts as it should. Thanks to Michael Terry for debugging :-)

+ /* Sub processes inheriting our environment may be confused if they
+ * see a starter bus set */
+ Environment.unset_variable ("DBUS_STARTER_ADDRESS");
+ Environment.unset_variable ("DBUS_STARTER_BUS_TYPE");

This bug was fixed in the package unity-lens-applications - 0.4.10-0ubuntu2

---------------
unity-lens-applications (0.4.10-0ubuntu2) oneiric; urgency=low

  * Cherry-pick from upstream:
    - gedit fails to start on first try, but does on the second (LP: #827414)
 -- Didier Roche <email address hidden> Wed, 28 Sep 2011 12:21:01 +0200

I suppose this is not a gedit bug, as it starts up just fine from a terminal.

This bug was fixed in the package unity-lens-files - 0.6.10-0ubuntu1

---------------
unity-lens-files (0.6.10-0ubuntu1) oneiric; urgency=low

  * New upstream release.
    - Unity's files lens fails to mount bookmarked remote shares (LP: #760309)
    - gedit fails to start on first try, but does on the second (LP: #827414)
    - Files lens should also search Downloads (LP: #748915)
    - Dash opens browser when selecting a FTP-bookmark (LP: #862112)
 -- Didier Roche <email address hidden> Thu, 29 Sep 2011 15:49:50 +0200

Similar bug 808918 has been marked as a duplicate of this bug, but the behavior is a bit different and it persists even though this bug has been fixed (it seems reliably reproducible on a fully updated Precise system), so I suspect that it is not really a duplicate. I have commented in bug 808918 (https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/808918/comments/9) with details.

I'm having this problem on 11.10 with unity 2d:

- click on the panel, write terminal, execute
hdante@aielwaste:~$ set | grep -i dbus
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-AWtwvAGZYd,guid=e5ab56cebeaea834bcdeba6b00000104
DBUS_STARTER_ADDRESS=unix:abstract=/tmp/dbus-AWtwvAGZYd,guid=e5ab56cebeaea834bcdeba6b00000104
DBUS_STARTER_BUS_TYPE=session
  gitcvs.dbuser
_qdbus ()
hdante@aielwaste:~$ gedit
^C
hdante@aielwaste:~$ unset DBUS_STARTER_ADDRESS DBUS_STARTER_BUS_TYPE
hdante@aielwaste:~$ gedit
hdante@aielwaste:~$

It only happens with unity 2d. I'm so pissed off. I just rm -rf ~/.* thinking it was a lost socket.

It´s still here on Unity-2D.

I still have this in Unity 2D as well, in Precise, still as described in bug 808918. (I haven't tested in Oneiric in a while.)

Because it seems like this only happens to Unity 2D users, I added Unity 2D to affected list.

This is NOT fixed. Still an issue in ubuntu 11.10 with all the updates up to date.

I have this problem on 11.10 with unity 2d

Reporting a bug in Ubuntu is like trying to have a serious conversation with /dev/null

Thanks for all your comments. I can see how this is unfuriating. I'm using today's trunk on Precise, and I'm not seeing this problem, but perhaps I'm not doing the correct thing. I will investigate more.

We added the fix mentioned above (see bug 873027) on 12 Oct, but that was too late for Oneiric.

I got tired of waiting for this to be fixed, so I implemented a workaround.

I moved the gedit binary to gedit.bin, then I created a shell-script named "gedit" that calls gedit.bin with the --standalone option:

% mv /usr/bin/gedit /usr/bin/gedit.bin
% vi /usr/bin/gedit

#!/bin/sh
/usr/bin/gedit.bin --standalone "$@"

% chmod 755 /usr/bin/gedit

Hopefully this helps someone who is having this issue.

Running Precise, I'm unable to reproduce this bug. Can anyone else using Precise confirm?

Can't reproduce in Unity-2d 5.4.0-0ubuntu1 via steps from comment #25

Gerry, I had this problem in 11.10 (comment #30), but I just installed Precise Beta 1 and can't reproduce anymore too. Seems to be fixed.

About comment #36: in both cases i ran unity-2d.

Thanks for the comments Vadim & Jorge!

I'm still unable to reproduce, so marking as fix released.

Is this issue going to be fixed in 11.10? I still have the issue and I install any available updates daily.

(Using Ubuntu 11.10 AMD64 Unity3D)

Bug is still present in precise.

For me, this problem went away after upgrade to 12.04.

Problem was fixed in 12.04 for me as well.

For me the problem is still present in 12.04 fully upgraded so far.

I've had the exact same problem since I upgraded from 12.04 to 12.10! I've never had it before and I've been using Ubuntu since v4 with heavy usage of gedit!!!...I can confirm all of this:

gedit 3.6.1
-open just fine when launched from Unity or the terminal
-opens the second time when double-clicking or hitting enter while having selected the file (process appears on system monitor the first time I double-click though!)

Very strange indeed...

This is most likely not related to Unity, for the same problem occurs for me with Linux Mint 13 XFCE.

If gedit is started from terminal (just "gedit", no arguments passed), it doesn't show up, nothing is printed in terminal and thus effectively hangs in limbo. Task Manager sees it sitting around consuming 0% CPU, it doesn't terminate on it's own.
When gedit is then started again, either via desktop shortcut/menu or another terminal window, it causes the first gedit instance to terminate with this message:

** (gedit:3900): CRITICAL **: _gedit_app_get_window_in_viewport: assertion `GEDIT_IS_WINDOW (window)' failed

The second instance then shows up normally. If a filename was passed as argument, it opens the file as expected.

If gedit is run with --standalone option, it always starts normally without fault, no matter what I tried.

The above is 100% reliably reproducable for me.

Now there are some oddities. For example when I start gedit from a panel (FYI: xfce4-panel 4.10.0), it always starts normally (launcher command: "gedit %U", or just "gedit").
When I doubleclick to open a text file in Thunar, the bug also occurs. When I do the same in Nautilus, the same works without the problem.

By the looks of it, this is a gedit bug. Obviously, gedit tries to find a running instance so it can open a new tab in the existing instance. It probably lacks a robust handler for the condition where it fails -- for whatever reason -- to find a running instance.

Hope that helps.