80392 - tracking: panels whose contents need to fit

Status: VERIFIED DUPLICATE of bug 133627

(SeaMonkey :: Preferences, defect)

Description

[sairuh (rarely reading bugmail)]

tracking bug.

Comment 1

[sairuh (rarely reading bugmail)]

filed as result of bug 79948 --in order to more easily keep track of the various
pref panels whose content needs to fit in a fixed-sized dialog.

pls do add bugs as blockers to this one [some of which might need reopening if
they were dup'd in favor of bug 54679, which was marked wontfix]. thx!

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

updating dependencies

Comment 3

[scottputterman]

Speaking as an NS manager affected by this change, I think we(Netscape) should
do one of two things. Either make it so that the size and resizeability can be
overridden in the NS tree to be what it was before or back this change out when
we branch.

I'm not going to argue that there wasn't work needed on various pref panels, but
I will argue that other bugs that are being worked on are higher priority and
making this work have to be immediate was unnecessary with so little time left
in 0.9.1

Comment 4

[sairuh (rarely reading bugmail)]

bug 33985 has a patch that added a pref to make all windows and dialogs
resizeable. should it be reopened?

Comment 5

[Jussi-Pekka Mantere]

What Scott said. To have to redo chunk of preference panels for what value at
this stage is ridiculous.

A change of this nature should have occurred weeks before the UI freeze, not
days after it. Especially any newly designed UI (such as the LDAP UI) would have
benefited from knowing that the prefs panel was going to be limited real estate
sometime in the near future. Had that been communicated early on and widely the
UI could have been designed to fit whatever goal we're trying to go for here.

Comment 6

[Blake Ross]

Uh...sorry, but to claim that this idea wasn't communicated early and widely is 
ridiculous.  The apparent apathy of developers towards designing a professional 
UI has been a publicly stated pet peeve of Ben and others for months.  And if 
you haven't kept up on IRC, read the newsgroups, perused the related bugs, 
heard of the discussion, then surely you read the notice that Ben sent to 
seamonkey-internal over two months ago.

If the UI had been designed with a little thought and care in mind from the 
start, we wouldn't be having this problem today -- something that Ben and 
others have warned about for months.  Scott, I don't really buy the time and 
priority argument.  It hardly takes much longer to do it right the first time 
than to do it wrong.  If you're spending the time to create the UI in the first 
place, then it's your responsibility to make sure it's correct.

In short, Mozilla has no such freeze coming up, so I see no reason to back this 
out of the trunk.  As always, the commercial tree is at your disposal.

Comment 7

[scottputterman]

Blake, to make it clear what I was trying to say, let me rephrase that my
suggestion to back out was for after NS branches, not affecting mozilla.  On the
other hand, I really do believe that there are higher priorities in most of the
modules than having to fix a bunch of new bugs that were added, so 0.9.1 is
going to suffer in some regard. Either these panels will look worse than they
did before if nobody fixes them or some other set of bugs won't get fixed.

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

Scott, I have a patch in my tree that makes every panel except LDAP (still 
working on that one) fit correctly, at all font sizes (tested a range between 
standard through 200%). Note that the previous pref dialog would remain sized at 
630px wide, no matter what the font setting, a serious problem for vision 
impaired users. My patch fixes this by ensuring that the window is always sized 
correctly regardless of the font size. 

I accidentally updated some of the stylesheet changes so have to do a full pull 
& resources build now, but expect to finish it off later tonight & have it 
attached for review by tomorrow. 

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: An example of the patch in action, 125% fonts (Large)

Comment 10

[scottputterman]

Ben. Great. In that case my previous comments don't matter. My concern was
very much the 17 dependency bugs I see. If you have fixes for them that work
with your new patch and any wording changes have gone through UE/localization
then I have nothing left to be unhappy about :)

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

OK, I have fixes for every panel except LDAP. I'll attach them soon but I need 
to fix some classic stuff to do with the stylesheet scoping landing tonight 
first. 

