Using feb 26 commercial trunk builds The New Folder button within mail filter rules dialog should be disabled when the action selection is no Move To Folder. The button should either disable or be hidden from the display altogether (4.x platforms differ in showing disabled button or hiding the button) when action is not selected to Move. 1. From mail window, Edit|Message Filters. 2. Click New button, filter rules dialog opens. 3. Go to the action selector at bottom of dialog. Note it defaults to Move To Folder and there is a New Folder button present, enabled and operable. 4. Switch the action selection to Change Priority, Delete, or Mark Read. Note the New Folder button remains enabled. Actual result: New Folder button in filter rules dialog is always enabled. Expected: New Folder button in filter rules dialog should disable when action other than Move To Folder is selected.

Taking. Jennifer, I think the button should be hidden. What do you think?

I'd go for disabling it, not hiding it. In general, you shouldn't completely hide a control when you're not using the space for something else. If you hide it, the user may wonder whether they were imagining the existence of the feature, or (in severe cases) even wonder if they're in the right window. In addition, completely hiding a control prevents the use of help balloons (Mac OS) or `What's This?' popups (Windows) for the control, which explain that the control is `Not available because the filter action does not involve custom folders' (or similar).

Good point. Thanks Matthew.

Ok, simple fix coming up. Navin and Seth, please review this.

looks good to me. r=naving

Seth, please sr= this little patch too.

with this patch, we call menuitem.getAttribute("actionvalueindex") why not do this: if (!menuitem) return; var indexValue = menuitem.getAttribute("actionvalueindex"); gActionValueDeck.setAttribute("index", indexValue); // Disable the "New Folder..." button if any other action that MoveToFolder is chosen document.getElementById("newFolderButton").setAttribute("disabled", (indexValue == "0") ? "false" : "true");

r=doron document.getElementById("newFolderButton").setAttribute("disabled", (indexValue == "0") ? "false" : "true"); is the ?"false":"true" really needed? I think i've seen it omitted before, but no big issue

I can optimize it further by doing document.getElementById("newFolderButton").setAttribute("disabled", indexValue != "0"); r=doron and sr=sspitzer implied for that change unless you say otherwise. :)

you can't optimize it further. "true" != true

note, that optimization only works first part was true and the second was false. but we have the reverse. (a ? true : false) == (a)

sr=sspitzer on http://bugzilla.mozilla.org/showattachment.cgi?attach_id=38975 (assuming you tested it and it works.)

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

fix checked in.

This seems to be okay using commercial trunk builds on linux and mac, but doesn't work well on windows june18-19 builds. Since we're having install problems with windows build today, I can't verify with like dates' builds. Will check again tomorrow. Basically OK, classic and modern skins, using commercial trunk builds: 2001-06-20-06 linux rh6.2 2001-06-20-08 maac OS 9.0

OK on june21 commercial trunk build, win98.