Bug 3556 - Debugger tooltip show up in the wrong place when Compiz is running
Summary: Debugger tooltip show up in the wrong place when Compiz is running
Status: RESOLVED UPSTREAM
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: Trunk
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Jeffrey Stedfast
URL:
: 2985 3499 ()
Depends on:
Blocks:
 
Reported: 2012-02-21 08:18 UTC by Nikita Tsukanov
Modified: 2012-02-21 12:38 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
video (1.52 MB, application/octet-stream)
2012-02-21 08:20 UTC, Nikita Tsukanov
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED UPSTREAM

Description Nikita Tsukanov 2012-02-21 08:18:12 UTC
See the attached video. It works fine with kwin and metacity.
Comment 1 Nikita Tsukanov 2012-02-21 08:20:27 UTC
Created attachment 1397 [details]
video
Comment 2 Nikita Tsukanov 2012-02-21 08:24:25 UTC
Monodevelop 2.8.2 works fine in the same setup.
Comment 3 Nikita Tsukanov 2012-02-21 09:42:28 UTC
As I can see this issue is caused by this commit: https://github.com/mono/monodevelop/commit/a5524bf142e4119cab05e132bf08752dd47e1374
When I compile monodevelop from previos one it works fine.
Comment 4 Jeffrey Stedfast 2012-02-21 09:52:31 UTC

*** This bug has been marked as a duplicate of bug 2985 ***
Comment 5 Jeffrey Stedfast 2012-02-21 10:35:57 UTC
Actually, I should probably mark the other as a dup of this...
Comment 6 Jeffrey Stedfast 2012-02-21 10:36:48 UTC
*** Bug 2985 has been marked as a duplicate of this bug. ***
Comment 7 Jeffrey Stedfast 2012-02-21 10:38:54 UTC
I'm thinking the bug has to be in the DoShowTooltip() in TextEditor.cs because that's the only one that changes the X location.

The other possibility is that getting the location of the window in the DebugValueWindow code is getting invalid values?
Comment 8 Jeffrey Stedfast 2012-02-21 11:22:47 UTC
I can't reproduce this with Ubuntu 11.10 in VirtualBox with the default window manager (how do I even make it use Compiz?)

Can someone who can reproduce this bug add some Console.WriteLine()'s to figure out what is breaking?

I've tried everything and I just can't replicate it.
Comment 9 Jeffrey Stedfast 2012-02-21 12:01:10 UTC
Marek is helping me debug this with some CWL's in his MD.

Gtk seems to be giving us wrong allocation *and* window position values in the OnSizeALlocated() callback.

It is telling us that the tooltip window is already at 0,0 when it is not, so we adjust the position to a location that is not up against the edge of the screen.
Comment 10 Jeffrey Stedfast 2012-02-21 12:06:11 UTC
Interestingly, Compiz seems to be resizing the tooltip window 5 times ,the third time it just randomly says the window is at 0,0
Comment 11 Jeffrey Stedfast 2012-02-21 12:38:08 UTC
This seems related (windows always show up at 0,0 no matter what): http://bugs.compiz.org/show_bug.cgi?id=5

This one claims Compiz is broken wrt window position reporting (often claiming position being 0,0 when it's not): http://bugs.compiz.org/show_bug.cgi?id=72

Seems very likely to be related.
Comment 12 Jeffrey Stedfast 2012-02-21 12:38:52 UTC
*** Bug 3499 has been marked as a duplicate of this bug. ***