Closed Bug 9999 Opened 25 years ago Closed 25 years ago

Closing Apprunner window fails to terminate relevant Open Location dialog

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Crysgem, Assigned: law)

Details

Apprunner Build of July 15 (ftp://ftp.mozilla.org/pub/mozilla/nightly/1999-07-15-13-M9/mozilla-win32.zip). 0) Execute Apprunner. 1) Open a new window (such that two Apprunner windows now teem upon your tray). 2) Select the "Open File or Location..." dialog from the File menu in the first window. 3) Close the first window (the "Open Location" is now "orphaned", or made irrelevant, if you will). 4) Input a URL into the "Open Location" dialog, Enter it. The results vary - a crash, an abrupt (but controlled) termination of Apprunner, or no application response (that the user may discern). These results, however, are of no user relevance - closing the "invoking" main browser window of an Open Location dialog should also terminate that dialog.
Component: HTML Dialogs → XPApps
reassing to Mr.Law although it sounds to me this might be a modality issue.
Assignee: davidm → law
Status: NEW → ASSIGNED
Accepting bug. I think this will require some xptoolkit support. I'll find out if they've got a bug for this and adjust this one. later.
Target Milestone: M10
Moving to M10; needs to deal with some xptoolkit modality issues.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Still a problem in the 1999101909 build, NT. To reproduce: - Launch apprunner - Select File | New Navigator Window - Switch back to the original apprunner window - Select File | Open File - Close the spawning window Result: All windows close and the app quits Expected result: The Open dialog should be modal (that is, you shouldn't be able to close its parent).
Assignee: law → danm
Status: REOPENED → NEW
I'm reassigning this to Dan. The suspicion is that it's a problem with setting the dialog "parent" to the "client area" of the parent window, rather than to the outermost top-level window. The modality causes the parent to be disabled, but because the parent is a child of the outer-window, the outer-windows other children (menu, close box, etc.) are still enabled. This bug applies to both Linux and Windows. Haven't tried the Mac.
mass-moving most m11 bugs to m12
Mass-moving non-PDT+ bugs to M13
Assignee: danm → law
Things have changed. We now use nsIFileSpecWithUI which isn't modal (see bug 5708). When I've fixed that one, I'll look at this issue again and we'll solve it if this quirk reappears. To clarify, my previous comment was addressing the fact that even after making the dialog modal, the parent window was still partially enabled.
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
I would declare this issue resolved to a user-forgetful satisfaction, as functions the 1999122108 build. [Resolving--Fixed]
Status: RESOLVED → VERIFIED
yup, works fine in the 1999122308 build. thanks for marking it fixed, crysgem!
Product: Core → Mozilla Application Suite
Flags: sec-bounty?
Flags: in-qa-testsuite+
Flags: sec-bounty?
Flags: in-qa-testsuite+
You need to log in before you can comment on or make changes to this bug.