xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#636 closed defect (fixed)

Pidgin main window does not show up

Reported by: Eric Blade Owned by: fladnag
Priority: minor Milestone: 0.16
Component: core Version: trunk
Keywords: Cc:

Description

Start pidgin from Win-Switch menu, it starts up and then only the chat windows show up

Attachments (6)

pidgin-bug.zip (26.7 KB) - added by Eric Blade 6 years ago.
pidgin.png (123.7 KB) - added by Antoine Martin 6 years ago.
shows pidgin running through xpra
client.log (174.0 KB) - added by fladnag 5 years ago.
reopen - client log
reopen - bug pidgin.zip (28.7 KB) - added by fladnag 5 years ago.
actions + client log + server log
pidgin-win7-jessie.png (347.8 KB) - added by Antoine Martin 5 years ago.
pidgin running from a win7 client on a jessie server
20151208.logs.and.screens.zip (412.0 KB) - added by fladnag 5 years ago.

Download all attachments as: .zip

Change History (31)

comment:1 Changed 6 years ago by Antoine Martin

Component: androidcore
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

Please include more information:

  • xpra versions
  • distro, pidgin version
  • xpra info output

etc

comment:2 Changed 6 years ago by Eric Blade

Client is Windows 8.1, server is Ubuntu 14.04, using Xpra 0.14.0 on both. Not unique to 0.14.0, though, has been happening for some time, maybe as long as I've been using Xpra, not sure.

Pidgin is .. 2.10.9

Last edited 6 years ago by Eric Blade (previous) (diff)

Changed 6 years ago by Eric Blade

Attachment: pidgin-bug.zip added

comment:3 Changed 6 years ago by Antoine Martin

Keywords: ubuntu added
Milestone: 0.15
Priority: majorminor

First thing, you're using Ubuntu and Xvfb but your server config (/etc/xpra/xpra.conf) file has the default max resolution set to 3940x2560.
Bump it to 5760 as per r7309 or even use something close to your resolution of 4890x1680 if you can find one that Xvfb accepts if that's the maximum size you will ever need. (note: wiki/Xdummy is broken on Ubuntu..)

That's not the cause of this particular problem, but it would definitely prevent you from interacting with any xpra windows you would place on the rightmost monitor.

Pidgin works fine with my Fedora server/client, or with Windows and OSX clients.
The real bug seems to be that the tray forwarding is completely broken on Ubuntu for both clients and servers. This appindicator thing is a shocking disaster. It doesn't matter how many times I try to fix this awful mess that Ubuntu has created, it will break again and again - guaranteed. See r4083, #406, #43 and more.

I'll try to take a look, but I am just tired of fixing Ubuntu bugs, so don't hold your breath. You would be better off using a better distro.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 years ago by Eric Blade

huh. i might've accidentally told apt-get to keep my old conf, but i thought i told it to update to the new one included in the package.

I wonder if somehow the window is ending up off screen somewhere. I've had a problem with another app that apparently restores it's last window position, when I try to use it on the local machine, which only has a single display, the window never shows up because it's off a couple thousand pixels to the left. Could be Pidgin's storing it's main window coords somewhere and they aren't visible. I'll check into the Pidgin conf and see if there's something there.

My tray forwarding seems to be working in one direction -- I can see the Pidgin tray on Windows no problem, hovering it works (although the hover message shows up half a screen away from the tray), but clicking on it doesn't.

Sadly, Ubuntu is my supported distribution for work :|

comment:5 Changed 6 years ago by Eric Blade

quick update: deleting all position information in the .purple/prefs.xml returned the chat/im window to the upper left hand corner, but the main/buddy list window is still not coming up anywhere.

Click xpra tray -> Xpra Info -> Statistics shows "Windows: Regular 1, Transient 0, Trays 1, OpenGL 1" .. If I open a dialog window such as Conversation->New, it bumps to "Windows: Regular 2, Transient 0, Trays 1, OpenGL 2" .. so it looks like the window is just not getting picked up

comment:6 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to Eric Blade
Status: assignednew

Please post xpra info, amongst other things it should tell us where the windows are located and their size.

comment:7 Changed 6 years ago by Eric Blade

bug report from xpra tray is attached

comment:8 Changed 6 years ago by Antoine Martin

Right, my bad, in the zip file.

Can you reconcile these dimensions with what you are seeing or expecting?

window[1].dimensions             : (800, 651)
window[3].dimensions             : (16, 16)
window[4].dimensions             : (236, 36)

The 16x16 window is probably a system tray.
There are a number of properties missing, like the window position... which I am looking into.

comment:9 Changed 6 years ago by Eric Blade

No idea what the last one is. window[1] looks like the open chat window. window[3] is most likely the tray as you suggest. window[4] doesn't look like anything i see on screen, and as far as i can tell, i only have two visible windows. 236x36 seems more like a tool-tip than an actual window, though.

Last edited 6 years ago by Antoine Martin (previous) (diff)

Changed 6 years ago by Antoine Martin

Attachment: pidgin.png added

shows pidgin running through xpra

comment:10 Changed 6 years ago by Antoine Martin

As can be seen in the screenshot above, I can run pidgin through xpra and I think that everything looks normal (though I never actually use pidgin myself).
You can see 3 windows there, and also the tray icon.

What is actually missing?

comment:11 Changed 6 years ago by Eric Blade

I never receive the main window. At startup, it is setup to login to several IRC servers and IM systems, and I receive the chat window and the tray icon, but never the main window.

Next time I load it, I'll try to remember to clear my pidgin config, and see if that gets it going.

comment:12 Changed 6 years ago by Antoine Martin

Does the tray icon respond to clicks?

It is possible that the main window starts hidden and that you need to interact with the tray icon to get it to show up. The tray is an absolute nightmare on Ubuntu - so that could be the cause. Note: I tested on Fedora.

Posting the server and client debug log with -d window,tray could help (as short as you can make it).

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:13 Changed 6 years ago by Antoine Martin

Resolution: needinfo
Status: newclosed

Not heard back, closing.

See also #406

Last edited 6 years ago by Antoine Martin (previous) (diff)

Changed 5 years ago by fladnag

Attachment: client.log added

reopen - client log

comment:14 Changed 5 years ago by fladnag

Keywords: ubuntu removed
Milestone: 0.15future
Resolution: needinfo
Status: closedreopened

I have the same problem with :
server : Debian Jessie xpra/now 0.16.0-1
client : windows 7 xpra 0.16.0-r11359

I tried to reset pidgin with remove .purple folder without success.

Xpra only show pidgin tray icon, but I can't interact with it.

Added "reopen - bug pidgin.zip" in attachments with these actions (forget "client.log" attachment)

  • move mouse over pidgin icon
  • left clic on pidgin icon
  • right clic on pidgin icon
  • 2 left clic on pidgin icon

All actions have the same result : only the pidgin tooltip is displayed, but not the main window

Last edited 5 years ago by fladnag (previous) (diff)

Changed 5 years ago by fladnag

Attachment: reopen - bug pidgin.zip added

actions + client log + server log

Changed 5 years ago by Antoine Martin

Attachment: pidgin-win7-jessie.png added

pidgin running from a win7 client on a jessie server

comment:15 Changed 5 years ago by Antoine Martin

Owner: changed from Eric Blade to fladnag
Status: reopenednew

The screenshot above shows pidgin running just fine on a win7 client from a fully up to date jessie server. (both running the latest beta builds)

I can click on the tray icon and get the pidgin "buddy list" window to show up / minimize.
This works just as well if I tell win7 to hide the systray and I then have to popup the small systray window to click on it.
If something is not working right, then I don't know what it is.

comment:16 Changed 5 years ago by Antoine Martin

Looking at the log files, the systray icon clicks are being registered and sent to the server, ie:

OnTaskbarNotify(7734152,1044,0,516) button(s) lookup: [(3, 1)], callback=<function tray_click at 0x0501D870>
18:09:14,165 tray_click(3, 1, 0) tray=ClientTray(88)
button_packet=['button-action', 88, 3, 1, (2727, 1056), ['mod2']]

