Closed Bug 10000 Opened 23 years ago Closed 22 years ago

Potential interface confusion re: HTMLDialog windows


(Core :: XUL, defect, P3)

Windows 98





(Reporter: Crysgem, Assigned: sdagley)




(1 file, 1 obsolete file)

Presumably, this design flaw (witnessed by the
copy) would apply to OS other than Win32.


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

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.  =)
Assignee: shuang → german
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.
Assignee: german → davidm
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!
Assignee: davidm → german
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. is responsible for this code if it needs to be updated to use
either open or opendialog.
Target Milestone: M11
Thanks David. I'll see that I can change that before m11.
+ G
Assignee: german → law
Can you verify or check that the open dialog is modal? It should be!
If/once it the bug can be closed.
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."
QA Contact: claudius → cpratt
Assignee: law → trudelle
Component: UE/UI → XP Toolkit/Widgets
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.
Assignee: trudelle → sdagley
that would be sdagley, reassigning.
Depends on: 6783
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.
mass-moving most m11 bugs to m12
Blocks: 19221
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.
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.
Mass-moving non-PDT+ bugs to M13
No longer blocks: 19221
Closed: 22 years ago
Resolution: --- → DUPLICATE
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

*** This bug has been marked as a duplicate of 6783 ***
Verifying as duplicate.
Attached file nothing to write here
Duplicate of this bug: 394420
You need to log in before you can comment on or make changes to this bug.