9582 - "Open File or Location" problems

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Michael Lowe]

In this dialog, pressing the "Choose..." button and then selecting a file and
pressing open will immediatly close both dialogs and open the page in a new
window.   The "Choose..." button should instead operate as does Netscape 4, and
enter the file path into the dialog where the user can then press the Open
button to open the page in a new window or an existing window.

Also, the "Ok" button in this dialog would be more appropriatly labled "Open".

Lastly, it would be nice to have the open as does Netscape 4 to choose to open
the file in either the brower or in the composer modules.

Comment 1

[Claudius Gayle]

1 issue 1 bug please, it's waaay easierto chase them down that way. cc'ing appropriate folks.

Comment 2

[german]

I agree with leaving the first dialog open, after the user has chosen a file. I
agree in general, too, that from a usability standpoint it is better to say what
the default action will do rather than a simple OK. Having said that though, we
will later use inserted fragments for the row of command buttons. This is to
keep ourselves the option open to have platform specifc button orders for
dialogs. Now if each of the dialogs would have to have its own specific
fragment, this could an administrative nightmare, considering this could be
around 50 different dialogs (est.), multiplied by 3 platform arrangements. In
addition, translation tables have to be generated for the entities to be
translatable (4.x ships in 23 languages!). Lastly, we it was already decided
earlier that the open dialog will be context sensitive based on which
environement it was opened. If editor will not be a separate environment, then
we might have to revisit this.

Comment 3

[Michael Lowe]

1. On inserted fragments for command buttons: would it be possible to have an
optional parameter to the template which overrides the label of the default
button?

2. On the context sensitive nature of dialogs: I still think it is better doing
things the 4.x way.   If the user is in the Browser and the want to start
editing a file it cuts down the number of operation requires to do this by 1.
Since the Browser / Composer / Mail News are integrated it provides an
opportunity to harvest opportunities for shortcuts in the tasks users perform.
For the same reason "New : Mail Message" is provided on the file menu as a
shortcut into Messenger, this option should be provided in the Open dialog as a
shortcut into the Editor.

Comment 4

[don]

OK ... what should we do here?

Comment 5

[Michael Lowe]

I notice that the Find dialog has "Find" and "Cancel" buttons, not "Ok" and
"Cancel".

Comment 6

[Bill Law]

I will soon be working on fixing file-picker problems, including this one.

The "Open" vs. "Ok" issue should be addressed separately (direct that to
[e-mail]).

Comment 7

[shuang (gone)]

took myself off the list. I am useless for this one...;-)

Comment 8

[Bill Law]

*** Bug 8618 has been marked as a duplicate of this bug. ***

Comment 9

[Bill Law]

I'm marking this fixed.  German overhauled the look of this dialog and removed
the "Chose file..." button.  I'm assuming the button is now labelled as it
should be.

Comment 10

[leger]

cpratt...can you verify ASAP please?  thanks!

Comment 11

[cpratt]

The problem as originally described is fixed. 1999092508 build, Windows 98.

Comment 12

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.