Bug 10644 - [gtk] Xamarin Studio stuck on top
Summary: [gtk] Xamarin Studio stuck on top
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: unspecified
Hardware: PC Windows
: High normal
Target Milestone: ---
Assignee: Mike Krüger
URL:
: 10336 12206 16761 17362 18200 20464 ()
Depends on:
Blocks:
 
Reported: 2013-02-25 11:05 UTC by Tracy
Modified: 2014-06-09 13:52 UTC (History)
15 users (show)

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

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 FIXED

Description Tracy 2013-02-25 11:05:18 UTC
After deploying and debugging an android application on a physical device Xamarin studio locks the screen focus.
You can minimize the window, but you can not open anything on top of it.
This includes internal dialog windows.
For example I tried to add a new file, and the add new file dialog open under the main window.
At this point there is no way to get to the dialog window and you must force shut Xamarin Studio.

On my setup I am running three monitors with Xamarin Studio on the middle one in full screen.
Comment 1 Mikayla Hutchinson [MSFT] 2013-02-25 13:42:49 UTC
I've seen this once myself, and it was reported a couple of times on the forum (http://forums.xamarin.com/discussion/comment/4670/#Comment_4670).

We haven't figured out repro steps yet, however.
Comment 2 Michael Natterer 2013-02-26 04:00:40 UTC
Michael, after all the window type hint and transient discussion, how
exactly did you end up doing the floating windows?
Comment 3 Mikayla Hutchinson [MSFT] 2013-02-27 18:07:32 UTC
I made them non-transient utility windows for now: https://github.com/mono/monodevelop/commit/54e8a9e0df2e13d493ba01f68b0f7869db03f389
Comment 4 Mikayla Hutchinson [MSFT] 2013-03-03 22:32:33 UTC
I have found one way to repro this, though it doesn't sound like the cause of the original bug.

* Click the breadcrumb dropdown
* use Jing to screenshot it

So it may be some kind of stuck grab.
Comment 5 Aleksander Morgado 2013-03-04 09:30:15 UTC
I can easily reproduce the issue with the previous steps, will take a look at it.
Comment 6 Aleksander Morgado 2013-03-05 05:30:36 UTC
Even easier steps, reproduced even with gtk-demo:
 * open any combobox in the main window
 * Alt+Tab to go to another app
 * Alt+Tab to go back to XS

Seems we're not closing the toplevel GDK_WINDOW_TEMP window created by the comboboxes when we change the application, as otherwise done with the menus. That issue is actually making us restack the main window below the GDK_WINDOW_TEMP and therefore moving it implicitly into the toplevel group as well, which makes the window always-visible.
Comment 7 Aleksander Morgado 2013-03-05 05:51:09 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=695200
Comment 8 Aleksander Morgado 2013-03-08 04:05:57 UTC
Please include the following patch in your gtk 2.24.x builds, which should solve the issue:
  http://bugzilla-attachments.gnome.org/attachment.cgi?id=238151

