Closed Bug 283342 Opened 18 years ago Closed 10 years ago
Many windows don't set window classes
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).
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/
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 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.
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)
Status: UNCONFIRMED → NEW
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.
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...)
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.
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+
Assignee: general → nobody
Component: XP Apps → Plug-ins
Product: Mozilla Application Suite → Core
QA Contact: general → plugins
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
Target Milestone: --- → mozilla1.9beta5
The default plugin is gone.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.