Closed Bug 10000 Opened 21 years ago Closed 21 years ago
Potential interface confusion re: HTMLDialog windows
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. =)
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.
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!
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. firstname.lastname@example.org is responsible for this code if it needs to be updated to use either open or opendialog.
Thanks David. I'll see that I can change that before m11. + G
Bill: 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."
Assignee: law → trudelle
Status: ASSIGNED → NEW
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.
that would be sdagley, reassigning.
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
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
Status: ASSIGNED → RESOLVED
Closed: 21 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 duplicate *** This bug has been marked as a duplicate of 6783 ***
Verifying as duplicate.
Attachment #8971639 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.