X2Go Bug report logs - #883
Window Decorations gone when resuming on smaller screen

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Stefan Baur <X2Go-ML-1@baur-itcs.de>

To: submit@bugs.x2go.org

Subject: Window Decorations gone when resuming on smaller screen

Date: Thu, 28 May 2015 21:38:40 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

package: x2goclient

I'm assigning this to x2goclient, as this is where I'm noticing the
issue.  Feel free to reassign to nx-libs or vcxsrv in case the root
cause is in one of these.

Situation:

Start x2goclient.exe on a Windows machine that has a native screen
resolution of, say, 1024x768.

In X2GoClient, configure a PubApp session.

Run Firefox/Iceweasel and resize the application window so it almost
fills the entire screen (do *not* maximize).

Close Firefox/Iceweasel.  Open it again to verify that the window has
the same size as before.  Close it again.

Terminate or suspend the session.  Close X2GoClient.

Now, change the screen resolution to 800x600.
Start x2goclient.exe again, resume your session, or start a new
session and run Firefox/Iceweasel again.

Expected result:
Firefox/Iceweasel window gets resized to maximum available space, with
window decorations.

Actual result:
Firefox/Iceweasel goes fullscreen and lacks window decorations, so it
cannot be resized or moved out of the way.

This does not happen on Linux, where the native X server is used, nor
on OS X, even though OS X uses a separate X Server.

It only occurs on Windows.

It might have to do with the X server we ship, however, trying
XWin.exe from Cygwin gave even worse results.

I'm kind of stumped as to what the reason is and would love to assist
the Devs in debugging and testing.

- -Stefan

- -- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZ27AAAoJEG7d9BjNvlEZnI8IAJMFJtPqYD06Qx6gt54SFaEr
PYNS/rdYcdpao+zGdJTdzxz69TeUkCNysouWCkj4HI5dVzbGkkfnUz7R1ZOnMAng
23hL4F0Zr/4rbvlty2QGNgzngvBkKOkPqUeOvrrZvx4eoq63WHzvPr0Lgf6gRllu
KUFRDzS+lZfBycSh+xlcVZN6uxOY3tjSU4eV42jaUnmCQgOIx8V/EyxyUC0en/TV
src/lKPAppyaiGJ9on7JuFNd9ZVsO4ApUaoU8IUzF42ExRl7WM3+GI5KS3kBO5rd
rKV8kuTCujhH+lFjwD9cLKFaEfXk0bUnjtCiOnX9wtu6XVx+zOtwAeYlCoGTjBE=
=e4dR
-----END PGP SIGNATURE-----

Message #10 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: 883@bugs.x2go.org

Subject: Regression in VcXsrv

Date: Mon, 22 Jun 2015 06:21:27 +0200

As I discussed with Stefan & Mihai at X2Go Gathering 2015:
1. VcXsrv 1.1.2 is not affected, so this appears to be a regression in VcXsrv.
2. It is safe to assume that it is a regression in the multiwindow
code in VcXsrv (and in other X servers for Windows),
xorg-server/hw/xwin/winmultiwindow*
3. We should bisect released versions/builds of VcXsrv until we find
which version was 1st affected, and then compare their source code in
the aforementioned area to find what change probably caused the
regression. If need be, we will build old git revisions in between
those released versions.
4. I have started doing #3 and recording the results in this spreadsheet:
https://docs.google.com/spreadsheets/d/1cVe7UELbJqLEFsE20v1-weUWyW-pQByTAkeUOIPs-uw/edit?usp=sharing

-Mike#2

Message #15 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: 883@bugs.x2go.org

Subject: Can be fixed by reverting winmultiwindow.patch

Date: Mon, 22 Jun 2015 09:18:28 +0200

I determined that this bug can be fixed by reverting Alex's
winmultiwindow.patch to VcXsrv, which was a workaround for #594 and
has been included in both 1.15.2.x and 1.17.0.0-x of the VcXsrv
X2Go/Arctica builds.

I also created a bug report & branch in the GitHub project for VcXsrv
(X2Go/Arctica builds):
https://github.com/ArcticaProject/vcxsrv/issues/3
https://github.com/ArcticaProject/vcxsrv/commits/bugfix/bug3

I will be releasing X2Go Client for Windows 4.0.4.0-2015.06.22 with
the OpenSSL updates. When I do, I will offer an alternate build with
VcXsrv with winmultiwindow.patch reverted. This will be a workaround
until we make a change to VcXsrv that fixes both #594 and #883

-Mike#2

Message #20 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Michael DePaulo <mikedep333@gmail.com>, 883@bugs.x2go.org

