114022 - Font size in Composer's "HTML Source" view is too small and is not customizable

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[Frank Gore]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014
BuildID:    20011120

The font size used by the Composer's "HTML Source" view is too small and is not
customizable.

Due to this problem it is very difficult to edit the HTML source using  the
Composer.

The size of all other fonts is OK and does not need to be changed. I would not
like to change the size of all the fonts but just the size of the fonts that are
used by the Composer "HTML Source" view.

This size is not in synch with the size of the other fonts used by Mozilla.


Reproducible: Always
Steps to Reproduce:
1. Open Mozilla Composer
2. Choose "HTML source" (View/HTML Source)
3. The size of the fonts used by this view is extremely small and there is no
(obvious) option to increase (to change) this size.


Actual Results:  
Due to this problem it is very difficult (impractical) to edit the HTML source
using  the Composer.


Expected Results:  
The font size used by the "HTML Source" view should be large enough to enable
HTML source editing.

The default font size used by the "HTML Source" view should probably be equal to
the default font size used for WYSIWYG HTML editing.

There should be an option for increasing or decreasing the font size used by the
"HTML Source" view. Options for changing other characteristics of the font and
for changing the font used in the "HTML source" view would be useful.

Comment 1

[Kathleen :Brade]

-->cmanske
Charley--I think you have a bug related to this issue (but perhaps not).  I
don't see an obvious duplicate bug but it seems like we've known about this
issue for more than 2 months.  

The fix should be to use the default monospace font/size preferences in html
source mode.

Comment 2

[Kathleen :Brade]

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

Comment 3

[Håkan Waara]

Yes, HTML source mode should obey the specified monospace font and font-size. 
That's the fix for this problem.

Comment 4

[Charles Manske]

I know I fixed this once before!
I added this CSS in themes file editor.css:
#content-source, #doctype-text {
  font-family   : -moz-fixed;
}
That used to allow us to use whatever monospace font size the user set in their 
prefs, but it doesn't seem to be working.
Not a composer problem?

Comment 5

[Charles Manske]

I experimented with added "font-size" directly to the "style" attribute in the
XUL for the source editor:
<textbox class="source-editor plain" id="content-source" ...  style="width:1em;
height:1em; font-family:-moz-fixed; font-size:larger;"/>
The result of this is that the text does appear larger, but by a significant 
amount. I'll attach an image to demonstrate.

Comment 6

[Charles Manske]

Attachment: Image showing font size when "font-size:larger" is used

Note that the DOCTYPE text size at the top is the default size (what the bug
filer considers too small), so "larger" is relative to that.
So we could get finer control over the size by using something like "110%" for
the
size. 
We could also add a menuitem that would allow users to change this size, like
the
View | Text Size submenu for the browser.

Comment 7

[Akkana Peck]