I've decided that I will not be fixing the LDAP panel. I looked at a build from 
the 9th (prior to my checkin) and it shows the panel's contents not fitting 
/then/, so as far as the average user is concerned, the situation hasn't really 
changed. How it was checked in the first place is beyond me. 

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Changes Classic-Win (Editor)

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Changes to Classic-Win (Global)

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Changes to Mail's "Viewing Messages" panel

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Changes to Modern (Editor and Global)

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Changes to preferences panels in xpfe/components/prefwindow

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

These patches fix the fit bugs for all panels except LDAP in Classic-Win and 
Modern, at standard font size through 200% font size (and probably beyond, 
didn't test past that). 

I'll be attaching mac classic changes in a minute.

cc'ing: 
hewitt: for overall sr
sspitzer: for the mail changes
cmanske, brade: for editor changes. 

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

Mac patches coming tomorrow

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Patch to entire classic skin (this should replace previous classic patch)

Comment 20

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Patch to editor's "Editing" pref panel

Comment 21

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Patch to mail's "Message Display" panel (should replace earlier mail patch)

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Preferences dialog changes. Should replace earlier prefdialog changes.

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

OK, updated the patches to support Mac. Tested configurations:

Windows, Modern,  100% font size
Windows, Modern,  125% font size
Windows, Classic, 100% font size
Windows, Classic, 125% font size
Windows, Classic, 200% font size
Mac, Classic, standard fonts
Mac, Modern, standard fonts

I expect Linux to work properly as most of the changes were made to accomodate 
mac's fonts, and linux seems to fall between Windows and Mac. 

Need reviews, sr's. 

Comment 24

[Brendan Eich [:brendan]]

How did we get so many dialogs and panels that required resizing or scrolling
(whose content does not fit well), in the first place?  Such crap should not
pass UI review, code review, or super-review.

I'm still angry that netscape.com failed to communicate its "UI freeze" *again*,
just as back in 6.0.

I hear it took ben about a half-hour to come up with the patches to fix the bad
CSS (or whatever was to blame -- not my point).  Doesn't that make anyone who
claims to own these things feel a little bit bad?  Why can poor code get checked
in, lock out improving changes (even temporarily, and we all know that later is
never), and then the burden of fixing the bad code falls on the person bringing
in the good code?  I do not believe that only Ben could have made these fixes in
such short order.  Where's the accountability?

Mozilla has been hit with bad code all over, and for too long -- don't get me
wrong, I'm not doting on this issue at the expense of others (see hyatt's huge
style system performance improvements, under way currently).  We need to draw a
line in the quality sand, and hold it.  We need to start upholding higher
standards, and stop whining about 30 minutes of work (total, not per panel),
even if it's at an awkward time.

30 minutes is not a cost-free good, of course, and no one owes Ben that free
lunch.  But those responsible for the wrongly sized dialogs/panels do owe a few
minutes apiece to Mozilla, i.e., to our shared idea of quality, the one thing
that keeps people willing to work on the project.  Ben has paid others' debts,
so now those who perpetrated the badly fitting panels *do* owe Ben something.

Mozilla is not a zero-sum game, however much netscape.com managers may feel
trapped by commercial deadlines and fixed headcount.  People have free time at
night (Ben did); there are unpaid contributors, motivated more by quality and
comradeship than by deadlines and related pressure to compromise on quality.  
There are new hires and new members of the community, in due course.

If we have to take badly fitting panels, and then we can't fix them because of
triage-style priority, we are doing something terribly wrong.  We shouldn't take
the bad code up front (super-reviewers are the *last* line of defense; where are
the others?), and we should insist on payback ASAP when bad code gets through
our shields.  ASAP means in this case (or should have meant) that some people
work a few minutes late one night during 0.9.1's development cycle.

/be

Comment 25

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: by comparison, the same panel as the first patch on 05/09, large fonts

Comment 26

[Ben Goodger (use ben at mozilla dot org for email)]

seth has given me his 'r/sr' for the mail patch, attachment 34251 [details] [diff] [review]. 

Comment 27

