I've been meaning to figure this one out, but never got around to
it... maybe this will motivate me ;)

another interesting comment from the Debian bts:

I'd just like to add my two cents here... Galeon 1.2 was the ONLY modern
browser which did this correctly, and thus was the only modern browser
properly-usable under pwm, which can use the WM_CLASS to automatically
group multiple windows into a single tabbed group, and pwm's native tabs
are FAR superior to any application's built-in tabbed support.  The same
goes for ion; managing multiple browser windows under ion becomes quite
hellacious if you have to worry about dialog boxes and so on being treated
identically with the browser window.

Like, even the "find" dialog box does this, which means that not only is
the "find" box no longer associated with a specific browser window like it
was in galeon 1.2, but when I bring it up, it pops up as a separate
browser
window with the same size and shape as a browser window.  It's extremely
annoying and frustrating, and makes me feel like all of the time and
energy
I've invested in setting up a user environment which suits my work style
and ergonomic needs has been totally wasted by the apathy of
developers who
seem to think that doing it just like Windows is good enough.

So it's not just users of an esoteric Sawfish feature which are left
out in
the cold on this; users of even more esoteric window managers such as pwm
and ion are hurt even worse. :)

Actually, if I understood correctly, WM_CLASS is supposed to be the
same for all windows of the same application (ICCM or something spec,
I think)

The property we should be setting different for all windows is
WM_WINDOW_ROLE, hope your esoteric wm's can handle it.  I wonder if it
can even handle the fullscreen mode ;)

Another posting to the debian bts:

Actually it is quite simple to fix this!  You just have to set the
wmclass_name property for each dialog in the *.glade files -- at least
that's what galeon-1.2 does.

E.g. to fix the problem for the history dialog you just have to add
one line to galeon.glade:

  <widget class="GtkDialog" id="history_dialog">
    <property name="border_width">6</property>
    <property name="height_request">400</property>
    <property name="title" translatable="yes">History</property>
    <property name="type">GTK_WINDOW_TOPLEVEL</property>
    <property name="window_position">GTK_WIN_POS_NONE</property>
    <property name="modal">False</property>
    <property name="resizable">True</property>
    <property name="destroy_with_parent">False</property>
    <property name="has_separator">False</property>
+   <property name="wmclass_name">history_dialog</property>

    <child internal-child="vbox">
      <widget class="GtkVBox" id="history_dialog_b">
        <property name="visible">True</property>


Setting WM_WINDOW_ROLE (any self-respecting WM will understand that
property) might be more appropriate with respect to ICCCM[1] but I
think Glade only handles WM_CLASS/WM_NAME currently.


        Juergen



Footnotes: 
[1]  ICCCM 2.0.xf86.1 Section 5.1:
    [...] If the WM_WINDOW_ROLE property is not specified on a top-
    level window, a client that needs to uniquely identify that window
    will try to use instead the values of WM_CLASS and WM_NAME.  If a
    client has multiple windows with identical WM_CLASS and WM_NAME
    properties, then it should provide a WM_WINDOW_ROLE
    property. [...]

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

WM_CLASS -> http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5
WM_WINDOW_ROLE -> http://tronche.com/gui/x/icccm/sec-5.html#s-5.1

This has been fixed in 2.0