Currenlty, the folder properties dialog in Mail has three very short tabs. It would be better to only have one tab (or no tab control), unless more items are going to be added to the dialog.

I agree. I can fix this if it's OK with bienvenu and sspitzer?

you want to merge the three tabs ("General", "Download", "Character coding")? if so, then I'd mark this WONTFIX. that dialog matches the spec.

Yes, this is invalid. There's more stuff coming for the tabs, at least for offline, and there should be stuff added to general at some point.

Can't we at least skip the "Character Encoding" tab, since it probably won't contain anything else than a checkbox and a popupmenu? Jglick?

cc'ing international rep.

"Character coding" is needed to allow the user to assign a character coding to a folder.

nhotta: No, the Character encoding *tab*. Read my previous comment. :)

Marking verified invalid

I'm starting to get a little by annoyed by this verifying in the middle of a discussion style. Can't you hold off till at least I get a proper answer?

we're matching the spec - it seems a perfectly valid resolution. We have a lot of real bugs to work on.

Okay. A couple of points about using Bugzilla. Firstly, as you can see from the `Severity' field, this isn't a bug; it's an RFE. If Mozilla's current behavior was matching the relevant spec, then it would be a request to change the spec as well. In this case, however, bienvenu is incorrect in claiming that `we're matching the spec', because this particular dialog *has* no spec. All it has is a cursory sentence in the global mail/news spec -- `Each folder has an associated Properties Dialog'. Ironically, in the screenshots for this dialog in the offline spec, the `Character coding' tab is not present, which is what Håkan was asking for in the first place. Secondly, trying to dictate which improvements to Mozilla a volunteer contributor should or should not work on is rather unfortunate behavior, and runs the risk of discouraging further bugfixes from that contributor in the future. (This isn't a criticism of those in this bug in particular -- Netscape employees have been doing it in quite a few bugs I've seen recently.) If some mysterious `we' has `a lot of real bugs to work on', that's fine -- all that `we' needs to do is to avoid accidentally typing the keystrokes which would reassign the RFE to theirself. In this case, Håkan had already offered to fix the bug, so whether or not `we' has time to do it is irrelevant. And in any case, `INVALID' should never be used as a scheduling mechanism.

Reassigning to Håkan, pending confirmation from jglick that the `Character Coding' tab will never contain more than one popup menu and one checkbox, in which case it's not worth the encoding UI having its own tab.

having a spec for this dialog, or at least some agreement about this specific issue would be a good idea before hwaara wastes his time on it. > This isn't a criticism of those in this bug in particular -- Netscape > employees have been doing it in quite a few bugs I've seen recently. no, you are seeing some healthy project guidance from the mozilla mailnews module owners. if you have problems with that, let staff@mozilla.org know. 'we' (the mailnews module owners) are trying to make mail & news in mozilla 1.0 the best it can be. yes, discouraging contributors is not good. but neither is wasting cycles on less important bugs. It's up to hwaara to decide what he works on, but less important patches tend to bit rot in bugzilla, since reviewers and super-reviewers time is limited, and more important bugs get higher priority. recent comments (like bienvenu's) are to help keep contributors focused on the current goals of the mail & news product. hwaara, I'm hoping you can apply your [improving!] skills on a bug that will affect more users in a bigger way than this bug.

Thanks for the reminder about working on more important bugs. However, something I don't like is when people are rude enough to close/verify a bug in the middle of a discussion (and that has happened to me two times only this week). Futuring (as per what the above comments indicate) and reassigning to default QA and assignee.

I meant "We" in the mozilla community sense, the people working on mail/news bugs have more important things to work on - in his screed, mpt seems to assume I meant Netscape or the mailnews group. Seth is correct that we, the module owners, definitely have more important things to review. We're not dictating what people work on - you can work on whatever you want to work on, but I think module owners do have the responsibility to decide what gets checked in. And I think everyone is happier if what they work on gets checked in, so what mpt sees as discouraging external contributions is, in my mind, in the long run, encouraging external contributions.

International implemented the Char Coding tab. nhotta, could you maybe elaborate (or cc the correct person) on the contents of this tab? Are more items planned for it in the future? Thoughts on it being a sep tab? (see 65018 for some history).

Language could be an additional attribute in future. It is not clear what is this bug proposing. Is it asking to merge the character coding items into generic tab?

bienvenu: I had no idea who `we' was referring to. All that was obvious was that it didn't include the person who had expressed an interest in implementing this. Ok, proposal: * The folder encoding popup menu, and the `Always use default' checkbox, be moved from the `Character Coding' tab to the bottom of the `General' tab. * The encoding popup menu be given the label `Default encoding for messages:'. * The now-empty `Character Coding' tab be removed. Perceived advantages: * The `Character Coding' tab stops looking unfinished in its eternal near-emptiness. * A first step is taken towards getting the folder properties window and the bookmark properties window (which share several ideas, e.g. name, offline browsing, and maybe even default encoding) to follow a relatively consistent design with two tabs each: `General' and `Offline Use'. * The UI for setting the default encoding of a folder becomes *more* obvious than it is now, since it is in the tab which is visible when the folder properties window is first opened. * Bug 67612 and bug 78891 could get fixed at the same time as this bug is fixed. Perceived disadvantages: * In the unlikely event that several more encoding-related items are added to the folder properties window, they may need their own tab again.

Yup. I'll fix this, along with bug 67612 and bug 78891.

Taking

Status: I'm having some problems with my mega-patch. I worked on it the whole evening but couldn't find the problem. Emailed mohanb for help.

If Character Coding is removed as a separate tab, then the menu item, "View Menu --> Folder Character Coding..." should also be removed. Currently this menu item opens the Folder Properties dialog with focus to the Character Coding Tab. If this tab is removed/combined with General Tab, this menu item is redundant with "Edit Menu--> (Folder) Properties...". See 66827 for history.

mpt@mailandnews.com, please post your proposal to i18n newsgroup (netscape.public.mozilla.i18n) since it mainly affects non Latin1 users.

Doron takes care of this baby. Per IRC discussion.

*** This bug has been marked as a duplicate of 78891 ***

verified dup.