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)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED
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.