Closed Bug 280518 Opened 20 years ago Closed 16 years ago

Activity selection box remains on top of file selection box

Categories

(SeaMonkey :: Download & File Handling, defect)

Product:
SeaMonkey
Component:
Download & File Handling
Version:
SeaMonkey 1.1 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: axel.braun, Assigned: iamawalrus)

References

Details

(Keywords: regression)

Attachments

(2 files)

Screen shot with file and selection dialog open
199.47 KB, image/png
Details
patch
1.27 KB, patch
bzbarsky
: review-
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050120 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050120 This behaviour is new compared to 1.7.5: Select a file to download, e.g. from a FTP-Server. A selection box appears, asking what to do with this file: Open with blabla or save to disk. select 'save to disk', the file selection dialog opens *but* the first selection box remains on top of the file selection box, and it still reacts on clicks. If you click it agian you are not able anymore to select a file, it seems all to be messed up. Reproducible: Always Actual Results: Activity box stays on top of fiel selection dialog Expected Results: destroy the activity box when opening the file selection box.
Which exact build are you using? GTK1 or GTK2? Which filepicker do you get -- the XUL one or the GTK2 one?
This is a good question, where can I see the file picker? The file from which I installed was mozilla-i686-pc-linux-gnu-full-installer.tar.gz dated 26.01.2005
That sounds like the GTK1 build (check in about:buildconfig whether gtk2 is set?), so the XUL filepicker....
I don't see this in my build, my picker is modal to the helper app dialog.
about:buildconfig Build platform target i686-pc-linux-gnu Build tools Compiler Version Compiler flags gcc gcc version 3.2.3 -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pthread -pipe c++ gcc version 3.2.3 -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -I/usr/X11R6/include Configure arguments --enable-application=suite --disable-tests --enable-extensions=default,irc,tasks,negotiateauth --without-system-nspr --without-system-jpeg --without-system-zlib --without-system-png --without-system-mng --disable-debug '--enable-optimize=-O2 -gstabs+' --enable-crypto does that help?
verified on today's build (2005021305): bug still valid
What windowmanager, if I may ask?
KDE 3.3.2 Level a (SuSE build)
That's the desktop environment. What window manager are you using with it?
Not sure where I can look this up, but I assume it is XDM.
I really doubt people use anything other than KWin with KDE...
Nah, XDM isn't the window manager either (it's the login prompt and x display manager). If I can get KDE to work here (it seems to have had issues all along, I'll try kwin). In the meantime, if reporter could try a different windowmanager and report the results, that would be useful. I really can't think of what could have changed here from 1.7.3 to 1.7.5, though....
tried with fvwm, works as designed. So, it seems to be an issue together with KDE. As far as I remember, version 1.7.5 worked fine.
Oh, this is between 1.7.5 and a current trunk build? All sorts of stuff has changed there... ;) Can you possibly narrow down the regression window using the 1.8a releases and http://archive.mozilla.org ?
Quite difficult to use the archive, as it is not visible what an 1.8 release is or in which subdir to find a workable package. I tried Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a4) Gecko/20040908 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041119 This release worked fine. BUT: I d'ld the latest nightly builds Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050218 from the archive mozilla-i686-pc-linux-gnu-gtk2+xft.tar.gz works fine, whereas the full-installer mozilla-i686-pc-linux-gnu-full-installer.tar.gz shows the faulty behaviour.
Axel, does 1.8a6 also work fine? Or does it show the problem?
I tried the full-installer package: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050111 shows the bug
OK. Could you try archived builds from between 1.8a5 and 1.8a6 to see how far you can narrow this down?
The issue seems to be more on the distribution version: As for the current build the full-installer version shows the problem I flipped through some hundred directories on the archive. The last full installer version was Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041105, which shows still the problem. So, the relevant change must have been before, but I couldnt find a full installer for an earlier version.
Wait. So you're seeing the problem with installer builds but not tarballs?
see my comment #15
In comment 15, the full installer build you tested was GTK1, while the tarball was GTK2, no? It sounds more likely that the difference is between the toolkits, not between tarball and installer.
Good question ;-) I have no idea whats inside the full-installer package (except that I expect Moz inside). So, if you can point me to an earlier tarball from gtk1 on the archive for testing, thats fine. I'm using moz to browse the archive, but it is not very comfortable as you cant open all subdirectories on a command...and the line seems to be thin to europe.
http://archive.mozilla.org/pub/mozilla/nightly/2004-12-08-07-trunk/ seems to have a GTK1 tarball (as well as full installer). Do those show the problem?
see comment 20, I tried an even oder one (20041105) which did *not* fix the problem
Hmm... but in comment 16, you said that "rv:1.8a5) Gecko/20041119" worked. Was that a GTK2 build?
yes, was a gtk2
OK... What about the 1.8a4? If that was also GTK2, could you test the GTK1 one?
I ooked through all trunk-folders of october and through most of July and August, but couldnt find a full installer build....
Ugh. Archive is worse than I recalled it being.... :( I put some GTK1 tarballs up at http://web.mit.edu/bzbarsky/Public/mozbuilds/ Let me know what testing shows with those?
all versions from your directory show the bug.
OK... does the GTK1 version of 1.7.5 also show the bug, then?
No, I downloaded and installed various 1.7.5 from the full installer, they all worked fine.
OK. But GTK1 1.8a4 shows the bug, I hope? (It's later than the first build that I put up....) If so, what about GTK1 1.8a3, 1.8a3, 1.8a1?
yep, tested all four packages you put up.... can you also put one up for 1.8a1-3? Thx
1.8a2 works fine, 1.8a3 has the bug
I've put 4 more builds in that range at <http://web.mit.edu/bzbarsky/Public/mozbuilds/> (well, they'll be up in the next 10-15 minutes). Could you test those? Also, I finally got kwin working, and it's not showing the problem here. :(
Well, those bugs you cant reproduce are the best ones 8-| Anyway, tried on a second machine (KDE 3.3.2 Level a, SuSE 9.1) with the same result: 07-15 is OK 08-01 is NOT OK
Ok.. I put up three more builds (07-19, 07-23, 07-27). Could you try those? With a small enough date range, I may be able to figure out what checkin caused the problem...
07-19 is already showing the bug Success!
Hmm... about 25000 lines of code changed in those 4 days. None of the changes really leap out at me.... I put up the builds for 07-16, 07-17, 07-18 in the same place. Could you test those? Maybe if we get this down to one day....
Blocks: 284082
tried 07-17 and 07-18, they are OK
List of checkins between 2004-07-18-07 and 2004-07-19-08 (plus 2-hour window on each side): http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-07-18+05%3A00%3A00&maxdate=2004-07-19+10%3A00%3A00&cvsroot=%2Fcvsroot I still don't see what in there could be causing this... There are no GTK widgetry changes, no XP window positioning or whatnot changes... biesi, do you have any idea?
hm... sorry... I don't see anything suspicious either... anyone wanna do a binary search through all those patches? :-)
looks like a difficult one :-( I've just installed all different versions on a different machine, and from the ones uploaded to http://web.mit.edu/bzbarsky/Public/mozbuilds/ it looks like 07-19 is still OK, but 07-23 fails. I know this is different to what i reported before (my apologies) but I dont have the other machine available at the moment to verify. Some more versions from in between?
I've uploaded 07-20, 07-21, 07-22 builds.
07-22 and earlier are OK, 07-23 failed
Blocks: 194323
OK. In that range, and given that it's toolkit-dependent, it's likely caused by bug 194323. Over to patch author of that bug. ccing people familiar with GTK widgetry.
Assignee: download-manager → robin.lu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b2?
*** Bug 284082 has been marked as a duplicate of this bug. ***
Flags: blocking-seamonkey1.0a?
Attached patch patch — — Splinter Review
we might need to define the relationship of these windows/dialogs explicitly.
Attachment #178764 - Flags: review?(bzbarsky)
Comment on attachment 178764 [details] [diff] [review] patch No, this is wrong. The parenting is done the way it's done for various reasons of dubious quality, but just changing it without changing other things in the helper app back end isn't going to work. So the situation is that we're opening a dialog modal to the browser window; why is that causing both the browser window and the modal dialog to be below this other dialog parented (but _not_ modal) to the browser window? That didn't use to happen, so clearly we changed something to cause it to happen.
Attachment #178764 - Flags: review?(bzbarsky) → review-
helperAppDlg is parent to null. So the dialog modal to the browser window can be below of it. BTW, when using metacity as window manager, no matter if the patch of bug 194323 exists, the helperAppDlg can always be on top of the filepicker and clickable. I tested with both gtk1.2 and gtk2 build.
> helperAppDlg is parent to null. Ah, yes... I forgot that part. > So the dialog modal to the browser window can be below of it. It _can_, but it didn't _use_ to be, unles the user put it there. The behavior used to be (and this is the same behavior I observe currently with my kwm version) that the browser window was brought up on top of the helper app dialog, with the modal dialog on top of the browser window. This behavior changed at some point, only for gtk1 builds (not gtk2). The regression window indicates bug 194323 as being the most likely culprit. So just to make it clear, we're talking about what happens when you click the "ok" button on the helper app dialog, not about the various and sundry states the user can put the windows into.
Let me explain what I have changed in bug 194323. Before the patch, dialogs without parents set their transient to null which means, in metacity, on top of every windows of the application. It made the preferences panel always on top of the dialog invoked in it. The patch changed the behavior by making the dialogs without parent grouped in a gdk window group by itself so that it won't block any other dialog. I test mozilla 1.7.6 gtk1.2 build with metacity. After I clicked "ok", the filepicker came to the top. Is it the right behavior we expect?
> It made the preferences panel always on top of the dialog invoked in it. But preferences is a window, not a dialog, no? At least for SeaMonkey; for Firefox it depends on a preference value. If that's not done correctly, _that_'s what should be fixed. > The patch changed the behavior by making the dialogs without parent grouped in > a gdk window group by itself so that it won't block any other dialog. But in the case described in this bug, it actually caused the helper app dialog to cover up the filepicker dialog by default. > After I clicked "ok", the filepicker came to the top. Yes. The expectation is that the filepicker will be the topmost mozilla window after it's opened. There is no real expectation as to the relative ordering of the browser window that the filepicker is parented to and the helper app dialog window...
Note that the Windows window code uses the "dialog" style to determine whether to suppress the display of the system menu, minimize box and maximize box, while the Mac also uses it as a cue to suppress the maximize and close boxes.
(In reply to comment #57) > But preferences is a window, not a dialog, no? It is a dialog. http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/utilityOverlay.js#262 > But in the case described in this bug, it actually caused the helper app dialog > to cover up the filepicker dialog by default. If you don't think we should explicitly build up the parentship for these windows, I believe it could be a bug of the window manager. The only thing I changed in the patch is to group the dialog without parent to a gdk window group. The window manager the reporter were using may have some different treatment to gdk window group other than the metacity. cc hp for his opinion.
> It is a dialog. That would seem to be a bug. As for the rest, I don't pretend to understand GTK window groups. I'm just trying to get this bug resolved one way or another... ;)
I'm not 100% sure I know what's going on here, but let me be sure I have the situation right from WM point of view. Prior to patch: 1. Main Window, group leader A, transient parent None, type NORMAL 2. Helper App Dialog, group leader A, transient parent 1, type DIALOG 3. File Chooser Dialog, group leader A, transient parent None, type DIALOG Patch changes: - file chooser has itself as group leader, since transient parent is None? If I got all that right, then what you're telling the window manager by changing the group leader on the file dialog is: "this file dialog is a separate application (or main window group at least) from the mainwindow + helper dialog" What that should imply is that the file dialog has no stacking constraints with respect to the other two windows. I don't _think_ this should effect the initial stacking of the file dialog, but it might in the latest GNOME (2.10) because of the "focus stealing prevention" which is supposed to keep something like Gaim from grabbing focus on new IM messages. IIRC there's an exception where if an app is focused and it opens a dialog, that dialog always gets focus; but changing the group leader would defeat this exception since from the WM point of view you suddenly have a new app that's being opened, not a dialog in an existing app. Given the age of this bug, GNOME 2.10 sounds unlikely though. Let me clarify a terminology point just to avoid confusion: the word "modal" in the window manager specs refers to whether a dialog disables input to other windows in the app; this should be orthogonal to whether the dialog has a parent (is transient for another window).
> That would seem to be a bug. I argued about this in a bug once. Some one told me, if all the changes apply after the ok is clicked, it should be a dialog. As far as I can remember. Do you think we can change the parent of filepicker to the helper app dialog to resolve this bug? It is reasonable. By this, user also can not bring the helper app dialog to the top and click the "ok" to get another filepicker, which is also a bug.
hp, come correction: Prior to patch: 1. Main Window, group leader A, transient parent None, type NORMAL 2. Helper App Dialog, group leader A, transient parent _None_, type DIALOG 3. File Chooser Dialog, group leader A, transient parent _1_, type DIALOG Patch changes: - helper app dialog has itself as group leader, since transient parent is None. In metacity, when file chooser is invoked, it comes to the top of 1 and 2, which is what we expect. But in some wm, as bz tested with gtk1.2 build on kwm, file chooser comes below 2.
> Do you think we can change the parent of filepicker to the helper app dialog to > resolve this bug? Like I said, not without changing a bunch of stuff in the helper app back end. We have bugs on those issues. > which is also a bug. And filed. May be worth reading....
If the bug only happens with kwin we should probably ask Lubos about it, though I'm not sure it's a kwin bug. My guess is that because the WM thinks there are two separate apps it tries to keep the windows for a given app together and causes the problem, or something like that. Which is potentially reasonable behavior, given the info the WM has...
MoFo shipped a couple of alphas and even a beta with this bug, so given that noone is working on this actively, as it seems, this can't block the SeaMonkey 1.0 Alpha release. If there's active work and it's still annoying, please consider to re-nominate for beta or final once alpha is out.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-
Im voting for this bug too, Im seeing in the SeaMonkey 1.0s/1.1a gtk1 builds from 7-3-2005 to present, also in gtk1 tinbox-builds. http://img300.imageshack.us/my.php?image=seamonkeybug0hy.jpg SuSE Linux 9.2 Pro - kernel 2.6.8-24 - machine x86_64 - KDE 3.3.0
*** Bug 309414 has been marked as a duplicate of this bug. ***
Can you reproduce with SeaMonkey v1.1.9 ? Can you reproduce with SeaMonkey v2.0a1pre ? Robin, Are you still working on this ?
Keywords: regression
Version: unspecified → SeaMonkey 1.1 Branch
Works for me with SeaMonkey 2.0 Beta 1 and later.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: