Closed Bug 109109 Opened 23 years ago Closed 21 years ago

Custom Hdr: Add new header should indicate where headers are added


(MailNews Core :: Filters, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: alecf, Assigned: mscott)



(Whiteboard: [ue2])


(1 file, 1 obsolete file)

this is coming of of bug 108943, which I filed because I didn't realize how the
Customize Headers dialog worked.

In any case, I think that:
1) we should initially focus the text box
2) we should disable the Add button if there is nothing in the text box
3) after adding a header, we should re-focus the text box
4) after adding a header, the new header should be selected in the header list

This also means that:
- initally, the Add button is disabled
- when the first character is typed, it gets renabled
- if you hit backspace to clear the text field again, the Add button is disabled
- when you do hit Add to add a new header, the button becomes disabled
 again because the text box is cleared

I think focusing the text box will make it more obvious what you're supposed to
do, because there is a dark line around the currently focused text box, the
cursor is blinking, and so forth..
Whoops, i didn't realize you had opened a new bug
Please see bug 108943 comment 5
Agree. The Add button should definitely be disabled if there is nothing to add.

Default focus in text field is a plus as well.
still exists dec14 commercial trunk
Keywords: nsbeta1
Summary: Add new header should indicate where headers are added → Custom Hdr: Add new header should indicate where headers are added
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.2
*** Bug 141062 has been marked as a duplicate of this bug. ***
This really effects the usability of the custom header dialog for mail (see my
comments in 141062). I added the same header 4 times in a row and coouldn't
figure out why it wasn't showing up in the list. I typed my text and hit enter
but the enter was for the ok button so the dialog kept dismissing without
actually adding my text to the list. *yuck* 

It'd be great if we had a small patch we could get in for rtm for this. 
sure, we can fix this for rtm.
The basketball game wasn't very interesting on tv last night so I decided to
contribute a patch to custom headers in my free time. Hope you don't mind

This patch implements most of the behaviors listed by Alec. I still need to
make the filter/search dialog select the last custom header you added when you
dismiss the custom header dialog instead of selecting the subject. That's going
to be tricky (suprisingly). 

Here's what the patch does do:

1) Text box is given focus when the dialog comes up, Add button is disabled.
2) When you start typing text, add button becomes enabled. When you delete all
of your text it becomes disabled again.
3) After a header is added, the text box is given focus again. The Add button
is disabled again. And the most recently added header is selected in the tree
widget (but it does not have focus).

4) It has one "extra" that I don't think Jennifer will let me check in =). My
biggest problem with the dialog when I first tried to use it was the following:

 I would type in a header then hit enter, expecting the header to be added to
the list. Unfortunately since this is a dialog enter always goes to the OK
button so instead the dialog gets dismissed. I modified it so if you hit enter
and you have text in the text box then we'll add that text as a custom header
then dismiss the dialog. Personally, once you start typing text I'd like to see
enter act as an Add instead of as the OK button but other dialogs that behave
like this one (i.e. subscribe) always dismiss on OK and you have to manually
click Add. So we are consistent with other dialogs, I just don't find it user
friendly. So I added an "extra" to accept what I had typed and dismiss the
dialog when you hit enter. I can now quickly add a custom header.

I'll post another patch when I have the most recently added custom header
getting selected in the search / filter dialog after you add a header.
yes, selecting the last added custom header in the filter editor is tricky. 
There were some issues as what header to show if the user removes one custom header
and comes out. 

over to you since you are working on a fix. you will have to run this new 
behavior by jennifer. 

Assignee: naving → mscott
*** Bug 104175 has been marked as a duplicate of this bug. ***
New behaviors sound good. Also to consider, "Remove" button should only be 
enabled when an item in the list area has primary focus, otherwise, it should be 
disabled. (currently, if the text entry field has primary focus, and an item in 
the list has secondary focus, "Remove" is still enabled and will remove the item 
from the list).

As for the "extra" feature, ;-)
"OK" does not have to be the default button on a dialog, hence I think having 
"Add" as the default button when the text entry field has focus is a cleaner 

From MS Windows UI Guidelines: "Define the default button to be the most likely 
action..." (in this case "Add". And "You can change the default button as the 
user interacts with the window."

Hence, when the text entry field has focus, "Add" should be the default button. 
Once the user activates "Add", "OK" button gets focus. If user navigates/clicks 
back to text entry field, "Add" button once again has default button focus.

The 4.x "Select Addresses..." dialog is a good example. The more commonly used 
"To" button has initial focus, then it switches to the "OK" button once a 
recipient has been added.

Is this doable?
Hey Jen, I couldn't find another dialog in the product that had a list box where
a delete or remove button would get disabled when focus left the listbox but an
item was still selected. I looked at dialogs like the advanced smtp dialog,
filter list dialog among others and they all behaved like the custom header
dialog does today with the remove button. 

I did try to disable the remove button when focus leaves the list box but I was
using an on blur event. As a result, just moving the mouse over to the Remove
button caused the remove button to get disabled. I'm probably just using the
wrong event to detect when focus leaves the listbox.  

I'll try to change the default behavior of the dialog to match the description
you just gave me with regards to the OK and the Add button.
Okay, here's the final version of the patch ready for review. With Jennifer's
green light, I modified the default action of the dialog. Initially the OK
button is the default action for enter / return and it gets a dark circle
around it.

As you type text into the header dialog the Add button gets the dark ring and
it becomes the default action for enter/return. 

If you hit enter at this point, the text is added as a custom header. Default
behavior returns to the OK button. Enter again and the dialog is dismissed. So
type text, 2 enters later it's added and the dialog is gone.

If you delete the text from the text box, the default action swings back to the
OK button from the add button.

The only thing I'm missing here is replacing the search attribute with the last
custom header you added to the dialog. Turns out that's really hard because of
the interaction between the search xbl widgets and the caller of the custom
header dialog. Fortunately that feature request is covered in: Bug # 107604. 

So I'm going to treat this bug as fixed with this patch with the missing part
already being covered in 107604.
Attachment #81870 - Attachment is obsolete: true
Comment on attachment 82153 [details] [diff] [review]
update patch, includes new default Add button behavior

looks good, r=naving
thanks for cleaning this
Attachment #82153 - Flags: review+
Comment on attachment 82153 [details] [diff] [review]
update patch, includes new default Add button behavior

Attachment #82153 - Flags: superreview+
>Hey Jen, I couldn't find another dialog in the product that had a list box 
>where a delete or remove button would get disabled when focus...

No biggie. You got the most important ones. :-)
nominating for buffy
Keywords: nsbeta1-nsbeta1
Whiteboard: [ue2]
Blocks: 160730
Items 1-3 of original bug are fixed.
Recommend we close this bug and file new bugs for item 4 plus any additional issues.
Mail triage team: nsbeta1-
Keywords: nsbeta1-
Keywords: nsbeta1
As noted in comment 17: original report's items 1-3 are fixed.  
Item 4 is bug 107604.
Problem described in comment 5 is also fixed.

Problem described in first paragraph of comment 10 still exists (and is "no 
biggie" per comment 15).

Therefore, resolving as fixed, per comment 12 and comment 17.
Closed: 21 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.