And then I see your tooltip window appearing:

Discovered new override-redirect window: 0xa0008b (tray=None)
new window 0xa0008b

The client then receives this new window packet:

process_new_common: [208, 1463, 1061, 121, 19, \
    {'fullscreen': False, 'has-alpha': True, 'xid': '0xa00a9e', \
     'title': 'Pidgin', 'client-machine': 'HOST', 'pid': 29767, \
     'group-leader-xid': 10485761, 'sticky': False, 'below': False, \
     'window-type': ('TOOLTIP',), 'command': '', 'above': False, \
     'maximized': False, 'skip-taskbar': False, \
     'class-instance': ('Pidgin', 'Pidgin'), 'override-redirect': True, \
     'skip-pager': False}], \
      metadata=..., OR=True

And it gets destroyed shortly after (because you move the mouse away presumably).

The bug report data does not include "xpra info" so there is no way for me to tell if the systray window really is where it should be, which is an area including the click location (2727, 1056).

Does this only occur with the multiple monitor setup?
How many monitors are needed and with what layout? Is the primary one on the left? (we've had issues with this recently)

comment:17 Changed 5 years ago by Antoine Martin

Is this information correct?

DISPLAY1 1920x1080 at 1280x0 (677x381 mm - DPI: 72x72) workarea: 1920x1040
DISPLAY2 1280x1024 at 3200x0 (452x361 mm - DPI: 71x72) workarea: 1280x1024
DISPLAY5 1280x1024 (452x361 mm - DPI: 71x72) workarea: 1280x1024

Your secondary displays are slightly shorter than the first one.
But the primary one is the taller one (DISPLAY1) and it is in the middle of the other two, right?
Can you include a screenshot of your full windows desktop area? (does not need to be at full resolution, just to see the geometry and layout)

comment:18 Changed 5 years ago by fladnag

yes, the display information is correct.

the left monitor is a 19" and the right monitor is a 17" (but at same resolution), both 4/3

the primary central monitor is more than that (21 or 24, don't remember), 16/9

I cannot test today but I will attach more info tomorrow (xpra info + screenshots + test with only one monitor + test with pidgin and "Xming/classic remote display" without xpra for assert the issue is not on pidgin side)

Last edited 5 years ago by fladnag (previous) (diff)

comment:19 Changed 5 years ago by fladnag

So... I have done more tests and I think I have understand what happened :

  • The same test with Xming and classic remote display have the same result
  • The same test with only one monitor works well ! Pidgin main windows show up normally
  • The same test with tree monitor, but all additionnal monitors to the right of the main monitor works too !
  • With a monitor to the left of the main, the toolip has an offset of the resolution of the left monitor

It's a "core" issue because Xming has the same issue, but you can probably fix it with setting an offset for handle left monitors (see screenshot for that)

It's not a specific pidgin issue, but clic on tray icon is the only way to display a minimized pidgin window ;o)

Changed 5 years ago by fladnag

comment:20 Changed 5 years ago by Eric Blade

"With a monitor to the left of the main, the toolip has an offset of the resolution of the left monitor"

... this sounds like an accurate summary of almost all of the multi-monitor problems that I've ever run into, in this software, and others.

comment:21 Changed 5 years ago by Antoine Martin

Milestone: future0.16
Owner: changed from fladnag to Antoine Martin
Status: newassigned

Got it, this only happens if the primary monitor is not the first one.
GTK cooks the coordinates so that they're always positive, but the win32 API will quite happily return negative values to make sure the primary monitor stays at (0, 0). We use the latter for the systray.. and this breaks.

comment:22 Changed 5 years ago by Antoine Martin

This should be fixed in r11389 - works for me with vlc.
Will backport.

comment:23 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to fladnag
Status: assignednew

@eblade / @fladnag: I've uploaded a new beta win32 build, does that fix things for you?

comment:24 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Applied to older branches in r11391. Closing, feel free to re-open if you still have issues.

comment:25 Changed 5 years ago by fladnag

r11392 works ;o) thank you very much

Note: See TracTickets for help on using tickets.