Closed Bug 283342 Opened 19 years ago Closed 11 years ago

Many windows don't set window classes


(Core Graveyard :: Plug-ins, defect)

1.7 Branch
Not set


(Not tracked)



(Reporter: sandreas41, Assigned: sandreas41)


(Whiteboard: [not needed for 1.9])


(2 files, 1 obsolete file)

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

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

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).
Version: unspecified → 1.7 Branch
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:
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.)
Component: General → XP Apps
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

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.
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.
Confirmed because a patch was added (but that's no garantuee that it will be used)
Ever confirmed: true
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.
Attachment #197950 - Flags: review?(mconnor)
Attachment #197952 - Flags: review?(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...)
Attachment #197950 - Flags: review?(mconnor)
Attachment #197952 - Flags: review?(mconnor)
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 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.
Attachment #197950 - Flags: review?(jst)
Attachment #197950 - Flags: approval1.9?
Attachment #215701 - Attachment is obsolete: true
This doesn't need approval.  Once reviewed, land at will.
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
Attachment #197950 - Flags: approval1.9? → approval1.9+
Attachment #197950 - Flags: superreview+
Attachment #197950 - Flags: review?(jst)
Attachment #197950 - Flags: review+
Assignee: general → nobody
Component: XP Apps → Plug-ins
Product: Mozilla Application Suite → Core
QA Contact: general → plugins
Assignee: nobody → sandreas41
Keywords: checkin-needed
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
Keywords: checkin-needed
Target Milestone: --- → mozilla1.9beta5
Whiteboard: [not needed for 1.9]
The default plugin is gone.
Closed: 11 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.