Potential interface confusion re: HTMLDialog windows

VERIFIED DUPLICATE of bug 6783

Status

()

defect
P3
normal
VERIFIED DUPLICATE of bug 6783
20 years ago
Last year

People

(Reporter: Crysgem, Assigned: sdagley)

Tracking

Trunk
x86
Windows 98
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

20 years ago
Presumably, this design flaw (witnessed by the
ftp://ftp.mozilla.org/pub/mozilla/nightly/1999-07-15-13-M9/mozilla-win32.zip
copy) would apply to OS other than Win32.

Procedure:

0) Cease thinking as a programmer and cast your mind into the naive user's for a
(painful) moment.
1) Execute Apprunner.
2) Open a new window; two Apprunner windows are now loaded.
3) From the "File" menu, in the first window, select the "Open File or
Location..." dialog.
4) Repeat action in the second window.

On the MS taskbar, two "Open Location" dialogs now strut. The user who fails to
close one window, or performs other tasks between the dialog invocations, or the
user who FORGETS may be challenged [ >;+) ] to relate each dialog with it's
caller window.
A keeper of ordering numbers is needed. It has been humbly suggested (in Bug
8033) that Mozilla should be watchful of where it permits it's tail to sway -
that is, should maintain discipline over all of the multiple windows that may be
opened by the user. A mechanism to identify each Mozilla browser window would
seem necessary. Implemented, a simple numerical identification (main window 1,
main window 2, Wallet HTMLDialog 1.1) of each "invoking" browser window would
permit the user to identify the associations between the dialogs and the
"invoker".

This thinking may be aided if you assume the programmer's mind once more.
Bug 10000 - I'd say congrats to the reporter, but I don't know if its something
anyone should be proud of.  =)

Updated

20 years ago
Assignee: shuang → german

Comment 2

20 years ago
assign to german for evaluation: do we need or should we make any changes as
suggested? any other way to make this work the way it should (in a "normal"
user's mind)? It may take us long time to get there, though.

Updated

20 years ago
Assignee: german → davidm

Comment 3

20 years ago
Correct me if I am misunderstanding but I think the core of the problem is that
Open file has to become a modal dialog , in that users have to complete the
action of opening a file (a cancelling out of it) before they even will be able
to open a new Nav window or switch to another Nav window. I think that's the
core of the problem. Once you have that you'd avoid the situation described in
this bug.
I am assigining it back to David Matiskella, maybe he can tell me what I need to
do in order to open this dialog in a modal way from JS. David feel free to
assign back to me once modal is working and once I can change that window call
to be modal. Let me know what the syntax is. Thanks!

Updated

20 years ago
Assignee: davidm → german

Comment 4

20 years ago
I agree with German that the whole problem is that the window is not modal. The
window can be made modal by adding  "modal" to the list of window features in
either openDialog or open. It should as of m9. Reassigning back to german.
law@netscape.com is responsible for this code if it needs to be updated to use
either open or opendialog.

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M11

Comment 5

20 years ago
Thanks David. I'll see that I can change that before m11.
+ G

Updated

20 years ago
Assignee: german → law
Status: ASSIGNED → NEW

Comment 6

20 years ago
Bill:
Can you verify or check that the open dialog is modal? It should be!
If/once it the bug can be closed.

Comment 7

20 years ago
I've got good news and bad news.

The good news is that the "Open Web Location..." dialog is indeed "modal" now.

The bad news is that the "Open File..." menu choice opens a file picker that is
not modal so we're back in the same boat.

The file picker is being opened via some xpconnect service and I'm not sure it
can do "modal."  We either need to attach that problem to this bug and get it
assigned to the right person, or, open a new bug.

The component in question is "nsIFileSpecWithUI."

Updated

20 years ago
QA Contact: claudius → cpratt

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Assignee: law → trudelle
Status: ASSIGNED → NEW
Component: UE/UI → XP Toolkit/Widgets

Comment 8

20 years ago
I'd like to get this assigned to the owner of the file picker widget.  When the
file widget is up to it, then fire this back and I'll modify the code that calls
it to do so in a way that makes the file picker dependent or modal.

Updated

20 years ago
Assignee: trudelle → sdagley

Comment 9

20 years ago
that would be sdagley, reassigning.
Assignee

Updated

20 years ago
Depends on: 6783
Assignee

Comment 10

20 years ago
This bug is essentially a duplicate of 6783 (although I'm marking it as a
dependency).  To restate the problem, on Windows and Linux you need to be able to
provide some sort of parent window ID for the non-modal file dialog so that the
association with the parent can be maintained.  How one can get this parent
window ID is the big question nobody seems to be able/willing to answer.  cmanske
proposed adding this to nsIDOMWindow but that never got pursued.  I'm going to
bring this up a a pork jockey topic so we can get some traction.
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 11

20 years ago
mass-moving most m11 bugs to m12

Updated

20 years ago
Blocks: 19221

Comment 12

20 years ago
The potential confusion envisaged by the reporter no longer seems possible,
as the "Open Web Location" dialog no longer makes an appearance on the
Taskbar or the task list, and the dialog is raised to the top whenever
the parent window is displayed. (Are there any other dialogs that might
need to be put on the Taskbar and then related back to their parents?)

However, the modality added to that dialog is causing a serious Usability
misfeature, as described in bug 19221 - other Mozilla windows are not
blocked from appearing, just from listening, giving the appearance of a
frozen App. Adding dependency.

Also, if any other dialog on which a parent window is waiting *does* appear
on the taskbar, the behaviour described under Additional Information in
bug 19921 seems a better way to avoid confusion than using numbering
correspondences. Quoting:

>B. If a dialog windows that a main window is waiting on is
>   given focus, it should first signal its parent to display
>   itself at the top of the window stack before displaying
>   itself at the top.
> ...
>B. may never in fact be needed. The only dialog I can think of that
>Communicator places on the Taskbar (and task list) where it
>can be independently reached is the "Saving Location" Dialog
>(the one after the "Save Page As" dialog), which has effectively
>been cast off - neither the parent window nor the child need to
>keep tabs on one another.

If B. as described *is* needed, this bug report is still meaningful,
otherwise it can probably be closed.

Comment 13

20 years ago
At present File>Open File does not bring up an HTMLDialog at all, but
a native Win32 file picker dialog. The interface confusion does exist
in this case, in practice, if more than one are waiting on the user's
final selection at once, as that dialog is completely independent
in the window z-order from its parent browser window.

Also, even with only one browser window it is possible to get more than one
such dialog launched and showing on the taskbar at once, and they all work.
But the point may be moot as they also all open the file in a new window,
so the dialog has no real relation back to its parent browser window.
Will that (viewing in new window) be continuing?

Tested with: 1999-11-17-17-M12 nightly build on Windows NT 4.0sp3.

Comment 14

20 years ago
Mass-moving non-PDT+ bugs to M13

Updated

20 years ago
No longer blocks: 19221
Assignee

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Assignee

Comment 15

20 years ago
Now that the multi-dialog path to opening a file has been eliminated from the UI
this bug has now been reduced to being a duplicate of #6783.  Closing as a
duplicate


*** This bug has been marked as a duplicate of 6783 ***

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 16

20 years ago
Verifying as duplicate.

Comment 17

15 years ago

Updated

12 years ago
Duplicate of this bug: 394420
You need to log in before you can comment on or make changes to this bug.