10000 - Potential interface confusion re: HTMLDialog windows

Status: VERIFIED DUPLICATE of bug 6783

(Core :: XUL, defect, P3)

Description

[Crysgem]

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.

Comment 1

[Matthew Tuck [:CodeMachine]]

Bug 10000 - I'd say congrats to the reporter, but I don't know if its something
anyone should be proud of.  =)

Comment 2

[shuang (gone)]

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.

Comment 3

[german]

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!

Comment 4

[davidm]

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.
[e-mail] is responsible for this code if it needs to be updated to use
either open or opendialog.

Comment 5

[german]

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

Comment 6

[german]

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

[Bill Law]

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."

Comment 8

[Bill Law]

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.

Comment 9

[Peter Trudelle]

that would be sdagley, reassigning.

Comment 10

[Steve Dagley]

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.

Comment 11

[Peter Trudelle]

mass-moving most m11 bugs to m12

Comment 12

[Sean Richardson]

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

[Sean Richardson]

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

[Peter Trudelle]

Mass-moving non-PDT+ bugs to M13

Comment 15

[Steve Dagley]

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 ***

Comment 16

[cpratt]

Verifying as duplicate.

Comment 17

[nagaraju]

Attachment: nothing to write here

Comment 19

[Pulsebot]

Backout:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bcc6422389f0

Comment 20

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: try: -b o -p linux64-pgo,macosx64,win64-pgo -u none -t other-e10s mozharness: --geckoProfile --geckoProfileInterval 10000

Review commit: https://reviewboard.mozilla.org/r/240404/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/240404/