Using feb26 commercial trunk builds Mac and Linux particularly bad The default launch size of the prefs dialog really affects the use of the Domains section in Mail and Newsgroups|Send Format panel. The dialog opens with the HTML and Plain Text Domains section severely clipped. Often even upon resize, the list boxes for each domain show as a horizontal line, even when the associated buttons are visible/active. When a domain is added, the list doesn't open up in this case; user must resize again to show the list with their addition. Because of the large linux fonts, on my machine I cannot see more than one line in the domains lists no matter how big I resize. In bug 68789 (concerning the new folder dialog) naving made some comments about a general problem with dialog auto resizing to content... I don't know if there's a master overall bug for the problem, but logged this to track the definite need for a fix for usability in this pref panel.

Nominating for nsbeta1, when this dialog is not resized to show all, it's not easy to realize there is anything else in the dialog to use. When I first looked at this to verify a bug, I almost reopened the bug because I didn't see the new stuff. The window was the same size as before and looked OK. I guess by habbit I expect the dialog to display everything. Also, when I resized, I only resized to the expose the new buttons (the list bucket was collapsed). Again I almost logged a bug saying there was no way to see what you added. I then resized again and found the buckets. Note: the good thing is that when you finally resize, it keeps the size.

1. Reduce items on this dialog to make room. OK, first, "If you know a particular recipient can receive html mail..." was supposed to come off this dialog. It is no longer valid since the settings for this in the AB was changed. Suggest also removing the "You can override these settings..." text. (Robin, what is your opinion on this? I don't know how helpful having this text here really is to users. Also, i am leaning towards making room on this panel as opposed to options 2 or 3 below. Or keep the "You can override these settings..." text and removed the group box. See screenshot. 2. HTML and Plain Text Domains can become its own panel. 3. Add a button which opens a dialog that allows users to view html and plain text domains. Currently adding a domain opens a secondary dialog. This would add an additional step.

reassigning to varada and marking nsbeta1+

could you offer >> and << arrows for moving domains from one list to the other?

Also, the Title header for this Panel "Send Format" is lower vertially than the title header for other pref panels. Moving this up to match the other headers would also make more vertical space.

Jennifer, I like the first option best (illustrated in your first attachment called "example"). I also favor leaving the text "You can override these settings..." since it lets users know they can change their sending format for an individual message at the time they send it (helpful info, I think).

Varada, can we first try moving the title header up to the same height as other pref panels, removing the "If you know a particular recipient can receive html mail..." text and removing the group box around the top item?

moving to mozilla0.9.1

Marking Fixed.

I'm still seeing a problem with this default size. My win98 is such that the list boxes are horizontal lines and even when a domain is added (with default pref dialog size), the lists stay at horizontal line. My mac seems ok, my linux is down so I can't confirm there. Reopening based on win98 ...

We have three choices. We can either change the wording to make it fit, add a new panel, or leave it as is. Due to time constraints I'd like to go with the first or third choice. Can anyone think of wording changes to this panel to make more vertical space?

I'm using Monday's build (2001041604) on Win95 and I'm not seeing the problem Laurel describes.

I just tried with win98 on 2001-04-17-04 and it's as present as ever. And, as I've mentioned before, linux is horrible (in not only the format pane, but others).

Try a new profile. Once resized it may stay usable size, but in some cases you don't even get as much as in my screenshot so user may not be aware there's anything there to resize for!

Take a look at the attachment example posted 2001-03-09 09:58 (id=27277). Can we try removing the group box around "Send Format"? And the HTML and Plain text domains don't each need their own group box either (see above mentioned attachment).

The html and plain domains text needs to be shorter (3 lines max, 2 prefered imo). <br> HTML and Plain Text Domains <p>Mail sent to domains in the lists below will be sent in the corresponding format.</p> I'd get rid of all of the group boxes; a vertical separator should be sufficient (and save a lot of space). The pair to Add is Remove not delete.

Can't we just move this section into another panel, a sub-panel, or sub dialog (as in jglick's second proposal). 1) I'd like to ask how this panel was checked in as it is. The fact that all of this is scrunched up at the bottom and can only be uncovered/trees-expanded by resizing the dialog is *appalling*. Come on guys, we're making a professional application here. This kind of bs. has to stop. 2) The size of the preferences dialog is not going to increase. In fact, before 1.0/6.5 I plan to shrink it to 565px wide (or the em equivalent of that using default font settings). 565 is 20px wider than 4.x, but smaller than we have now, I think. Conformance to this width setting will be non-optional for everyone who wishes to have a panel in the dialog. Our application MUST fit on 640x480 displays otherwise we're just going to be laughed at. If you want to know how you can make your panels fit into a reduced size dialog, or how to make text flex properly, please don't hesitate to contact me for information.

