Confirmed with 2.2.3 on Windows XP.

So what exactly is happening here? I don't follow.

I can also not make any sense out of this bug report. Let's see... "Gimp
toolbar" probably means the toolbox, right? What exactly do you mean with "Click
new layer through the menu on the mouse"? That doesn't seem to make any sense.
And why should a "new layer dialog" be displayed?

Steps to reproduce:

1) Open a new image
2) Minimize the toolbox
3) Go to Layer->New layer in the context menu - this only happens with the image
context menu, it works fine with the image menu and the layers dialog context
window.

Result:
The new layer dialog doesn't open. Additionally, it is now impossible to restore
the toolbox from the taskbar again.

Expected result:
The dialog appears, and the toolbox can be minimized and restored without problems.

Thanks to Michael Schumacher for putting it into better words.

(I need to work on my bug reporting)

I tried it on a Debian system and the root cause of the problem is obvious once
you compare what happens when selecting New Layer from the context menu and
from the image menu or layers dialog.  When using the context menu (<Image> ->
Layer -> New layer), the "New Layer" dialog will not pop up because it has the
toolbox as its parent.  De-iconifying the toolbox solves the problem: both the
toolbox and the "New Layer" dialog show up.

So the bug seems to affect all OSs.  It is only a minor annoyance for many
systems, but it seems to cause a deadlock for Windows.  It could be fixed by
ensuring that the "New Layer" dialog is tied to the image window instead of
the toolbox when it is invoked from the context menu.

By the way, it seems that other dialogs could have the same problem:
  <Image> -> Edit -> Buffer -> Cut Named...
  <Image> -> Edit -> Buffer -> Copy Named...
  <Image> -> Mode -> Indexed...
  <Image> -> Image -> Canvas Size...  (but not Scale Image)
  <Image> -> Image -> Print Size...
  <Image> -> Layer -> Mask -> Add Layer Mask...
  <Image> -> Layer -> Transform -> Offset...
  <Image> -> Layer -> Layer Boundary Size...
  <Image> -> Layer -> Scale Layer...
That's about all I could find.  Note that using the same features from the image
menu, from a shortcut or from the layer dialog (button or context menu) works
fine.  The problem occurs only from the image context menu.

*All* dialogs invoked from the <Image> popup have this problem.

I recently changed HEAD to do exactly that: separating
the <Image> and <Toolbox> menus into different UI managers
to make sure that action_data_get_widget() returns the display
shell instead of the toolbox when called from an <Image> popup
callback.

I just need to do the actual change in action_data_get_widget().

Backporting this whole stuff to 2.2 doesn't feel comfortable though.
Perhaps we should let the dialogs get their parent widget from
the display, not from action_data_get_widget().

When fixing this, we should also consider minimized image windows.
After all, the menus could be torn off and the active display invisible.

Maybe some generic code in GimpDialog::map() to unminimize the
parent widget?

Re comment #7: not all dialogs.  Try to test with the stable branch and compare
Image -> Canvas Size (parent is the toolbox) and Image -> Scale Image (parent is
the image window).

Re comment #8: you are right about detached menus (I just tested this and it
produces funny results) but this is probably less likely to happen.

For detached menus, unminimizing the parent widget might make sense.  However,
this is only appropriate if you are sure that your recent changes in HEAD will
always cause the right parent to be used.  Otherwise, the user would be annoyed
if the toolbox or some other window suddenly pops up.

The changes in HEAD were made to ensure exactly this (among other things).

Did you try both menu entries from the popup? The callbacks get their
parent widget exactly the same way and should both use the toolbox.

Heh, you are right, image_scale_dialog_new() doesn't use the passed
parent widget at all but uses gdisp->shell instead :-)

Yes, I tried them both from the context menu and I was very surprised that
they behaved differently (that's why I mentioned it in comment #6).  So if I
take the CVS stable branch or the Debian build of 2.2.2 and I open the
Canvas Size or the Scale Image dialog from the context menu, one of them is
tied to the toolbox and the other one is tied to the image window.  The right
parent (image window) is also picked by other dialogs such as the display
filters, create new template, etc.

It's funny to discover these inconsistencies in the code now...

Made the scale dialog correctly be affected by this bug too:

2005-02-03  Michael Natterer  <mitch@gimp.org>

	* app/dialogs/image-scale-dialog.c (image_scale_dialog_new): use
	the passed parent widget instead of display->shell.

Fixed in HEAD. The fix for 2.2 is far more complicated and ugly
and still half-finished on my disk.

2005-02-08  Michael Natterer  <mitch@gimp.org>

	* app/actions/actions.c (action_data_get_widget): return the
	active display's shell instead of the toolbox when called from the
	<Image> popup. Fall back to the toolbox if there is no active
	display. Fixes bug #166012.

Shouldn't GTK+ care about minimized parent windows? I suggest that we check for
GTK+ bug reports and if there isn't one, then reassign this (or perhaps bug
#169965) to GTK+.

Bug 169965 comment #9 suggests that this has to be solved at the toolkit and/or WM level, depending on the platform. Does this one qualify as a duplicate?

Since this is fixed in HEAD and 2.4 is fast approaching, I am going to reset the target to 2.4 and declare it FIXED for purposes of Bugzilla housekeeping -- which should not prevent mitch from continuing to backport it if he wants to.