Cc: o.schneyder@phoca-gmbh.de

Subject: Re: [X2Go-Dev] Bug#883: Can be fixed by reverting winmultiwindow.patch

Date: Tue, 23 Jun 2015 10:51:15 +0000

[Message part 1 (text/plain, inline)]

Hi Michael, hi Alex,

On  Mo 22 Jun 2015 09:18:28 CEST, Michael DePaulo wrote:

> I determined that this bug can be fixed by reverting Alex's
> winmultiwindow.patch to VcXsrv, which was a workaround for #594 and
> has been included in both 1.15.2.x and 1.17.0.0-x of the VcXsrv
> X2Go/Arctica builds.
>
> I also created a bug report & branch in the GitHub project for VcXsrv
> (X2Go/Arctica builds):
> https://github.com/ArcticaProject/vcxsrv/issues/3
> https://github.com/ArcticaProject/vcxsrv/commits/bugfix/bug3
>
> I will be releasing X2Go Client for Windows 4.0.4.0-2015.06.22 with
> the OpenSSL updates. When I do, I will offer an alternate build with
> VcXsrv with winmultiwindow.patch reverted. This will be a workaround
> until we make a change to VcXsrv that fixes both #594 and #883

@Alex: Before Michael starts diving into your patch for fixing #594,  
do you see any chance for taking a look at the regression described in  
#883 introduced by your patch? Any feedback on a possible solution  
would be highly welcome.

Thanks,
Mike
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #25 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>

To: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>, Michael DePaulo <mikedep333@gmail.com>, 883@bugs.x2go.org

Cc: o.schneyder@phoca-gmbh.de

Subject: Re: [X2Go-Dev] Bug#883: Can be fixed by reverting winmultiwindow.patch

Date: Tue, 23 Jun 2015 21:22:41 +0200

[Message part 1 (text/plain, inline)]

Hi,
I'll look on it on Thursday-Monday,

regards,
Alex

Am 23.06.2015 um 12:51 schrieb Mike Gabriel:
> Hi Michael, hi Alex,
> 
> On  Mo 22 Jun 2015 09:18:28 CEST, Michael DePaulo wrote:
> 
>> I determined that this bug can be fixed by reverting Alex's
>> winmultiwindow.patch to VcXsrv, which was a workaround for #594 and
>> has been included in both 1.15.2.x and 1.17.0.0-x of the VcXsrv
>> X2Go/Arctica builds.
>>
>> I also created a bug report & branch in the GitHub project for VcXsrv
>> (X2Go/Arctica builds):
>> https://github.com/ArcticaProject/vcxsrv/issues/3
>> https://github.com/ArcticaProject/vcxsrv/commits/bugfix/bug3
>>
>> I will be releasing X2Go Client for Windows 4.0.4.0-2015.06.22 with
>> the OpenSSL updates. When I do, I will offer an alternate build with
>> VcXsrv with winmultiwindow.patch reverted. This will be a workaround
>> until we make a change to VcXsrv that fixes both #594 and #883
> 
> @Alex: Before Michael starts diving into your patch for fixing #594, do
> you see any chance for taking a look at the regression described in #883
> introduced by your patch? Any feedback on a possible solution would be
> highly welcome.
> 
> Thanks,
> Mike


-- 
-----------------------------------------------------------
Oleksandr Shneyder        | Email: o.shneyder@phoca-gmbh.de
phoca GmbH                | Tel. : 0911 - 14870374 0
Ludwig-Feuerbach-str. 18  | Fax. : 0911 - 14870374 9
D-90489 Nürnberg          | Mobil: 0163 - 49 64 461

Geschäftsführung:
Dipl.-Inf. Oleksandr Shneyder

Amtsgericht München | http://www.phoca-gmbh.de
HRB 196 658         | http://www.x2go.org
USt-IdNr.: DE281977973
-----------------------------------------------------------

[signature.asc (application/pgp-signature, attachment)]

Message #30 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Mihai Moldovan <ionic@ionic.de>

To: Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>, 883@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#883: Bug#883: Can be fixed by reverting winmultiwindow.patch

Date: Wed, 24 Jun 2015 04:04:43 +0200

[Message part 1 (text/plain, inline)]

On 23.06.2015 09:22 PM, Oleksandr Shneyder wrote:
> I'll look on it on Thursday-Monday,

I've had a look myself and played around with it, assisted by Mike#2.

I don't see any benefit in applying this patch and suggest dropping it.

As far as I've gathered, it's supposed to create a "fake" fullscreen window by
removing the borders and title bar IFF the window extents are greater or equal
the monitor's size, with "monitor" being the monitor that holds most of the
window's contents.


