menu items selected from screen 1 open on screen 0

Bug #346964 reported by Brian J. Murrell on 2009-03-22
114
This bug affects 14 people
Affects Status Importance Assigned to Milestone
GLib
Fix Released
Medium
GNOME Panel
Fix Released
Medium
glib2.0 (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gnome-panel

I have a dual head configuration (no xinerama) on current juanty. Any menu item chosen from a menu on screen 1 always opens on screen 0. If I direct a terminal window to open on screen 1 by manually setting it's DISPLAY variable then opening it, anything I open from that terminal will open on screen 1 (not surprising).

Sebastien Bacher (seb128) wrote :

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

Changed in gnome-panel (Ubuntu):
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Invalid

On Sun, 2009-03-22 at 22:28 +0000, Sebastien Bacher wrote:
> *** This bug is a duplicate of bug 282806 ***
> https://bugs.launchpad.net/bugs/282806
>
> Thanks for the bug report. This particular bug has already been
> reported, but feel free to report any other bugs you find.

Are you sure? I found bug 282806 but followed it to the upstream bug,
http://bugzilla.gnome.org/show_bug.cgi?id=555078 but that bug looked
specific to Nautilus and not gnome-panel. Notice comment #7 in the
gnome bug:

Fixed in trunk.

2009-03-18 Cosimo Cecchi <email address hidden>

        * src/nautilus-application.c: (open_window), (open_windows),
        (message_received_cb), (nautilus_application_startup):
        Spawn the Nautilus windows on the right scren instead of always
        using the default one (#555078).

Is a fix in src/nautilus-application.c really going to fix a similar
problem in gnome-panel? Does gnome-panel really get it's application
launching code from the nautilus code? Could be, I dunno.

Sebastien Bacher (seb128) wrote :

let's undup for them since I don't have the right number but I've read bugs about that before

Changed in gnome-panel (Ubuntu):
status: Invalid → New
LaChild (shafer-w2002) wrote :

In case this helps: Bugs 324065 and 344273 are considered dups of 282806 which really should be dups of this issue. It doesn't look like I can update that (which is probably a good thing... lol)

LaChild (shafer-w2002) wrote :

Opps guess only 344273 would be a dup of this one.

This occurs on my amd64 upgrade from 8.10 to 9.04.

Gnome panel 2.26.0

It pretty much negates any advantage in two monitors in Dualview.

I think its importance should be higher.

I'm affected too.

Changed in gnome-panel (Ubuntu):
status: New → Confirmed
Changed in gnome-panel (Ubuntu):
status: Confirmed → Triaged
Changed in gnome-panel:
status: Unknown → New
yakovlev (gregalex) wrote :

I've attached a hacked version of gnome-terminal that dumps some screen information to a file called "foo" in your home directory when run.

THIS IS NOT a secure version, DO NOT install the resulting hacked .deb.

However, if you compile gnome-terminal with this patch to src/terminal.c, you should be able to get some debug information.

I need someone experiencing the problem to run the resulting binary from a terminal on screen 1 and from a panel launcher on screen 1.

Hopefully we'll get different results which we can use to further debug the problem.

How to use:
Log into your home directory.

sudo apt-get build-dep gnome-terminal
*NOTE: NO SUDO BELOW HERE*
mkdir temp
cd temp
apt-get source gnome-terminal
cd gnome-terminal-2.26.0
cd src
patch terminal.c /path/to/gnome-terminal-fdfoo.patch
cd ..
dpkg-buildpackage -rfakeroot -b

This will build some packages in your temp directory... ignore these.

What you want to do now is run the resulting executable file:

temp/gnome-terminal-2.26.0/src/gnome-terminal

in as many ways as possible from screen 1 (and maybe some from screen 0.)

Then, please post the results (appended to file "~/foo") and where the terminal appeared here.

Thanks!

yakovlev (gregalex) wrote :

I've attached a hacked version of gnome-terminal that dumps some screen information to a file called "foo" in your home directory when run.

THIS IS NOT a secure version, DO NOT install the resulting hacked .deb.

However, if you compile gnome-terminal with this patch to src/terminal.c, you should be able to get some debug information.

I need someone experiencing the problem to run the resulting binary from a terminal on screen 1 and from a panel launcher on screen 1.

Hopefully we'll get different results which we can use to further debug the problem.

How to use:
Log into your home directory.

sudo apt-get build-dep gnome-terminal
*NOTE: NO SUDO BELOW HERE*
mkdir temp
cd temp
apt-get source gnome-terminal
cd gnome-terminal-2.26.0
cd src
patch terminal.c /path/to/gnome-terminal-fdfoo.patch
cd ..
dpkg-buildpackage -rfakeroot -b

This will build some packages in your temp directory... ignore these.

What you want to do now is run the resulting executable file:

temp/gnome-terminal-2.26.0/src/gnome-terminal

in as many ways as possible from screen 1 (and maybe some from screen 0.)

Then, please post the results (appended to file "~/foo") and where the terminal appeared here.

Thanks!

yakovlev (gregalex) wrote :

I've attached a hacked version of gnome-terminal that dumps some screen information to a file called "foo" in your home directory when run.

THIS IS NOT a secure version, DO NOT install the resulting hacked .deb.

However, if you compile gnome-terminal with this patch to src/terminal.c, you should be able to get some debug information.

I need someone experiencing the problem to run the resulting binary from a terminal on screen 1 and from a panel launcher on screen 1.

Hopefully we'll get different results which we can use to further debug the problem.

How to use:
Log into your home directory.

sudo apt-get build-dep gnome-terminal
*NOTE: NO SUDO BELOW HERE*
mkdir temp
cd temp
apt-get source gnome-terminal
cd gnome-terminal-2.26.0
cd src
patch terminal.c /path/to/gnome-terminal-fdfoo.patch
cd ..
dpkg-buildpackage -rfakeroot -b

This will build some packages in your temp directory... ignore these.

What you want to do now is run the resulting executable file:

temp/gnome-terminal-2.26.0/src/gnome-terminal

in as many ways as possible from screen 1 (and maybe some from screen 0.)

Then, please post the results (appended to file "~/foo") and where the terminal appeared here.

Thanks!

yakovlev (gregalex) wrote :

Sorry about that, didn't know that the comment took, it just wasn't showing me the bug screen.

LaChild (shafer-w2002) wrote :

Ok I tried to use the patch. There's one problem... In order to open the program on screen 1 I have to use a hack to get it to open onto that screen. Once the terminal is opened on the right screen calling the apps directly through this opens up on the correct terminal.

Also if you set the environment display variable "export DISPLAY=':0.1'" and call the programs from the command line they all open fine.

So long story short, you can not replicate the problem from the terminal. To get the info you're looking for I'd recommend hacking gnome-panel and output it's info instead.

Thanks for looking into it.

LaChild

yakovlev (gregalex) wrote :

I think you're missing the point.

Add a gnome-panel launcher (temporarily, of course) to screen 1 which launches the hacked gnome-terminal. Then use that to make it appear on the *wrong* screen. **What I most need the output of is a run where gnome-terminal shows up on the wrong screen.**

The other cases I would like (for comparison) are a run where gnome-terminal is launched in the same way from screen 0 and appears on screen 0, and a run where it is launched "correctly" on screen 1 (maybe via your hack.)

What I'm trying to do is figure out just where the bad terminal info is coming from, so that I work backwards and attack the problem from there.

In particular, I want to see if the environment that gnome-terminal is picking up is bad, or if the problem comes from something in the DBUS code ignoring the environment that is passed to it.

Thanks!

LaChild (shafer-w2002) wrote :

oops I did miss the point. Now that I know step-by-step what to do I'll get that for you shortly.

LaChild

LaChild (shafer-w2002) wrote :

Run from panel on screen :0.1

LaChild (shafer-w2002) wrote :

Run from panel on screen :0.0

LaChild (shafer-w2002) wrote :

Run from terminal on screen :0.0

LaChild (shafer-w2002) wrote :

Run from terminal on screen :0.1 -> default terminal opened on 0.1 used to open patched terminal with no environment changes

LaChild (shafer-w2002) wrote :

Run from terminal on :0.0 with modified environment settings. Command used: export DISPLAY=':0.1'; ./gnome-terminal

Let me know if you need anything else.

LaChild

yakovlev (gregalex) wrote :

Interesting...

I need one more thing... it will take a while for me to get a new patch file ready, if you can do this yourself, that would be great.

Basically, I need to add the following lines to the previous patch so that I have the value of the "DISPLAY" environment variable. I think some other users were using `bash -c executable` to get things working, which I don't understand why it worked.:

char *fdfoodisplay;
fdfoodisplay = getenv( "DISPLAY" );

fprintf(fdfoo, "DISPLAY Environment Variable is: \"%s\"\n", fdfoodisplay);

LaChild (shafer-w2002) wrote :

Patch Used

LaChild (shafer-w2002) wrote :

Run from panel on screen :0.1

LaChild (shafer-w2002) wrote :

Run from panel on screen :0.0

LaChild (shafer-w2002) wrote :

Run from terminal on screen :0.1 -> default terminal opened on 0.1 used to open patched terminal with no environment changes

LaChild (shafer-w2002) wrote :

Run from terminal on screen :0.0

LaChild (shafer-w2002) wrote :

Run from terminal on :0.0 with modified environment settings. Command used: export DISPLAY=':0.1'; ./gnome-terminal

hmm... Maybe I should have saved everyone the email notifiations by simply taring up these files into one post.

Sorry Guys,
LaChild

From gnome bugzilla:

Bug 580103 – Terminal starts on Display :0.0 when started on :0.1 in Dual screen conf
2009-04-24 11:03 UTC
http://bugzilla.gnome.org/show_bug.cgi?id=581502

Bug 581502 – Menu/panel items open on different screen
2009-05-05 17:48 UTC
http://bugzilla.gnome.org/show_bug.cgi?id=581502

Note: I have found one application launcher that launches in the correct screen, see Comment #4 at
http://bugzilla.gnome.org/show_bug.cgi?id=581502#c4

No apparent action has taken place with this bug.

yakovlev (gregalex) wrote :

Okay, now for a patched gnome-panel.

For this one, you'll need to install the gnome-panel and libpanel .debs. To get the old ones, recompile without the patch and reinstall the .debs. There also may be a way to force synaptic/apt-get to reinstall over the current ones, but I'm not sure what it is.

This test again puts data in ~/foo.

It outputs some information on startup, and other information when the application is launched.

This should tell us whether the bug is in gnome-panel or in the underlying gnome/GTK libraries. Right now I'm about 50/50 as to which I suspect.

Install the debs listed above and then log out and log back in. (I've tested on my single display machine, so you should be okay as far as hosing your system, though this may leak memory.)

Then run an application on screen 1 that shows up on the wrong screen (screen 0), and send the output.

Thanks!

LaChild (shafer-w2002) wrote :

Ok, here's the output of ~/foo when launching an app from screen 0.1 and the app shows up incorrectly on 0.0

----------------------------------------------------------------------
Adding Screen
Screen number: 0
screen name: :0.0
Adding Screen
Screen number: 1
screen name: :0.1
Launching URI
screen: :0.1
----------------------------------------------------------------------

Here's the output from ~/f00 when launching an app from 0.0
----------------------------------------------------------------------
Adding Screen
Screen number: 0
screen name: :0.0
Adding Screen
Screen number: 1
screen name: :0.1
Launching URI
screen: :0.0
----------------------------------------------------------------------

Hope this helps
LaChild

yakovlev (gregalex) wrote :

Actually, this helps a lot.

What this tells us is that this is actually a bug in glib2.0 function g_app_info_launch_uris().

The bug occurs when this is launched with a context including a screen with gdk_screen_make_display_name(screen)=":0.1" but the parent process has DISPLAY=":0.0"

Here is a snippet of the relevent code sequence in gnome-panel:

...
        gdk_app_launch_context_set_screen (context, screen);
        gdk_app_launch_context_set_timestamp (context, timestamp);

        local_error = NULL;
        retval = g_app_info_launch_uris (appinfo, uris,
                                         (GAppLaunchContext *) context,
...

yakovlev (gregalex) wrote :

Okay, I think I found the problem.

I think this is a bug in the "is_env()" function in glib2.0 file gdesktopappinfo.c.

I will be providing a patch shortly once I have tested it locally.

Basically what's happening is the environment passed to the spawned process has 2 "DISPLAY=" lines, one with "DISPLAY=:0.0" and another with "DISPLAY=:0.1".

The is_env() function as written is CLEARLY wrong.

Untested version of the new fix:

/* '=' is the new '\0'.
 * DO NOT CALL unless at least one string ends with '='
 */
static gboolean
is_env (const char *a,
 const char *b)
{
  while (*a == *b)
  {
    if (*a == '=' && *b == 0) /* return true if at end of b and a is on =. */
      return TRUE;

    if (*a == '=' || *a == 0 || *b == 0) /* otherwise return if at the end of either string. */
      return FALSE;

    a++;
    b++;
  }

  return FALSE;
}

The old version would bomb out with FALSE if *a==0 || *b==0, but the actual correct TRUE case (shown above) is (*a == '=' and *b == 0).

yakovlev (gregalex) wrote :

Nope, above doesn't work, this should:

static gboolean
is_env (const char *a,
 const char *b)
{
  while (*a == *b)
  {
    if (*a == 0 || *b == 0 || *b == '=') /* cover naughty equals usage */
      return FALSE;

    a++;
    b++;
  }

  if (*a == '=' && *b == 0)
    return TRUE;

  return FALSE;
}

yakovlev (gregalex) wrote :

Here is a patch with both the fix and debugging information.

Use this only if the later patch doesn't work.

I don't know if you need libglib or libgio-fam, so install both .debs.

yakovlev (gregalex) wrote :

And here is the patch without debugging information.

TRY THIS FIRST.

Again, this is a bug in glib, NOT gnome-panel.

Sebastien Bacher (seb128) wrote :

could you add the change to the upstream bug?

yakovlev (gregalex) wrote :

I added the patch to 580103. However, I don't know the right way to get that bug moved from the gnome-panel team to the glib team.

Also, has anybody tried out the patch and made sure it fixes the problem? I'm pretty confident it does, as I was able to observe bad behavior on my single-head machine that the patch corrected, but it would be preferrable for someone experiencing the problem to confirm that.

(I'm avoiding upgrading due exclusively to THIS BUG. As such, I did all the design work in a VM.)

LaChild (shafer-w2002) wrote :

The patched fixed it for me.

Thanks for all the hard work, now we just need to get it patched upstream in time for Karmic Koala! :D

On Mon, 2009-06-01 at 18:56 +0000, LaChild wrote:
> The patched fixed it for me.

Great.

> Thanks for all the hard work, now we just need to get it patched
> upstream in time for Karmic Koala! :D

Uhm. And fixed ASAP for Jaunty. That's what most of the leading edge
Ubuntu userbase are all using. Jumping on the Karmic bleeding edge is
not a workable solution for the general masses suffering this bug.

Changed in glib:
importance: Undecided → Unknown
status: New → Unknown

Patch fixes it for me too.

A Blaylock (april-deirdre) wrote :

I am having trouble propagating the fix into my system.

I downloaded glib-2.20.1.tar.gz onto my Desktop.
Uncompressed it.
Patched it.
Typed:
connfigure
make install

Everything seemed to work, but I don't know how to replace the version I have with the new one.
(Its probably simple, but I am not use to compiling stuff for linux)

A good set of steps would be very helpful!

April.

Launchpad is not a help forum. Please do not post troubleshooting questions on bugs.

This page may help you: http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/. For any further questions please visit http://ubuntuforums.org/.

A Blaylock (april-deirdre) wrote :

No Problem.

I did not realize that configure needed to be seeded with a prefix.

This bug is now fixed on my system.
It was very frustrating for a dual monitor user.
I am surprised that it was rated low importance.

Changed in glib:
status: Unknown → New

I applied the patch and got mixed results.

Some launches opened in the correct screen while other did not.

Example Firefox open in the correct screen while System/Shutdown… does not.

I am using Ubuntu 8.10 amd64.

yakovlev (gregalex) wrote :

Ubuntu 8.10 shouldn't have this bug, unless glib or gnome-panel was updated recently (in which case, shame on the developers for breaking a working release.)

The patch only fixes application launchers, which is the only thing anyone mentioned having problems with. Gnome-panel internals are a whole different animal, and if they're showing up on the wrong screen, will need an independent fix.

Alen (cshadow) wrote :

Intrepid is not so bug free...
Does this bug cover drag&drop from the menu to the desktop?
Because when i do that on the screen 1, the launcher appears on screen 0 (8.04, 32-bit).
Also, right click-->Properties on the launcher on panel opens properties window on the wrong screen (0).
Opening anything from 'Places' menu opens nautilus on the screen 0.
BTW, I also noticed the shutdown bug.
In 8.04 I used to open movies on my TV (screen 1) via nautilus, in 8.10 I have to open player and then it opens associated file types on that screen wherever I click on the movie.
Until now I didn't figure out a way to open nautilus on screen 1, only thing that works is opening via terminal.
I only use second screen for watching movies, but it could be quite frustrating for someone who wants to do some work involving two screens.
I have dual boot with 9.04 64-bit, would have to try this patch later on it. Currently this installation is quite unusable because some other bugs (user switching crashing X)...
Gnome devs definitely broke something in the last 2 releases of gnome. Never had any problems with 2 screens on 7.10, but starting from hardy strange things are hapening :-)

yakovlev (gregalex) wrote :

The Places bug in 8.10 is a different nautilus bug. It is documented in launchpad bug 282806, referenced above. My guess is that bug also covers the drag&drop problem.

I'm not sure about the shutdown or properties bugs. I don't know how those are launched.

I agree that things for dual-screen users seem to be getting worse, not better. I suspect XRandR and to a lesser extent Xinerama are responsible for this breakage.

Sebastien Bacher (seb128) wrote :

the bug has been fixed upstream now

affects: gnome-panel (Ubuntu) → glib2.0 (Ubuntu)
Changed in glib2.0 (Ubuntu):
status: Triaged → Fix Committed

On Thu, 2009-06-11 at 07:50 +0000, Sebastien Bacher wrote:
> the bug has been fixed upstream now
>

Excellent. Will that fix be backported to Jaunty, seeing how that's the
release we are all using currently?

Now I am confused.

I did not have this bug in 8.04 and I do have it in 8.10.

I verified the code in the patch before applying it.

If this only refers to 8.04, do I need to open a new bug?

8.10 amd64

I am still confused.

That should read

"I did not have this bug in 8.10 and I do have it in 9.04"

Changed in glib:
importance: Unknown → Undecided
status: New → Fix Released
importance: Undecided → Unknown
status: Fix Released → Unknown

Just to inform, this bug happens on Fedora 11 too....

I think it is Gnome related. I fix it moving from Gnome to XFCE.

----
Leandro Tavares Carneiro
Analista de Suporte Linux/Unix

On Mon, Jun 15, 2009 at 8:27 PM, Nexos <email address hidden> wrote:

> ** Changed in: glib
> Importance: Unknown => Undecided
>
> ** Changed in: glib
> Remote watch: GNOME Bug Tracker #580103 => None
>
> ** Changed in: glib
> Status: New => Fix Released
>
> ** Changed in: glib
> Importance: Undecided => Unknown
>
> ** Changed in: glib
> Status: Fix Released => Unknown
>
> ** Changed in: glib
> Remote watch: None => GNOME Bug Tracker #580103
>
> ** Bug watch added: GNOME Bug Tracker #580103
> http://bugzilla.gnome.org/show_bug.cgi?id=580103
>
> --
> menu items selected from screen 1 open on screen 0
> https://bugs.launchpad.net/bugs/346964
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

andrewmcnnz (andrew-scoop) wrote :

I'm having this problem also. Running Jaunty, all up to date.

I notice that gnome-panel is being started up with arguments as follows:

<pre>
gnome-panel --sm-config-prefix /gnome-panel-svkHHa/ --sm-client-id 103a4ad18dff7eaf70124528181440707300000036800023 --screen 0
</pre>

notice that "--screen 0" bit. Where does it come from?

I tried to kill the gnome-panel process but it got re-created instantly, presumably by the session manager.
I then tried:

<pre>
gnome-panel --replace --sm-config-prefix /gnome-panel-svkHHa/ --sm-client-id 103a4ad18dff7eaf70124528181440707300000036800023
</pre>

which I did on my second screen. Now everything opens on screen 2 which is not an improvement, but maybe it's useful information.

Is it possible somehow to run two gnome-panel processes, one for each screen, with different --screen values?

Ng Oon-Ee (ngoonee) wrote :

Just to inform all that this has been fixed in latest glibc, I'm on Arch Linux and we've already gotten the fix. For those using Ubuntu 9.04, I doubt its coming your way due to the freeze policy Ubuntu has on its releases (I think only security-related patches are released).

Anyway, the problem HAS been solved as shown in the comments above. I suppose you could always recompile your own glibc if you don't want to try out other distros/DMs/testing versions.

Changed in glib:
status: Unknown → Fix Released
Changed in gnome-panel:
status: New → Fix Released
Sebastien Bacher (seb128) wrote :

the new version is in karmic now

Changed in glib2.0 (Ubuntu):
status: Fix Committed → Fix Released
Kidaf (rafa.luft) wrote :

Any way I can get the new version on Jaunty, without having to recompile the package?

Step by step instructions used to correct this problem are given in the answer to the following question:

https://answers.launchpad.net/ubuntu/+source/glib2.0/+question/77380

TJ (tj) wrote :

I've repackaged my previous Jaunty libglibc package to use yakovlev's patch since it seems to perform better than my original upstream-backport patch (which came from grossly refactored code).

In particular, yakolev's patch doesn't cause the launching of external applications to fail (e.g. double-click of a .deb inside a .tar.gz in file-roller, or a downloaded file on Chromium-browser) as the previous patch did.

Add my PPA (https://launchpad.net/~intuitivenipple/+archive/ppa) and then update the "libglib2.0-0" packages.

sudo apt-get install libglib2.0-0

If you previously used my PPA build you'll need to remove all the packages it installed and replace them. The version of the current Ubuntu update is less than the version I used with that package so you'll need to explicitly specify the version:

sudo apt-get install libglib2.0-0=2.20.1-0ubuntu2.2~tj~ppa1j libglib2.0-data=2.20.1-0ubuntu2.2~tj~ppa1j

If you have applied TJ's prior patch, step-by-step have been added at

https://answers.launchpad.net/ubuntu/+source/glib2.0/+question/77380

to update to the latest patch using Synaptic.

Changed in glib:
importance: Unknown → Medium
Changed in gnome-panel:
importance: Unknown → Medium

Hello:
I have good news for you. Last week, I have Order china 22
Products:<Philips 52PFL9703D/10 LCD TV 52 >
I have completed bank transfer payment.
I've received the item today this website:www.SLEUBO0.com
It's amazing! The item is original, brand new and has high quality,
but it's much cheaper. I'm pleased to share this good news with you!
I believe you will find what you want there and have an good experience
on shopping from them.
Regards!

mlnjnlkj8jio....妙

Jasper Frumau (jfrumau) wrote :

Can someone take care of this previous spam post(er)?

Jasper Frumau (jfrumau) wrote :

And another spam comment added just before mine. Can somebody please do something about these fake users?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.