I can confirm this when running BibleTime, a Qt application. Passing Qt::CustomizeWindowHint | Qt::WindowTitleHint | Qt::WindowCloseButtonHint or any combination thereof has no effect on Gnome 3. Only using Qt::Window works, but this turns it into a regular window instead of a dialog window.

I suppose both _NET_WM_WINDOW_TYPE_DIALOG and MWM_FUNC_CLOSE get through to Mutter, but the latter fails to show the close button.

You can confirm this behavior by running the Qt demo application "Window Flags": http://doc.qt.nokia.com/widgets-windowflags.html

You can run it by installing the qt-demo or (qt4-demo or qtdemo-qt4 on some platforms) application, selecting "Widgets" -> "Window Flags" -> "Launch" or by running the "Window Flags" application manually from its install location.

Just select "Dialog" (== Qt::Dialog) as the "Type" and toggle combinations of "Customize window", "Window title" and "Window close button" checkboxes to verify that it doesn't work.

On Gnome 2.30.2 the showing/hiding the close button works.

Well, at least Firefox and Thunderbird have fixed this problem. So, at least it seems that it is not a problem with GTK+ applications and can be fixed by the application. Maybe a separate bug for Qt applications should be opened?!

I do not see any rational reason to consider this to be a bug in Qt applications when it is Gnome 3 that bluntly ignores the MWM_FUNC_CLOSE hint. That Firefox and Thunderbird have "fixed" the issue should be considered as a friendly gesture towards Gnome, not as an actual bug in those applications. The bug is still in Gnome 3. At minimum, I see this as a backwards-compatibility issue.

PS: Sorry for not being as friendly as others on this issue, and not bowing before the will of Gnome to define how all applications should design and present their dialogs (and to world domination :).
PPS: Until somebody gives good reasons for me to change my position on this matter, I will likely continue directing similar bug reports filed against such applications to Gnome. Thanks.

I didn't mean that the problem is necessarily in Qt applications. I meant that if the problem with Qt applications still exist, I suggest to open a separate bug in *GNOME* about missing close button for them; since I (as the reporter of this bug) has no clue about why there were no close buttons previously and how Firefox/Thunderbird managed to add it again if it cannot be added in a standard way (seems to be MWM_FUNC_CLOSE as you said). Apparently you have a better insight about the problem, so I certainly suggest you to open a separate bug with a better subject about the issue. 

Anyway, I'm not a member of Gnome team so I neither tell you to not report bugs about this issue nor I will brings reasons for you to change your position! :P

I believe this is a valid bug. Unlike in OS X and Windows, dialogs don't have a 'x' (to close) button in GNOME. They probably should, since it's quite a pain for developers to add special [ "Close" ] buttons to their dialogs, just to appease mutter users.

GTK+ 3.12's new dialogs have headerbars with 'x' buttons, so it seems like there is recognition that dialogs should have 'x' buttons.

Please add 'x' buttons in the top of the title bar for mutter-decorated dialogs.

Here is some proof of the inconvenience caused by the current behavior:

https://stackoverflow.com/questions/8691025/qt-qdialog-and-gnome-3-how-to-display-the-close-button-title-bar-and-make-it-mo

http://www.qtcentre.org/threads/31905-Show-maximize-button-in-the-title-bar-of-a-QDialog-under-GNOME

http://musescore.org/node/21036

https://github.com/nvbn/everpad/issues/88

One more example:

https://bugs.launchpad.net/bzr-explorer/+bug/1090331

The following fix has been pushed:
86d8c39 theme: Stop hiding titlebar buttons in dialogs

Created attachment 312828 [details] [review]
theme: Stop hiding titlebar buttons in dialogs

As design patterns have evolved, dialogs that use CSD do use titlebar
buttons, so it's time to re-enable them for SSD as well.

*** Bug 762188 has been marked as a duplicate of this bug. ***