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

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

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

Comment on attachment 82153 [details] [diff] [review] update patch, includes new default Add button behavior looks good, r=naving thanks for cleaning this up.

Comment on attachment 82153 [details] [diff] [review] update patch, includes new default Add button behavior sr=sspitzer

>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

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-

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.