It doesn't make sense to do something like this in multiwindow mode. It *does*
make sense to do something like this in fullscreen mode, but the patch targets
multiwindow mode.

For this mode, it's plain wrong and only causing trouble. You can't fix it
either, because you're missing a crucial bit of information: when *do* you want
to have a "fake" fullscreen window?


Why did you write the original patch exactly? What was the use case that this
patch fixed?



Mihai

[signature.asc (application/pgp-signature, attachment)]

Message #35 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>

Cc: Michael DePaulo <mikedep333@gmail.com>, 883@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#883: Can be fixed by reverting winmultiwindow.patch

Date: Wed, 24 Jun 2015 08:57:49 +0000

[Message part 1 (text/plain, inline)]

Hi Alex,

On  Di 23 Jun 2015 21:22:41 CEST, Oleksandr Shneyder wrote:

> Hi,
> I'll look on it on Thursday-Monday,

Thanks!

My suggestion would be to drop that patch and try-out the  
-multimonitors and the -screen options of VcXsrv instead (as also  
proposed by Ionic and mikedep333 on IRC):

"""
-[no]multimonitors or -[no]multiplemonitors
Use the entire virtual screen if multiple
monitors are present.

[...]

-screen scr_num [width height [x y] | [[WxH[+X+Y]][@m]] ]
Enable screen scr_num and optionally specify a width and
height and initial position for that screen. Additionally
a monitor number can be specified to start the server on,
at which point, all coordinates become relative to that
monitor. Examples:
-screen 0 800x600+100+100@2 ; 2nd monitor offset 100,100 size 800x600
-screen 0 1024x768@3 ; 3rd monitor size 1024x768
-screen 0 @1 ; on 1st monitor using its full resolution (the default)
"""

Greets,
Mike
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #40 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: 883@bugs.x2go.org

Subject: I will try Mike#1's suggestions, and I released the test build

Date: Thu, 25 Jun 2015 23:14:28 -0400

Hi Mike#1,

I will try your suggestions.

Also, everyone,

I just released X2Go Client for Windows 4.0.4.0-2015.06.24 instead of
4.0.4.0-2015.06.22 (because I did the build 1.5 days later.)
The alternate build with the test fix (reverting the
winmultiwindow.patch) is available:
http://code.x2go.org/releases/binary-win32/x2goclient/releases/4.0.4.0-2015.06.24/non-default-builds/x2goclient-4.0.4.0-2015.06.24-bug883test1-setup.exe

-Mike#2

Message #45 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>

To: Mihai Moldovan <ionic@ionic.de>, 883@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#883: Bug#883: Can be fixed by reverting winmultiwindow.patch

Date: Mon, 29 Jun 2015 11:36:19 +0200

[Message part 1 (text/plain, inline)]

Hello,

I'll try to explain why I wrote this patch. In x2go client you have
possibility to run x2go session in "full screen" mode on only one of
physical displays. It has nothing to do with xinerama. It is very useful
if you have a client with several monitors and you want to have the
native session on one monitor and  full screen remote session on second
monitor. It's also not a full screen mode, because you are using only a
part of virtual display, so you are not running a vcxsrv in full screen
mode. This scenario widely used in enterprise environments.

To create a full screen window on only one physical display you need to
 maximize the window on this display and remove the window decorations.
Unfortunately on some setups it was not possible to maximize an
X-window. As soon as you tried it, vcsrv resized a window with a size
that was bigger then physical display and reseted a window decorations.
After some investigation I figured out that it's only happening on the
displays with negative coordinates, for example if a secondary display
is left of or on the top of primary display. So I assumed that vcxsrv
doesn't work properly with negative coordinates. Unfortunately I didn't
manage to find a bug in vcxsrv, so I wrote a workaround that checking if
the windows size is bigger than a physical display and in this case
resizing a window on a screen size. Usually it is no ways to create a
windows that are bigger then a physical display, so that workaround
worked well. Unfortunately in the case described in this bug report,
nxagent creating window that is bigger then screen size, because screen
was resized. This is why a firefox or whatever window will be maximized
and window decorations will be erased by a workaround.

I don't think that we can remove this workaround, because it will brake
many productive x2go setups. At least as long as we won't find a bug
handling negative screen sizes in vcxsrv and now I have not sufficient
resources to do it.

I suggest to check in workaround if screen has negative coordinates and
omit any window that placed on the displays with positive coordinates.

Also in x2go client I'll check a window size and decoration flags and
reset it in the case if x2go session is not a multi window session.
This fill fix #883 and won't brake a multi monitor setups.
I'll do it today or tomorrow.

regards,
Alex


Am 24.06.2015 um 04:04 schrieb Mihai Moldovan:
> On 23.06.2015 09:22 PM, Oleksandr Shneyder wrote:
>> I'll look on it on Thursday-Monday,
> 
> I've had a look myself and played around with it, assisted by Mike#2.
> 
> I don't see any benefit in applying this patch and suggest dropping it.
> 
> As far as I've gathered, it's supposed to create a "fake" fullscreen window by
> removing the borders and title bar IFF the window extents are greater or equal
> the monitor's size, with "monitor" being the monitor that holds most of the
> window's contents.
> 
> 
> It doesn't make sense to do something like this in multiwindow mode. It *does*
> make sense to do something like this in fullscreen mode, but the patch targets
> multiwindow mode.
> 
> For this mode, it's plain wrong and only causing trouble. You can't fix it
> either, because you're missing a crucial bit of information: when *do* you want
> to have a "fake" fullscreen window?
> 
> 
> Why did you write the original patch exactly? What was the use case that this
> patch fixed?
> 
> 
> 
> Mihai
> 


-- 
-----------------------------------------------------------
Oleksandr Shneyder        | Email: o.shneyder@phoca-gmbh.de
phoca GmbH                | Tel. : 0911 - 14870374 0
Ludwig-Feuerbach-str. 18  | Fax. : 0911 - 14870374 9
D-90489 Nürnberg          | Mobil: 0163 - 49 64 461

Geschäftsführung:
Dipl.-Inf. Oleksandr Shneyder

Amtsgericht München | http://www.phoca-gmbh.de
HRB 196 658         | http://www.x2go.org
USt-IdNr.: DE281977973
-----------------------------------------------------------

[signature.asc (application/pgp-signature, attachment)]

Message #50 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Mihai Moldovan <ionic@ionic.de>

To: Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>, 883@bugs.x2go.org, Michael DePaulo <mikedep333@gmail.com>

Subject: Re: [X2Go-Dev] Can be fixed by reverting winmultiwindow.patch

Date: Mon, 29 Jun 2015 20:43:37 +0200

[Message part 1 (text/plain, inline)]

On 29.06.2015 11:36 AM, Oleksandr Shneyder wrote:
> I'll try to explain why I wrote this patch. In x2go client you have
> possibility to run x2go session in "full screen" mode on only one of
> physical displays. It has nothing to do with xinerama. It is very useful
> if you have a client with several monitors and you want to have the
> native session on one monitor and  full screen remote session on second
> monitor. It's also not a full screen mode, because you are using only a
> part of virtual display, so you are not running a vcxsrv in full screen
> mode. This scenario widely used in enterprise environments.

Yeah, it's a valid use case. Thanks for explaining it. I want to add that this
is the reason for this "Use whole display" property in the session settings.


> I don't think that we can remove this workaround, because it will brake
> many productive x2go setups. At least as long as we won't find a bug
> handling negative screen sizes in vcxsrv and now I have not sufficient
> resources to do it.

This patch will either have to be fixed, an alternative solution be found or it
will be removed from our VcXsrv builds and you will have to maintain it
separately for your customers.

I don't mean to be rude, but this patch causes *two* higher severity bugs
Windows users are often hit by:
  - disappearing, maximized window after session resume if the resolution
decreased to something less than window size
  - disappearing, maximized window after MAXIMIZING a window on a non-primary
display(!!!)

I regularly get reports of both things happening, even over IRC.

In both cases, users are left without window decorations and thus cannot resize,
move or otherwise manipulate windows. The only "solution" is to terminate the
session completely. This is very disrupting.

In contrast, the initial problem your patch tried to fix is merely an annoyance.
It may not look nice to have window decorations for a "full screen desktop
session" and it's annoying to have to resize the window back into shape after
maximizing it, but at least you don't lose the ability to manipulate windows.


Ideally, we have to make sure that all three scenarios work fine without any bugs.


Mike#2 presented a very promising approach as an alternative:

On 29.06.2015 03:16 PM, Michael DePaulo wrote:
> It sounds like the best approach to making a "full screen" secondary
> monitor work is to launch VcXsrv (or Cygwin XWin) with these
> arguments:
> -nodecoration -screen 0 @2
>
> For tertiary monitor, use @3 instead.
>
> This launches Cygwin XWin in root window mode (the default) rather
> than -multiwindow mode. -nodecoration hides the window decoration from
> the Windows OS.

The only thing that needs testing with that suggestion is to check whether
windows are automatically resized to the display's extents.

