Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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.
Michael, after all the window type hint and transient discussion, how
exactly did you end up doing the floating windows?
I made them non-transient utility windows for now: https://github.com/mono/monodevelop/commit/54e8a9e0df2e13d493ba01f68b0f7869db03f389
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.
I can easily reproduce the issue with the previous steps, will take a look at it.
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.
Please include the following patch in your gtk 2.24.x builds, which should solve the issue:
Upstream seems to like it, and we're now discussing the patch for master meanwhile.
Since this is happening with our custom widget in the breadcrumb bar, presumably it would need the same fix?
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.
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.
Mike, can you fix this on the breadcrumbs widgets?
And anywhere else that we take a grab, for that matter.
Should be fixed
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).
DO you have the new GTK#, 2.12.21?
*** Bug 12206 has been marked as a duplicate of this bug. ***
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.)
Clarification: When it starts happening, XS stays on top of all other windows. (It isn't only when it has a dlgbox up.)
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.
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
However, it does not fix the reported problem with dead tabs (#10790).
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.
*** Bug 10336 has been marked as a duplicate of this bug. ***
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".
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.
*** Bug 16761 has been marked as a duplicate of this bug. ***
*** Bug 17362 has been marked as a duplicate of this bug. ***
*** Bug 18200 has been marked as a duplicate of this bug. ***
*** Bug 20464 has been marked as a duplicate of this bug. ***