Closed Bug 55977 Opened 24 years ago Closed 22 years ago

File save/open dialogs should not be app modal.

Categories

(Core Graveyard :: File Handling, defect, P3)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: braden, Assigned: bryner)

References

Details

(not sure if this is the correct component)

The "Save file" dialog comes up modal. I don't see any reason why this should be
a modal dialog.
->future
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Same for "file open" dialogs.
Summary: "Save file" dialog should not be modal. → File save/open dialogs should not be modal.
Target Milestone: Future → ---
Target Milestone: --- → Future
The real problem here is that these dialogs are app-modal rather than window-modal.
Summary: File save/open dialogs should not be modal. → File save/open dialogs should not be app modal.
That is unfortunate, but it still doesn't fit the profile for N6.

I'm not sure what you're suggesting; this is a Mozilla bug.

I'm not suggesting anything, just saying that we, the assignees, will not fix
this in time for Netscape6.  ->bryner
Assignee: trudelle → bryner
Status: ASSIGNED → NEW
Oh, of course. I knew that. :-)

Hm... Perhaps your comment arose from the fact that I goofed during a Bugzilla
collision and inadvertently overwrote some of the modifications you'd made. I
put the "Future" back (I thought), but perhaps I missed something else...

Braden, can you note your window manager, because these dialogs are window 
modal when running under gnome/enlightenment.
I'm using Sawfish.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0
This is a dupe of 65521 or 65521 is a dupe of this.
This bug is more specific than bug 65521. I'm making this bug depend on that one.
Depends on: 65521
*** Bug 85669 has been marked as a duplicate of this bug. ***
*** Bug 100537 has been marked as a duplicate of this bug. ***
*** Bug 101099 has been marked as a duplicate of this bug. ***
hmm i marked a Mac bug dup - is this one linux only?
->file handling. taking qa contact [for the nonce].
Component: XP Toolkit/Widgets → File Handling
QA Contact: jrgm → sairuh
Target Milestone: mozilla1.0 → mozilla1.1
*** Bug 112134 has been marked as a duplicate of this bug. ***
Based on the bugs that have been marked as dups of this one, shouldn't OS be
changed to all?

I'm seeing the same thing on win2k with 2001112603
actually Bug 112134 isn't a dup of this one (reopening it). On windows, the 
File->Save, etc., dialog, while modal, is _window_ modal, not _app_ modal.
This bug is really Linux only, and is requesting that the dialog be (at least)
window modal.

(As for the Mac dup, I didn't read it, but on OS 9.0, convention is that all 
dialogs are app modal. mozilla's just bowing down to the Gods of the HIG in 
being app modal as well on OS 9).
should the dialog boxes be window modal or tab modal?  If I have multiple tabs
in the same window, I really want a file open/save as dialog box to affect only
that tab.
Found an inconsistancy in Open/Save.
Seems Open/Save - dialog is treated in another way than the "Select Filename"
dialog.

This is especially obvious on WindowMaker when setting "Open dialogs in same
workspace as their owners."

The first dialog does not honor this but the second "Select filename" does.

1. Open a file that will open the dialog for opening or saving the file.
2. Switch to another workspace before dialog has appeared
3. Choose the save option

Expected results:
The Select Filename - dialog should appear in the same workspace as the previous
dialog.

Acctual results:
The Select Filename - dialog appears in the workspace with the window with the
link that caused the first dialog to open.

This is really confusing and I think both dialogs should operate in a similar way.

However just a cosmetic+ issue AFAIAC.

Build: 2002021810
This bug is fixed now that modality on linux is non-broken (per clarification in
comment 3). It was fixed by bug 65521.  Comment 21 is actually referring to bug
135736
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
vrfy'd fixed using 2002.09.19.08 comm trunk build on linux rh7.2. per comment
21, the actual results i saw matched the expected results.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.