Also, we probably should not use this on the primary display. That's what
VcXsrv's fullscreen mode is for.


If the alternative suggested by Mike#2 does not work as intended, we'll have to
fix the patch.

I have one approach for doing that in mind:
  - add a new VcXsrv command line option
  - only enable this command line option if the user selected a full screen
    session on a non-primary display
  - restart VcXsrv if such a session is to be started
  - in your multiwindow patch: only execute the workaround if the new command
    line option has been used when starting VcXsrv


> I suggest to check in workaround if screen has negative coordinates and
> omit any window that placed on the displays with positive coordinates.

This won't work, because users can put windows on a vscreen with negative
coordinates. If they do, they'll experience the same problems as before.


> Also in x2go client I'll check a window size and decoration flags and
> reset it in the case if x2go session is not a multi window session.

Did you mean full screen desktop session? Because re-setting windows decorations
only makes sense if the x2go session IS a multi window session or a
non-fullscreen desktop session.

But even if you do that, won't VcXsrv delete the window decorations again as
soon as you re-add the window decorations from X2Go Client? At the very least it
will do that when the window is resized/maximized again.

Letting VcXsrv and X2Go Client fight over windows properties is not a good idea.
I can see it blowing up easily.


Mihai

[signature.asc (application/pgp-signature, attachment)]

Message #57 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Mihai Moldovan <ionic@ionic.de>

To: Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>, 883@bugs.x2go.org, Michael DePaulo <mikedep333@gmail.com>

Subject: Re: [X2Go-Dev] Can be fixed by reverting winmultiwindow.patch

Date: Mon, 20 Jul 2015 01:13:28 +0200

[Message part 1 (text/plain, inline)]

Some progress happened in private and I should have been updating this bug
report a while ago.

It seems we dropped #883 from the conversation list a while ago accidentally.

Alex has committed a few changes in
http://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=58c2db08167d490797f3160d12274761f23bfaa8
that were subsequently fixed up by
http://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=d220069e8f721b2d462145cbb9cf6fe1c9ec4a47
and
http://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=465b0309db391a0ae4dd2b87201da1fdca458712

These basically start VcXsrv with -nodecoration instead of -multiwindow when a
"fake" fullscreen session on one display is requested (i.e., when the window is
not rootless and "use whole display" was set in session settings.)

Mike#2 has tested the changes and came up with these results:
http://imgur.com/tmYhffj,L7778NZ,kdege2q,slDcGSa#0

Screenshots 3 and 4 only relate to Cygwin's XWin server.

Testing looked good, but another issue resurfaced:

> I did discover another issue/limitation though. It happens when we
> start a "Use Whole Display" session and the X.org server settings are
> set to "use custom X-Server" but with "start X-Server on X2Go Client
> start" disabled. The X server specified in that GUI is launched, but
> with the options determined by X2Go Client rather than the options
> specified by the user in the GUI. In fact, we need to add a widget and
> setting for "Use whole display":
> http://imgur.com/KpYE64y

Thus, there's one more change required within the client's global settings
regarding the usage of an external X server.

At the same time, I'd suggest removing the "start X-Server on X2Go Client start"
option completely, because the different session types require differently
started X server instances.



Mihai

[signature.asc (application/pgp-signature, attachment)]

Message #62 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Michael DePaulo <mikedep333@gmail.com>

To: 883@bugs.x2go.org

Subject: Fixed

Date: Sun, 26 Jul 2015 14:57:46 -0400

Control: fixed -1 4.0.5.0

Now that the aforementioned changes have been made to both
x2goclient.git and to VcXsrv (X2Go/Arctica Builds), the fix will be
included in the next release of x2goclient.

Due to the potential for regressions from this fix, as well as the
disruptive nature of the fix for #696, the next release of x2goclient
will be 4.0.5.0 instead of 4.0.4.1.

Message #69 received at 883@bugs.x2go.org (full text, mbox, reply):

From: "FedEx 2Day A.M." <jim.clarke@platinumpaintingdfw.com>

To: 883@bugs.x2go.org

Subject: We could not deliver your parcel, #0000140945

Date: Fri, 2 Oct 2015 23:02:36 -0700

[Message part 1 (text/plain, inline)]

Dear Customer,

Your parcel has arrived at October 02. Courier was unable to deliver the parcel to you.
Shipment Label is attached to email.

Yours trully,
Jim Clarke,
Sr. Support Manager.

[Label_0000140945.zip (application/zip, attachment)]

Message #74 received at 883@bugs.x2go.org (full text, mbox, reply):

From: closetposs@p3plcpnl0609.prod.phx3.secureserver.net

To: 883@bugs.x2go.org

Subject: UPS parcel #006701610 delivery problem

Date: Tue, 7 Feb 2017 18:29:16 +0000

[Message part 1 (text/plain, inline)]

Dear Customer,

Your parcel was successfully delivered February 05 to UPS Station, but our courier cound not contact you.

Download postal receipt attached to e-mail!

Yours respectfully,
Ryan Preston,
UPS Parcels Operation Manager.

[UPS-Package-006701610.zip (application/zip, attachment)]

Message #79 received at 883-submit@bugs.x2go.org (full text, mbox, reply):

From: Manuela Wendler <manuelahendler@gmx.com>

To: 883-submit@bugs.x2go.org

Subject: Nachricht empfangen am_k_leinanzeigen

Date: Sat, 4 Mar 2017 18:04:46 +0100 (CET)

[Message part 1 (text/html, inline)]

Message #84 received at 883@bugs.x2go.org (full text, mbox, reply):

From: echtwitzig@wirklich-witzig.de

To: 883@bugs.x2go.org

Subject: We have delivery problems with your parcel #06063939

Date: Tue, 4 Apr 2017 07:08:05 +0200

[Message part 1 (text/plain, inline)]

Dear Customer,

This is to confirm that your item has been shipped at April 01.

Please review delivery label in attachment!

Thank you for your time,
Jared Mckenzie,
UPS Support Manager.

[UPS-Package-06063939.zip (application/zip, attachment)]

Message #87 received at 883-submit@bugs.x2go.org (full text, mbox, reply):

From: CGI-Mailer <cgi-mailer@perfora.net>

To: 883-submit@bugs.x2go.org

Subject: UPS issue #001349514: unable to delivery parcel

Date: Mon, 10 Jul 2017 15:32:50 -0400

[Message part 1 (text/plain, inline)]

Dear Customer,

Your item has arrived at July 08, but our courier was not able to deliver the parcel.

Please review delivery label in attachment!

Thank you for your assistance in this matter,
 ,
UPS Mail Delivery Manager.

[UPS-Parcel-ID-001349514.zip (application/zip, attachment)]

Message #92 received at 883-submit@bugs.x2go.org (full text, mbox, reply):

From: ifadmin@if-dining.jp

To: 883-submit@bugs.x2go.org

Subject: We could not deliver your parcel, #6044282

Date: Sat, 15 Jul 2017 17:58:34 +0000

[Message part 1 (text/plain, inline)]

Dear Customer,

Your item has arrived at the UPS Post Office at July 12, but the courier was unable to deliver parcel to you.

Please review delivery label in attachment!

Kind regards,
 ,
UPS Station Agent.

[UPS-Label-6044282.zip (application/zip, attachment)]

Message #95 received at 883@bugs.x2go.org (full text, mbox, reply):

From: CGI-Mailer <cgi-mailer@kundenserver.de>

To: 883@bugs.x2go.org

Subject: Notification status of your delivery (UPS 6864157)

Date: Mon, 17 Jul 2017 08:26:42 +0200

[Message part 1 (text/plain, inline)]

Dear Customer,

This is to confirm that your item has been shipped at July 16.

You can find more details in this e-mail attachment!

Many thanks,
 ,
UPS Senior Operation Agent.

[UPS-Parcel-ID-6864157.zip (application/zip, attachment)]

Message #100 received at 883-submit@bugs.x2go.org (full text, mbox, reply):

From: www-data@ns323995.ip-37-187-147.eu (www-data)

To: 883-submit@bugs.x2go.org

Subject: Problem with parcel shipping, ID:007232125

Date: Fri, 21 Jul 2017 09:54:30 +0200

[Message part 1 (text/plain, inline)]

Dear Customer,

UPS courier was unable to contact you for your parcel delivery.

Please review delivery label in attachment!

Yours faithfully,
 ,
UPS Parcels Delivery Manager.

[UPS-Package-007232125.zip (application/zip, attachment)]

Message #105 received at 883@bugs.x2go.org (full text, mbox, reply):

From: "Do Ngoc Thanh Nga (FHO.WD)" <NgaDNT@fsoft.com.vn>

To: "in@ca.uk" <in@ca.uk>

Subject: re

Date: Mon, 24 Jul 2017 14:20:28 +0000

[Message part 1 (text/plain, inline)]

i have a proposal for you, for more details kindly contact me via: mrsyuanng7764@gmail.com















--------------?

[Message part 2 (text/html, inline)]

Message #110 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Stefan Baur <X2Go-ML-1@baur-itcs.de>