font-size:larger seems like the wrong solution.  In any plaintext context
(including the source view), we should be using the same font as the user has
specified for fixed-width (or, alternately, the font that's used for textareas).
 Presumably these fonts are displayed at a reasonable size, or else many other
pages won't work right, so we should leverage off that.  If we're specifying
that and it's not working, we need to find out why it's not working rather than
putting in band-aids like "larger".

Comment 8

[Charles Manske]

I think the basic problem is that the HTML source window isn't really 'content'
(a real editor), but is just another child window in the chrome. Thus it isn't 
responding to the CSS that governs content attributes. I'll confirm this 
hypothesis with the XUL/XPFE team. 

Comment 9

[Charles Manske]

More milestone load balancing

Comment 10

[R.K.Aa.]

The original summary of this bug was:
"Font size in Composer's "HTML Source" view is too small and is not customizable"

The current summary is for some reason set to the same as in bug 114832.
Which makes this very hard to find, since the issue raised here is a completely
different one.

Comment 11

[Akkana Peck]

I'm guessing that changing the summary to "contextual menu "List Item
Properties" should not fire Advanced properties panel when selection is a list
item" was a mistake -- it doesn't seem related.  So that this issue doesn't get
lost, I'm taking the liberty of changing it back.  Charley, I hope that's okay.

Comment 12

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 13

[Charles Manske]

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

Comment 14

[Robert Maynord]

By way of information: Netscape 6.2 does not have this problem.  I have both
Mozilla and Netscape installed on multiple machines at the school where I work.
 Students use Composer for HTML authoring.  Mozilla is not usable because of the
font size.  We use Netscape, although I wish I could use Mozilla.

Comment 15

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

I confirm that Netscape 6.2.2 does not have the bug... Investigating the 
difference.

Comment 16

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

I think this is the root of the problem because the font size of composer's
source view is directly inherited from there :

/xpfe/global/resources/locale/en-US/intl.css, line 6 :
            font: 3mm tahoma,arial,helvetica,sans-serif;
/l10n/langpacks/en-DE/chrome/en-DE/global/locale/intl.css, line 6 :
            font: 3mm tahoma,arial,helvetica,sans-serif;
/l10n/langpacks/en-GB/chrome/en-GB/global/locale/intl.css, line 6 :
            font: 3mm tahoma,arial,helvetica,sans-serif;

Has someone any idea why we set a 3mm font size on window ? Joe Hewitt, can you
help ? BTW, Joe, we really need an XPI for Document Inspector that could be
installed over the commercial public releases.

Comment 17

[Kathleen :Brade]

Maybe Frank Tang or someone on his team knows why the default font is 3mm
tahoma? (in intl.css)

Daniel--have you checked cvsblame to see if it has any relevant comments?

Comment 18

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

Given the fact that the change from 5mm to 3mm was done without any mention of
a bug # (grrrr !!!!), and given the fact that I have no idea where this
rule originally comes from, that does not help a lot, Kathy...

Comment 19

[Akkana Peck]

Also, on many linux machines arial displays even smaller than the listed point
size -- it's usually better to specify helvetica first, then arial.  This
default will be pretty small for most linux users.

But all the other windows seem able to override this setting with the user's
fonts chosen from prefs; why can't we override it in composer?

Comment 20

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

> But all the other windows seem able to override this setting with the user's
> fonts chosen from prefs; why can't we override it in composer?

Probably because Composer's source view uses a html|textarea and because the
default CSS rules for that specify 'font-size: inherit'... Then we inherit from
all ancestors of the textarea up to the window because none of them specifies a
font-size (font-size is an inherited property).

Comment 21

[Håkan Waara]

This is extremely ugly and makes the HTML source view unusable. Cmanske? Would
be nice to get some traction on this sucker.

Comment 22

[Roy Yokoyama]

cc shanjian

Comment 23

[Charles Manske]

Attachment: patch v1

This is a minimal fix to increase the size for all users.
While it would be better to make this size changeable by a pref (either the
same as the browser's fixed-width size or with a separate pref for Composer),
this is definitely an improvement.

Comment 24

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

Comment on attachment 84937 [details] [diff] [review]
patch v1

r=glazman

Comment 25

[rbs]

Did you try: "font-size: -moz-initial;" This should get the default browser's
size for the current generic font (i.e., the fixed-width size in this case, and
will respond to changes on the fonts pref dialog.

Comment 26

[Charles Manske]

I just tried "font-size : -moz-initial;" and in Windows 2000k, the font size 
looks too large (like what it would be using "font-size: large") and doesn't 
respond to changes in the fixed-width size in prefs :-(

Comment 27

[rbs]

Let me have a try... (I don't fancy much this 120% -- it would like a mystery to
anyone looking at the editor.css file).

Comment 28

[rbs]

initial display: WFM (on Win2K) when I try:

#content-source, #doctype-text {
  font-family : -moz-fixed;
  font-size: -moz-initial;
}

pref change: doesn't work because nsPresContext::PreferenceChanged() has a code 
to avoid to unnecessarily re-layout the chrome when prefs are changed. The 
editor's <HTML> source does respond to pref-changes when I temporarily #if'0 the 
chrome section in nsPresContext::PreferenceChanged(). Do you have IDs on your 
<textarea> that you can use instead of attaching the CSS rules on the chrome 
element that is higher-up? This way, prefs might reach them, and they will fit 
naturally with other font niceties as they get added to the Font panel (e.g., 
minimum font-size, typeface preview).

Comment 29

[Charles Manske]

Attachment: patch v2

Interesting! RBS is correct that the initial size is based on the pref setting.

It looked larger than monospace type in "Normal" mode, but that was an
illusion!
So I think this is the correct fix.
I played around as RBS suggested, e.g., using <html:textarea> instead of 
<textbox>, but the font size would not respond after a pref change.
Note that it *does* use the new pref size in a new Composer window, so I think
we can live without the immediate change in current window for now.
This is still way better than the situation w/o the patch.

Comment 30

[Igor Furlan]

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

Comment 31

[rbs]

Comment on attachment 85920 [details] [diff] [review]
patch v2

I had a look at editor.xul and saw how you are flipping the modes:
<deck>
  <editor/>  // editor mode
  <textbox/> // source mode
</deck>

The edit mode is responding to pref-changes (for the
proportional/variable-width font) given that <editor> creates its own shell to
distance itself from the chrome.

The <textbox/> doesn't have a shell and so it doesn't see pref-changes since
its container shell remains the chrome and the early return in
nsPresContext::PreferenceChanged() is in effect (same story when you tried
<html:textarea>, and BTW if I read the DOM inspector correctly, it showed that
the <texbox/> is an XBL mapping to <html:textarea>).

So the patch is good enough, since a proper fix that reacts to pref-changes
straightaway would require wrapping the <texbox/> in something that creates a
separate non-chrome shell. A fish for another time.

Comment 32

[rbs]

Comment on attachment 85920 [details] [diff] [review]
patch v2

r=rbs

Comment 33

[Alec Flett]

Comment on attachment 85920 [details] [diff] [review]
patch v2

sr=alecf

Comment 34

[kinmoz]

Comment on attachment 85920 [details] [diff] [review]
patch v2

sr=[e-mail]

cmanske, have you verified that things look ok on Linux and Mac with these
changes?

Comment 35

[Kathleen :Brade]

I tested my Mac debug build (trunk) and it seems ok.

Comment 36

[Asa Dotzler [:asa]]

Comment on attachment 85920 [details] [diff] [review]
patch v2

a=asa (on behalf of drivers) for checkin to the 1.1 trunk

Comment 37

[Charles Manske]

checked into trunk

Comment 38

[R.K.Aa.]

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

Comment 39

[Syd Logan]

adt1.0.1-

Comment 40

[Judson Valeski]

please checkin to the 1.0.1 branch. once there remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 41

[Charles Manske]

What? Removing "-" from adt1.0.1 for reconsideration. Mozilla drivers has
approved this. It is a trivial, safe fix affecting only Composer's HTML Source
window. It is also a regression.
We've had LOTS of complaints about this - there are four duplicates 
you can see above as evidence.

Comment 42

[Charles Manske]

Comment on attachment 85920 [details] [diff] [review]
patch v2

Fix was by [e-mail]
r=cmanske

Comment 43

[rbs]

Checked in the MOZILLA_1_0_BRANCH, marking fixed1.0.1.

Comment 44

[scottputterman]

adding adt1.0.1- in case this gets reopened.

Comment 45

[Igor Furlan]

yes...  HTML source is readable on
Mozilla 1.1a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610

Comment 46

[R.K.Aa.]

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

Comment 47

[sujay]

marking verified using 7/16 build...font looks fine to me now...if anyone
disagrees, please REOPEN.

Comment 48

[Charles Manske]

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

Comment 49

[Igor Furlan]

font size on screen 1600x1200  is still a little bit too small...
but it is usefull
Mozilla 1.1b

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020825

Comment 50

[Charles Manske]

Igor: did you try increasing the size in you Browser prefes? (Appearance ->
Fonts -> Monospace size.)