Closed Bug 280518 Opened 20 years ago Closed 15 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: 15 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: