283342 - Many windows don't set window classes

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Stewart]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220

A number of windows (such as the "Security Warning" dialog, the "Confirm Setting
Cookie", the "Cookie Manager", and others) do not set their window classes as
specified in the XUL files ( windowtype="..." ).

This is frustrating because it means the windows can't be tagged by type by the
active window manager for different treatment, such as "don't automatically take
focus" (so my typing doesn't allow a few cookies, surf through various security
zones, and eat my words, among the other effects I've seen), or "confine to page X".

This is also frustrating when error messages pop up and are dismissed without
being read because the user is typing at the time.

Why aren't the "windowtype=" declarations for these windows being honored?  From
my reading, this should be the appropriate means to tag window classes to these
windows...


Reproducible: Always

Steps to Reproduce:
1. Go to any web site that will ask about cookies being added or modified (i.e.
either someplace you haven't been yet or where individual cookies are
specifically accepted or rejected).
2. While the page is loading, go do something else, such as responding to
someone's e-mail.
3. Try to find the cookies that were added while you were hitting the enter key
in your e-mail typing.  There may be many that you didn't notice (space -> same
for all cookies from this site, enter -> allow).

Actual Results:  
Minimum one frustrated user.  (In my case, at least 2 frustrated users, as I'm
not the only person at this site who is becoming very frustrated with this
behavior.)


Expected Results:  
By all means, pop up the window, but I want to have the choice of having my
window manager treat it differently.  In my case, as noted above, I have a "Do
not autofocus" option I'd like to apply, plus a "play specific sound file upon
appearance" option (cookie questions are very different to me from DNS server
failure messages).

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Stewart]

As of the 20050928 trunk version, Mozilla behaves worse than it did in version
1.7.11.  As of this version, it appears that ALL windowtype= settings are being
ignored, rather than just many (in 1.7.11).

For reference, this is the command line I gave to configure:
> ./configure --prefix=/usr/local/mozilla-trunk --enable-crypto --enable-ctl
--enable-extensions --disable-installer --enable-strip --enable-reorder
--disable-freetype2 --enable-xft --disable-debug
--with-user-appdir=.mozilla-trunk --enable-application=suite


(BTW, an easy way to tell what class has actually been assigned to a window with
WindowMaker is the "Attributes" menu option off the title bar.)

Comment 3

[Stewart]

Attachment: Patch to add a window class to the Default Plugin's window

I'm just starting to learn X programming, and I've found that the Default
Plugin was only missing a single statement to assign a window class using GTK
(which seems to be required by the plugin... hmmm...).	This patch adds this
single line, and works on the most recent trunk version I have (20050928).

I believe I've worked out why no windows get classes any more for me on the new
trunk version -- the configure script detected GTK2, which (unlike GTK1) seems
to have no provisions for setting the window classes.

I can't see any options I can set to get configure to compile for my GTK1
libraries.

Additionally, trying to read the GTK2 widget source directory isn't getting me
anywhere in understanding where the "SetWindowClass" function definition should
be placed... so I doubt I'll be capable of writing a patch to add this in.

Comment 4

[Stewart]

Attachment: Adds windowtype= to a variety of dialogs/windows

I tried to add windowtype= to all the dialog boxes (I could find...) that can
pop up without warning, or that I usually want to treat specially -- this patch
is the result.

If nothing else, I hope this gives an idea of just how many different kinds of
popups separate window classes can be useful for.

Comment 5

[Jo Hermans]

Confirmed because a patch was added (but that's no garantuee that it will be used)

Comment 6

[Stewart]

Attachment: Adds GetWindowClass and SetWindowClass implementations to GTK2 widget

OK, I've finally worked out how to add functions to the GTK2 widget code for supporting the SetWindowClass and GetWindowClass functions.

The code itself is basically copied and adapted from the corresponding GTK1 widget code, and it seems to work on Seamonkey 1.0.

Comment 7

[Mike Connor [:mconnor]]

Comment on attachment 197950 [details] [diff] [review]
Patch to add a window class to the Default Plugin's window

I'm really not the right guy to review this, if its even still relevant (suspect not, but...)

Comment 8

[Stewart]

It is still relevant to me.

I use the window classes to prevent some windows from taking focus (which is useful whenever I'm typing things with spaces in them, especially), to make windows omnipresent (so I can respond to cookie
dialogs as they appear, even if I'm on another workspace), to float or sink some windows, etc..

Just because I have the GTK2 library installed on my system doesn't
mean my chosen window manager doesn't rely on window classes.

This bug is about both the plugin and the GTK2 widget library section
I think it still applies to the newest Seamonkey source...

:waves at Mike,
Who is supposed to review my patch?

Comment 9

[timeless]

Comment on attachment 197950 [details] [diff] [review]
Patch to add a window class to the Default Plugin's window

this is for the default plugin which is essentially a sample that others copy. it doesn't affect firefox releases as we don't use it.

Comment 10

[Damon Sicore (:damons)]

This doesn't need approval.  Once reviewed, land at will.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 197950 [details] [diff] [review]
Patch to add a window class to the Default Plugin's window

blanket-a=beltzner for when it's reviewed

Comment 12

[Reed Loden [:reed]]

I'm not sure if this bug is finally fixed currently, so if it is, please resolve it.

Checking in modules/plugin/samples/default/unix/nullplugin.c;
/cvsroot/mozilla/modules/plugin/samples/default/unix/nullplugin.c,v  <--  nullplugin.c
new revision: 1.18; previous revision: 1.17
done

Comment 13

[Benjamin Smedberg]

The default plugin is gone.