37668 - Only make dialog button available if text field has data

Status: VERIFIED INVALID

(SeaMonkey :: General, defect, P3)

Description

[Henrik Gemal]

In all the dialogs that requires the user to enter text, the button the either 
activates or OK'es the action should first become available when the user 
actually enters some text.
Like the Search -> Find on This Page... dialog where the Find button only is 
avaiable when the users has entered some text.
Many places this is not the case, like in Bookmarks -> File -> New Bookmark

Comment 1

[Matthew T (active 1999-2002)]

Actually, the button should be available if the text field has content, not just 
when the user enters content. In the case of the Find dialog, for example, the 
field might be pre-filled from the previous search.

This should probably be an overlay of some description, linking the contents of 
the text field to the state of the button, so it can be applied to any dialog you 
like.

I have mixed feelings about this -- fixing it would be a usability plus, but it 
could also hide a number of bugs (henceforth reproducible only through scripts or 
something similarly obscure) where certain functions accepted null input when 
they shouldn't.

Comment 2

[Brendan Donohoe]

The usability benefit of this suggestion is somewhat dubious.  If you make 
it a general rule, as described here, that any dialog which requires user 
input should disabled the OK button until input or content has been 
received, then you're bound to wind up in a situation where a user has 
filled in some, but not all fields in a dialog and doesn't know why they can't 
click OK.  There's no recourse but to click cancel and start again or give 
up.  Even in a dialog that has only one or two controls, it can be frustrating 
when a particular control is disabled and there's no way to find out why.

On the other hand, if the OK button is enabled, clicking it prematurely can 
put up an error dialog specifying exactly which piece of information is 
missing and providing the opportunity to go back and fill it in. 

Resolving as INVALID since I think the current behavior is more usable 
(provided we catch errors when they occur!).

Comment 3

[Henrik Gemal]

So I file individual bugs on dialogs where I think Mozilla should use the "no 
OK before enter text" thingy...

Comment 4

[Matthew T (active 1999-2002)]

bdonohoe: If a dialog relies on error messages to tell the user what still needs 
filling in, there's probably something wrong with the design of the dialog.

gemal: Yes, go file those bugs. This is invalid really because the best behavior 
on capturing the Return key varies from dialog to dialog -- in some cases, it 
would be to accept the input and perform no action (e.g. the Find dialog), in 
others it would be to beep/flash and then put focus back in the first empty 
compulsory field.

Verifying invalid.

Comment 5

[Brendan Donohoe]

For the record, "error" messages are not just a means to prevent crashing 
or other program failure.  Use of an alert to *inform* the user when 
information is missing is not inherently a bad design; in fact, it can be a 
*better* design than cramming all the instruction into the dialog because 
it allows users to learn and then not be bothered with a dialog overloaded 
with information the next time.

Regarding gemal's comment, yes, if there is a particular dialog where it 
makes sense to dim the okay button until input is received, file a bug and 
we can all evaluate that particular case.