Eek. Wrong patch, new one coming up. Sorry. I'm attaching the simple wording fix.

One last tiny morsel of spam from me... Varada, I looked in the JS and XUL code for the two accesskeys, but couldn't find them, are they not implemented yet, or am I just not looking in the right place? I grepped prefs-formatting.xul for those two accesskeys (l & t) and couldn'd find the entities.

hey stephen thanks for the info - I had forgotten to add the accesskeys . I think we will be moving this to another panel or subdialog and I will incorporate your diffs into it as well as the accesskeys.

r=timeless + *sigh* isn't it amusing to note that the js internally called it remove? jglick: what do you think about my rewording of the long string?

So, I was just about to write that we should try to make the wording changes only. But then I decided to try this on my Win 2000 machine and I have to admit that this looks awful. I had to resize before I even saw the edit fields. It would be interesting to see what these changes do to the size, but I am beginning to agree with Ben that we should put this in a separate panel.

I just tried it. Chopping out the parentheticals, shortening the send format preamble, killing the postamble, and shortening the domains text leaves the dialog _still_ too big. I'm going to try rearranging the pane for 10 minutes, but i think this pane is one milestone from being split into two panes.

I have it to ~600x430, by moving th e add/remove buttons to the side instead of below. Removing the two outer titleboxes and substituting a HeaderSpan gets me to ~510x400 which would work, except it's contrary to our style. :( I think that a single domain list (outliner) that supports inline edit and has a blank entry (for new entries) with a subscribe check-like second collumn to indicate html/plain would be more space efficient, and possibly more functional. Users could easily toggle a domain from html to plain (and possibly to unknown/ask "?"), and sort by domain name or by formatting. I'd propose that deletions be made by clearing an entry, pressing delete key, dragging to system trash, or right clicking and selecting delete. Perhaps if we move to a multi state toggle, users could click through to delete ( plain->html->unknown->delete| html->plain->unknown->delete| unknown->html->plain->delete ), if an entry loses focus while in delete state it's deleted. Unknown isn't really needed, so w/o it, deleting is two clicks+focus change. If people want buttons, we could have: +------+----+ |Domain|Type^ +------+----+ |go.com|HTML| <HTML> | md.us|Text| <Plain> | uk|Text| <Remove> +-----------+ [ new item ] <Add> Anything like this is much more space efficient than what we currently have, however it would probably be too narrow :O -- I think that's an acceptable drawback.

Robin, please comment on the wording. Thanks. How about: "When sending messages to an address that has one of the domain names listed below, Mail will automatically send the message in the correct format." This keeps it similar to the wording above (Send Format).

Responding to Jennifer on the wording-- I prefer the wording of the original: "When you send a message to an address that has one of the domain names listed below, Mail automatically sends the message in the correct format." This version is also a bit smaller (uses 144 characters (including spaces), which is 2 characters less).

What if we used a pull-down combo instead of four radio buttons?

Getting better. Is anyone here opposed to offering a help button in the preferences dialog? Personally I don't think that caveats (you can overide this by ...) or parentheticals are worth their space in a preferences dialog, I'd prefer for them to be in a help document for the panel. But, even so, I think putterman's right, we should consider moving the domains options into a new panel. The problem is that i can't think of good titles for either panel. There's the /What to do when mail doesn't know the user's preference for a recipient/ panel, and the /User's prefered format by domain/ panel. I think these could be "Default Send Format" and "Mail Format Domains" but that sounds pretty bad. -- mpt veto'd the list box because the items were too long. I'm not sure if that's the case if we shorten the options to 5-8 words each. [In which case, we could have warning text for the current option displayed below the list box]