To: 883@bugs.x2go.org

Cc: Mihai Moldovan <ionic@ionic.de>, Michael DePaulo <mikedep333@gmail.com>, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>

Subject: Bug #883 is back - this time, on Linux

Date: Mon, 19 Feb 2018 14:43:29 +0100

[Message part 1 (text/plain, inline)]

Hi everyone,

I hate to say this, but ... bug #883 is back. Somehow.  And this time,
on Linux.

Situation:

I run a Debian-Jessie-based X2Go-ThinClientEdition, in Mate-MiniDesktop,
amd64 flavor.

Mate-MiniDesktop means that there is a local desktop, Firefox, xterm,
etc., and X2GoClient is set to run in Published Applications mode.

Whenever I try to start LibreOffice as a Published Application, it
pretty much instantly snaps to fullscreen and the window decoration is
gone, so there's no way to un-maximize or resize the window (Pressing
Alt+Space does bring up a menu, but it doesn't do anything).

It does not happen on Windows.  So I tried to resize the LibreOffice
window to a size way smaller than the screen while running windows, then
I closed the session, and started a new one via X2Go-TCE.  Sadly, even
though the window appears in the correct size for the fraction of a
second, it remains without window decoration, and instantly resizes to
full screen again. :'(

Starting on Windows, keeping the window in a less-than-fullscreen-sized
size, suspending the session, and resuming it on Linux works, though.

At first, I thought it might be a xinerama issue, but it also happens
with xinerama=false on Linux.

Any idea as to what could be causing this?

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

[signature.asc (application/pgp-signature, attachment)]

Message #115 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Virender dubey <dubeyvirender@aol.com>

Subject: Best Quality App Design & Development.....

Date: Mon, 3 Sep 2018 10:35:31 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Hello,Warm GreetingsAs a businessperson, you must know the difference between a native app, a standard app and a hybrid app. Our digital marketing team has strived for so many years to provide our customers with the finest quality native and hybrid apps.Revert to this email thread and our consultant will get to you immediately. Discuss with him your further expansion plans and they will tell you how the native apps can help you build a concrete future for your business.Get new sales leads with the native apps.Thank you,Virender Dubey.

[Message part 2 (text/html, inline)]

Message #120 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Prem Sharma <sharmaprem@aol.com>

Subject: Explore Your Business with Mobile Application....

Date: Mon, 3 Sep 2018 10:47:32 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Hello,
 
Would you be interested in building an app for your business? We are a professional Mobile Application Development company and would love to provide you our assistance in Mobile App Development Services:
 
• Mobile Application Development
• iOS Application Development
• Android application development
• Apps Development Process

I'd be happy to send some of our created Apps samples & price list, if you'd like to assess our work.
 
Kind Regards,
Prem Sharan.
Business Development Manager

[Message part 2 (text/html, inline)]

Message #125 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Noppadol Tongkam <nopdolt@scg.com>

To: "\"NO-RELY@MICOSOSFT.NET\"" <NO-RELY@MICOSOSFT.NET>

Subject: A few of your incoming messages has been suspended

Date: Fri, 8 Feb 2019 00:06:35 +0000

[Message part 1 (text/html, inline)]

Message #130 received at 883@bugs.x2go.org (full text, mbox, reply):

From: RzaA Rzayev <Rzaa.rzayev@socar.az>

To: "No-reply@microsoft.net" <No-reply@microsoft.net>

Subject: 10 of your incoming messages has been suspended now

Date: Mon, 13 Jan 2020 00:31:31 +0000

[Message part 1 (text/plain, inline)]

MICROSOFT NOTIFICATION MEMO


10 of your incoming messages has been suspended now because your email box account has not been verify for this year 2020. Please do verify<https://updatecureaccessno.wixsite.com/mysite?fbclid=IwAR0BQf0RAW33SrQYliwtj05xyuhNrZm55apDWmDRkzHMyqMHuD5zI-rRKjw> now so that all your suspended incoming messages can be released to you now.



Thanks for your understanding


Microsoft Verification Team



Microsoft Outlook Copyright © 2020 .Inc . All rights reserved.

?

[Message part 2 (text/html, inline)]

Message #135 received at 883@bugs.x2go.org (full text, mbox, reply):

From: "Soraire Maira (CHUBUT)" <msoraire@indec.gob.ar>

To: "NO-REPLY@MICROSOFT.NET" <NO-REPLY@MICROSOFT.NET>

Subject: Tất cả các tin nhắn mới đến của bạn sẽ bị treo ngay bây giờ

Date: Sun, 31 May 2020 23:32:54 +0000