Upstream seems to like it, and we're now discussing the patch for master meanwhile.
Comment 9 Mikayla Hutchinson [MSFT] 2013-03-08 16:24:43 UTC
Since this is happening with our custom widget in the breadcrumb bar, presumably it would need the same fix?
Comment 10 Tracy 2013-03-08 16:27:02 UTC
I dont know about the bread crumbs, or comboboxes, but it happens when I try an do anything after a run on my physical device.
I cant reproduce it every time and I havent figured out if it is when I hit the start button, or hit F5, or select run from the drop down.
I hope a fix will be rolled out in the master shortly.
Comment 11 Aleksander Morgado 2013-03-11 05:28:32 UTC
Yes, make sure that if your widget creates a temp window, like the one opening the combobox, the window gets closed when the grab is lost.
Comment 12 Mikayla Hutchinson [MSFT] 2013-03-11 14:51:58 UTC
Mike, can you fix this on the breadcrumbs widgets?
Comment 13 Mikayla Hutchinson [MSFT] 2013-03-11 14:52:18 UTC
And anywhere else that we take a grab, for that matter.
Comment 14 Mike Krüger 2013-05-03 03:55:37 UTC
Should be fixed
Comment 15 constructor 2013-05-09 08:43:48 UTC
When I have 2 instances of Xamarin Studio open (comparing an example project and my own project) I still get this window locking/on top behaviour on Windows 7. I have the latest stable build according to Xamarin Studio update (9th May).
Comment 16 Mikayla Hutchinson [MSFT] 2013-05-09 10:23:32 UTC
DO you have the new GTK#, 2.12.21?
Comment 17 Mikayla Hutchinson [MSFT] 2013-05-11 12:59:24 UTC
*** Bug 12206 has been marked as a duplicate of this bug. ***
Comment 18 eduard.qualls 2013-06-27 14:09:16 UTC
Status: not fixed (or it's been re-introduced)

XS 4.0.9 [on multi-monitor Win 7]

XS main window gets toggled to "Always on top" so that no dialog boxes [such as the full find or replace windows] are allowed to come to the foreground. XS main window becomes inactive (no response to mouse or keyboard).

When this happens, XS also blocks all other application and system windows, but will allow itself to be minimized or moved, so long as it has no dlgbox up.

Usually, if you hit escape when this first starts happening, the hidden dlgbox will go away and XS will regain focus so that you can kill it and reload it, at which point it resumes proper behavior. However, there have been times when nothing responded, and the only recourse was to go the "Processes" windows of Task Manager and force the OS to kill the entire process.

This situation appears to be particularly quick to show up when switching between "Content" and "Source" windows while editing layouts. (So far, I've had to kill XS and re-start it three times, and it's only 1 PM.)
Comment 19 eduard.qualls 2013-06-27 14:10:42 UTC
Clarification: When it starts happening, XS stays on top of all other windows. (It isn't only when it has a dlgbox up.)
Comment 20 Mikayla Hutchinson [MSFT] 2013-06-27 14:35:30 UTC
Just to confirm whether this is actually a multimonitor issue, could you please try to reproduce it without the second monitor attached? I don't have a multimonitor system at the moment.
Comment 21 eduard.qualls 2013-06-27 16:01:30 UTC
I have not been able to recreate it as of yet. (Sometimes it takes longer than
at other times.)

As for now, I can tell you that going to single monitor appears to fix the
port-access problem I reported in 12672.

XS also seems faster and much more stable in single-monitor mode than in
dual-monitor.

However, it does not fix the reported problem with dead tabs (#10790).
Comment 22 Carlos Garnacho 2013-07-10 13:46:25 UTC
After checking thoroughly, the patch in https://bugzilla.gnome.org/show_bug.cgi?id=695200#c1 should fix the problem for good with 0 side effects. There's places in monodevelop where Popup windows are created without being necessarily driven by a pointer grab, any of those windows may bring the same issue if the transient window is focused out and back in while they're onscreen.
Comment 23 Mikayla Hutchinson [MSFT] 2013-07-11 16:20:20 UTC
*** Bug 10336 has been marked as a duplicate of this bug. ***
Comment 24 Mikayla Hutchinson [MSFT] 2013-07-11 20:15:52 UTC
We have prepared a new build of GTK+ that contains this fix. To test it, please download https://mjhutchinson.com/files/temp/gtk-2.24.20-2013-07-11.zip and copy the directories it contains "C:\Program Files (x86)\GtkSharp\2.12". You can verify it is installed by checking that "Help->About->Show Details" shows "GTK 2.24.20".
Comment 25 Mikayla Hutchinson [MSFT] 2013-07-16 12:35:29 UTC
The new GTK+ binaries have been included in the GTK# 2.12.22 installer, which is now in the beta update channel and will roll out to stable after we're reasonably confident there are no regressions.

Please reopen if this happens with GTK+ 2.24.20.
Comment 26 Mikayla Hutchinson [MSFT] 2013-12-12 18:10:23 UTC
*** Bug 16761 has been marked as a duplicate of this bug. ***
Comment 27 Mikayla Hutchinson [MSFT] 2014-01-21 21:16:21 UTC
*** Bug 17362 has been marked as a duplicate of this bug. ***
Comment 28 Mikayla Hutchinson [MSFT] 2014-03-05 15:06:53 UTC
*** Bug 18200 has been marked as a duplicate of this bug. ***
Comment 29 Mikayla Hutchinson [MSFT] 2014-06-09 13:52:03 UTC
*** Bug 20464 has been marked as a duplicate of this bug. ***