278533 - Preferences window too small for Composer prefs

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Stefan [:stefanh]]

Mozilla 2005011406, Mac OS 10.3.7

The fix for bug 92686 added new prefs in pref-composer.xul. Unfortunately, the
pref windows height isn't enough, the checkbox "Return in a paragraph..." is cut
off at the bottom.

Comment 1

[Stefan [:stefanh]]

Attachment: Screenshot of pref window

Comment 2

[Vedran Miletic]

It happens on Windows too. Can someone change Hardware -> All and OS -> All?

Comment 3

[Ian Neal]

This is theme dependent, on some themes it just about fits on (Classic on Windows)

Comment 4

[Stefan Borggraefe]

Why is it important to have a user visible preferences option for the maximum
number of pages listed in the "Recent Pages" menu? Could we perhaps just remove
this option from the pref pageto fix this bug? A hidden pref with a reasonable
default would be enough for this IMHO.

Comment 5

[Kathleen :Brade]

One reason to keep the pref for "open recent" exposed is because if someone
wants to open a file and not have it listed in the prefs it is easy to tell them
to set the value to 0 and then reset after they have edited the file.

I don't really have a good sense of how many people actually change the value. 
I know I do occasionally (when I have a huge number (~20) of files I'm editing
and want to keep in the list but generally I don't like the list too big (8-10).

If we are going to remove a pref (or two), we should also consider the table
(maintain table structure) pref as well as the two radio buttons (which don't
work?) for reformatting the source when the file is saved.

If we don't want to remove a pref, we can combine the radio buttons into a
dropdown list or move one or more prefs to other panels.

Comment 6

[Asa Dotzler [:asa]]

not going to block on this for beta but we'd take a reviewed patch into beta2
and possibly beyond as long as it didn't add or modify localizable strings. 

Comment 7

[Max Powers]

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

Comment 8

[Ian Neal]

Attachment: Screenshot of Proposal A

The "Table Editing" and "Cascading Style Sheet (CSS) Editing" group boxes
combined into one "Editing" group box

Comment 9

[Ian Neal]

Attachment: Screenshot of Proposal B

The "Table Editing", "Cascading Style Sheet (CSS) Editing" and "Behavior of the
return key" group boxes combined into one "Editing" group box

Comment 10

[Stefan [:stefanh]]

Since all three checkboxes deals with editing, I'll vote for proposal B ;)

Comment 11

[Robert Kaiser]

Proposal 2 sounds good to me...
While we're at it, we should probably even replace the remaining radio with a
"Retain original source formatting" checkbox, as it's pretty obvious that the
other possible variant is reformatting the source, and it's bad style to have a
two-way radio where one choice is obvious from knowing the other one.
A checkbox is cleaner and simpler.

Comment 12

[Giacomo Magnini]

Add my vote for proposal B.

Comment 13

[Ian Neal]

Attachment: Screenshot of Proposal C

Changes from Proposal B
* Changed radio group to single checkbox as suggested by Kairo
* Changed "Retain" to "Preserve" in new checkbox label
* Added accesskeys where they were missing

Comment 14

[Ian Neal]

Attachment: Patch for Proposal C v0.1c

Implements Proposal C

Comment 15

[[e-mail]]

Comment on attachment 179376 [details] [diff] [review]
Patch for Proposal C v0.1c

Looks OK except you forgot to reverse the formatting checkbox.

Comment 16

[Ian Neal]

Attachment: Revised patch for proposal C v0.1ca (Checked in)

Changes since v0.1c
* Added reversed="true" to new checkbox - thanks Neil for the catch

Comment 17

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 179501 [details] [diff] [review]
Revised patch for proposal C v0.1ca (Checked in)

nice.
r=[e-mail]

Comment 18

[Kathleen :Brade]

Does the pref for maintaining original source formatting actually work now?  At
one point (years ago?) the checkbox and text weren't in synch with each other
and it's not clear if that is fixed with this patch or was fixed long ago or ?

Comment 19

[Ian Neal]

brade, from my testing using the "Preserve orginal source formatting" does make
a difference to the HTML source code that you see in composer.

Comment 20

[Ian Neal]

Comment on attachment 179501 [details] [diff] [review]
Revised patch for proposal C v0.1ca (Checked in)

marking daniel's r= and requesting sr=

Comment 21

[Ian Neal]

Comment on attachment 179501 [details] [diff] [review]
Revised patch for proposal C v0.1ca (Checked in)

Checking in composer/content/pref-composer.xul;
/cvsroot/mozilla/editor/ui/composer/content/pref-composer.xul,v  <-- 
pref-composer.xul
new revision: 1.34; previous revision: 1.33
done
Checking in locales/en-US/chrome/composer/pref-composer.dtd;
/cvsroot/mozilla/editor/ui/locales/en-US/chrome/composer/pref-composer.dtd,v 
<--  pref-composer.dtd
new revision: 1.2; previous revision: 1.1
done

Comment 22

[Stefan [:stefanh]]

v fixed (2005040610, Mac OS X)

Comment 23

[Stefan [:stefanh]]

v fixed (2005040610, Mac OS X)