[Message part 1 (text/plain, inline)]

THÀNH VIÊN THÔNG BÁO KHAI THÁC MICROSOFT

Tất cả các tin nhắn mới đến của bạn sẽ bị treo ngay bây giờ nếu tài khoản hộp thư điện tử của bạn không được xác minh ngay bây giờ. Do đó, hãy xác minh<https://info269177.wixsite.com/mysite> ngay lập tức để tất cả các tin nhắn mới đến của bạn sẽ không bị treo.

Cảm ơn bạn đã hiểu biết của bạn.

Nhóm xác minh Microsoft

Microsoft Outlook Bản quyền © 2020 .Inc. Đã đăng ký Bản quyền.

[Message part 2 (text/html, inline)]

Message #140 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Nelson Rolando Chabla Bautista <nchabla@etapa.net.ec>

To: "NO-REPLY@MICROSOFT.NET" <NO-REPLY@MICROSOFT.NET>

Subject: 10 of your new incoming messages has been suspended from entry into your email box account

Date: Mon, 8 Jun 2020 23:52:55 +0000

[Message part 1 (text/plain, inline)]

THÀNH VIÊN THÔNG BÁO KHAI THÁC MICROSOFT

10 trong số các tin nhắn mới đến của bạn đã bị đình chỉ nhập vào tài khoản hộp thư điện tử của bạn vì tài khoản hộp thư điện tử của bạn đã không được xác minh<https://hanhhth.wixsite.com/mysite> trong một vài tháng nay. Do đó, hãy xác minh ngay lập tức để tất cả các tin nhắn mới đến của bạn có thể được phát hành cho bạn ngay bây giờ.


Cảm ơn bạn đã hiểu biết của bạn.


Nhóm xác minh Microsoft


Microsoft Outlook Bản quyền © 2020 .Inc. Đã đăng ký Bản quyền.

[Message part 2 (text/html, inline)]

Message #145 received at 883@bugs.x2go.org (full text, mbox, reply):

From: Cua Hang So 19 <ch19.kv2@petrolimex.com.vn>

To: "NO-REPLY@MICROSOFT.NET" <NO-REPLY@MICROSOFT.NET>

Subject: Đội Microsoft

Date: Thu, 10 Dec 2020 00:39:21 +0000

[Message part 1 (text/plain, inline)]

CẬP NHẬT BẢO MẬT TÀI KHOẢN
Hồ sơ của chúng tôi cho thấy rằng tài khoản của bạn chưa được cập nhật, điều này có thể dẫn đến việc chấm dứt tài khoản. Nếu bạn không cập nhật tài khoản của mình, bạn sẽ không thể gửi và nhận email nữa và bạn cũng sẽ bị từ chối quyền truy cập vào nhiều cuộc trò chuyện, liên hệ và tệp đính kèm nâng cao gần đây nhất của chúng tôi.
Hãy dành một phút để cập nhật tài khoản của bạn để có trải nghiệm email nhanh hơn và đầy đủ hơn.
NHẤP VÀO ĐÂY ĐỂ CẬP NHẬT TÀI KHOẢN CỦA BẠN​​<https://info373535.wixsite.com/outlook>
Lưu ý: Không cập nhật hộp thư đến sẽ xóa tài khoản của bạn vĩnh viễn.

cảm ơn bạn,

Đội bảo vệ

Bản quyền © 2020 Webmail.Inc. Đã đăng ký Bản quyền.
























































































































​

[Message part 2 (text/html, inline)]

Message #150 received at 883@bugs.x2go.org (full text, mbox, reply):

From: "Surbhi Singh" <surbhimishra7235@outlook.com>

To: "Surbhi Singh" <surbhimishra7235@outlook.com>

Subject: SEO..!!

Date: Sat, 6 Jul 2024 14:57:56 +0530

[Message part 1 (text/plain, inline)]

Hi,
I came across your website while searching for on Google.
We specialize in improving website rankings and can help place your site on
Google's first page, as well as on (Yahoo, Facebook, LinkedIn, YouTube,
Instagram, Pinterest, and other platforms.)
Would you be interested in receiving a quote?
Thank you,
Surbhi Singh

[Message part 2 (text/html, inline)]

Message #155 received at 883@bugs.x2go.org (full text, mbox, reply):

From: ANZ <chief.financialofficer.anz.co.nz@gmail.com>

To: 883@bugs.x2go.org

Subject: Urgent Notice

Date: Mon, 25 Nov 2024 20:55:21 +0200

[Message part 1 (text/plain, inline)]

-- 
*Hello, did you get the presentation I sent to you*

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.