[Chris McAfee]

over to ben

Comment 28

[Charles Manske]

Patch to editor's "Editing" pref panel is good, but not 100% adequate to fixing
the chopped off widgets in this panel. We already had bug 77517 on that issue,
which hopefully will be fixed for 0.9.1. I'll integrate Ben's changes with
that bug's fix, so that patch doesn't *have* to be checked in (but it is ok if
it is) r=cmanske if it is decided to checkin that asap.

Comment 29

[Charles Manske]

Editor bug 77517 is fixed and has patch attached that should be used instead of
patches for editor attached here.
It includes change to modern/editor/EditorDialog.css slightly different from
Ben's patch here labeled "Changes to Modern (Editor and Global)"

Comment 30

[scottputterman]

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

Comment 31

[Blake Ross]

r=blake on the css stuff.

Comment 32

[Blake Ross]

I don't like inline style, but I think its use is justified in cases like this.

</window>
+
+
+

Unnecessary, of course.

-        style="width: 51em; height: 40em;"
+        style="width: 51em; height: 40em"

This is probably harmless, but don't both properties need (or shouldn't they 
both have) trailing semicolons?

r=blake on the xpfe patch if you address the above.

Comment 33

[jglick]

Attachment: Message Display Panel

Comment 34

[jglick]

Ben fix probably already took care of this, but suggested fix for Message 
Display (Mail). Move "variable width" to the right of "fixed width" instead of 
below it. See above.

Comment 35

[timeless]

(overriding character coding specified by MIME header).

I think we use Si&ze in most places.  And I would expect either St&yle or 
&Style.

Comment 36

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: updated changes to Message Display panel to reflect jennifer's suggestion

Comment 37

[timeless]

convert <box orient="vertical" ...>...</box> to <vbox ...>...</vbox>

Comment 38

[Blake Ross]

r=blake on the new mailnews patch.

Comment 39

[Joe Hewitt (gone)]

sr=hewitt

Comment 40

[Ben Goodger (use ben at mozilla dot org for email)]

Fix checked in. 

Comment 41

[sairuh (rarely reading bugmail)]

vrfy'ing. remaining issues are tracked separately in the open bug blocking this
one.

Comment 42

[sairuh (rarely reading bugmail)]

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

Comment 43

[Samir Gehani]

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

Comment 44

[Greg K.]

Reopening. This is not fixed in either RC1 or RC2.

Either this or bug 133627 need to be fixed.

Comment 45

[timeless]

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

Comment 46

[timeless]

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

Comment 47

[Frank J. R. Hanstick]

Additional information.  BuildId: 2002072308.  When an application is selected
in Navigator Helper Applications, the window extends to thr right driving the
buttons off the screen.

Comment 48

[Cees T.]

Wrong component. ^^;

Comment 49

[Taco Witte]

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

Comment 50

[timeless]

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

Comment 51

[timeless]

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

Comment 52

[timeless]

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

Comment 53

[gregg987]

In MacOS 9.2.2 Preferences panels are still not resizable and buttons are still
clipped on the right in these panels:
Navigator..Helper Applications
Mail and News Groups..Message Display
Advanced..Cache
These errors exist in NS7, as well.
This thread is over a year old. Why weren't the patches mentioned in this report
applied to all builds after May 2001?

Comment 54

[simon.hetzer]

I also (still) have this problem with Win32, using the (old) build 2002091014
but I bet it is still the same in newer ones.
If we could just have a resizeable Preferences dialog back, I would aready be
satisfied. [Others might not]

Comment 55

[Andrew E. Schulman]

I agree with Simon Hetzer: can't we just make the Preferences dialog resizable?
 For me that would solve the problem.

Found more duplicates of this bug:  143290, 160149, 160420.

Comment 56

[Patrick]

perhaps bug 189786 should be added to the dependencies?

Comment 57

[sairuh (rarely reading bugmail)]

dup'ing in favor of bug 133627; also transferring dependency tree.

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

Comment 58

[sairuh (rarely reading bugmail)]

zap