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)
Tracking
(Not tracked)
VERIFIED
FIXED
M13
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.
reassing to Mr.Law although it sounds to me this might be a modality issue.
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.
Moving to M10; needs to deal with some xptoolkit modality issues.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
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).
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.
Comment 6•25 years ago
|
||
mass-moving most m11 bugs to m12
Comment 7•25 years ago
|
||
Mass-moving non-PDT+ bugs to M13
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 ago → 25 years ago
Resolution: --- → FIXED
I would declare this issue resolved to a user-forgetful satisfaction, as
functions the 1999122108 build.
[Resolving--Fixed]
Comment 10•25 years ago
|
||
yup, works fine in the 1999122308 build. thanks for marking it fixed, crysgem!
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•3 years ago
|
Flags: sec-bounty?
Flags: in-qa-testsuite+
Updated•3 years ago
|
Flags: sec-bounty?
Flags: in-qa-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•