57568 - Blank item added to Smart Browsing tree if enter is pressed

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect, P4)

Description

[Blake Ross]

Build ID: new {trunk, branch} build

Steps to Reproduce:

(1) Open the prefs window
(2) Navigator > Smart Browsing
(3) Type something in the textfield next to "Domain:"
(4) Press enter <prefs dialog closes>
(5) Reopen the Prefs dialog
(6) Navigator > Smart Browsing

Result: There's a blank item in the tree.  Pressing enter in the textfield 
should really trigger the Add button, not close the prefs dialog.  But since it 
does (close the dialog), nothing should be added to the tree, not a blank item 
(the item shouldn't be added because the enter key shouldn't carry out two 
actions, e.g. adding the item AND closing the window)

Comment 1

[Blake Ross]

Clicking in all textfields should make the corresponding button the "default" 
button, so it -- not the global OK button -- triggers upon pressing enter.  But 
I don't know if that should be one big bug or not.

Comment 2

[Matthew T (active 1999-2002)]

Changing the default button depending on the focus is decidedly unpleasant 
(unless the focus is on a button itself, as discussed elsewhere).

The root cause of the problem here is that there should be a separate dialog 
(with its own default button) for adding an entry.

Comment 3

[Blake Ross]

> Changing the default button depending on the focus is decidedly unpleasant 

Really? I could have sworn this is done many places throughout Windows UI.

Why would making the user add an item through a new dialog be more usable than 
the current solution?

Comment 4

[Matthew T (active 1999-2002)]

> Really? I could have sworn this is done many places throughout Windows UI.

I said, *unless the focus is on a button itself, as discussed elsewhere*. (I 
think that's a UI bug in Windows, but it's not bad enough to be worth Mozilla 
being inconsistent with.) That `elsewhere' is bug 49811.

> Why would making the user add an item through a new dialog be more usable than
> the current solution?

Because it wouldn't have the problem that the Enter key would have different 
behavior depending on something as apparently unrelated as placing the keyboard 
focus. I have never, ever seen a dialog do this in any app (not even in Windows), 
and I don't think Mozilla should be the first app to do so.

`Having two behaviors for one key can confuse users and make the interface less 
predictable.' <http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-
146.html>

Comment 5

[Blake Ross]

I'm pretty sure I've seen multiple cases in the windows UI where clicking in a 
textfield changed the default button *NOT* just when a button has the focus.  As 
I said.  I'll try to dig up an app where this happens.

Comment 6

[Matthew T (active 1999-2002)]

Attachment: For example, in 4.x's Subscribe dialog, the `OK' button is never the default button ...

Comment 7

[Matthew T (active 1999-2002)]

Attachment: ... because in (only) one panel, the default button is something else instead, and making the default button inconsistent is Bad.

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

simple enough, maybe you could patch it, blake? :P 

Comment 9

[Viswanath Ramachandran]

nav triage: german can you comment on this bug? 

Comment 10

[Viswanath Ramachandran]

ue to comment on what the behaviour shd be. 

Comment 11

[Blake Ross]

There's nothing really for UE to comment on.  This bug has morphed into a 
discussion of unrelated stuff, but there's a bug here that needs to be fixed.  
reassigning to me to look.

Comment 12

[Paul Chen]

blake, when do expect to get this done?

Comment 13

[Blake Ross]

not a priority.

Comment 14

[Blake Ross]

WFM.

Comment 15

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)