timeless wrote: >>Getting better. Is anyone here opposed to offering a help button in the preferences dialog? << FYI, this is a planned feature for 6.5. I'm working with Ian Oeschger to implement a Help button in the Prefs dialog (as well as in other dialogs that could benefit from a Help button). The spec is here: http://mozilla.org/projects/help-viewer/cshelp_specification.html

see also bug 53375 and bug 54679.

*** Bug 77628 has been marked as a duplicate of this bug. ***

adding german, for pref window sizing help

Marking Fixed.

This bug still occurs in Friday's build. Suggest reopening.

It was checked in on Friday. Therefore, you'd have to check a build from Saturday (or pull yourself via CVS) to see the changes.

Is this bug fixed in sundays buid?

I am running today's build (20010430) and the Send Format window is still completely unusable in 640x480. This is unacceptable as a resolution to this bug, as 640x480 is still considered a standardized resolution on Windows platforms (I don't like it any more than you guys do...).

Its fixed on yesterdays build on the standard 800x600 screen res. And when windows is installed it is pre-set to 800x600, at least on all the machines I use. Maybe setting your pc to 800x600 is best for you.

Cody, this bug isn't about 800*600. It's about 640*480, on which we *must* comfortably fit. And we don't, on build 2001501. Reopening.

Reduce the text to: "When you send a message to an address with one of the domain names listed below, Mail automatically sends the message in the correct format." Move the Add and Delete buttons to the right of the list boxes if necessary.

Oh it isnt about 800x600? Well then why did I have this problem at that res. and now with this new build it is fixed?

I still don't see why we can't make those radio buttons one pull-down list. That would be the best solution to this problem. And yes, Mozilla absolutely must be fully and comfortably usable at 640x480. Internet Explorer works at 640x480, and we obviously don't want to lose those users. There are some people who must run at this resolution because of vision problems, cheap monitors, etc.

Apparently this works at 800 X 600 so marking nsbeta1- and changing milestone to future. If jglick approves (and since she gave you the text I imagine she does), timeless feel free to take the bug over and check in your patch.

taking bug and seeking approval SkewerMZ@skewer100.cjb.net: try it out, provide pictures, usabilitiy estimate and a patch, preferably in a new bug.

Not sure if it's exactly an r=stephend@netscape.com, but I've applied, built and run with Timeless' patch in my tree at 640x480 with no problems.

In the above image, note that the prefs window is stretched beyond any reasonable boundaries such as the edge of the screen or the taskbar, and still the domain listboxes under Send Format are completely unusable. Again, this browser MUST BE FULLY USABLE AT 640x480, otherwise there will be users who cannot use Mozilla/Netscape. Strongly recommend changing future milestone.

This bug is getting worse. In 20010512 Win98, the prefs window is not sizable, and in the fixed size, the domain lists are rendered as illegible dashes. In fact, almost everything in the prefs window renders incorrectly now.

may as well convert <box orient="horizontal" to <hbox while you're touching those lines. sr=ben@netscape.com to that patch with that change.

fix checked in

It's getting better now, but the bottom of the frame still gets chopped off in build 20010516 Win98. Maybe you guys should test your fixes with a larger font, my system uses the Trebuchet font.

win32 talkback build 2001061520, win98se 17-inch monitor, screen resolution 1280x1024 96dpi. Screen shot attached. I really wish this would get adddressed. Oddly enough, when I change the Win screen display settings to use Large Fonts, the panels fit in the window just fine. Same kind of thing happens with the Message Display and main Mail and Newsgroups prefs windows.

Renominating bug for nsbeta1. When this bug became nsbeta1-, the dialog was usable at 800x600 because at that time it was sizable. Now that its size is locked, all resolutions exhibit this bug dependent on the system font (Although the dialog looks OK in Verdana, it's particularly bad with the Trebuchet MS font with Classic skin). I have a screenshot which effectively duplicates the previous one using the settings I just described.

Target milestone is a bit out of date. Adding keyword for 0.9.3.

This appears to be fixed in today's build, both themes.

Marking verified worksforme. Looks fine for me using current branch builds on win98, mac OS X, linux rh6.2