On Linux the font-size in Inspector is too small and thus hard to read. It is smaller than in the Style Editor. (not on Win, OS X untested). The cause might be in: http://mxr.mozilla.org/mozilla-release/source/browser/themes/linux/devtools/common.css 12 .devtools-monospace { 13 font-family: monospace; 14 font-size: 85%; In the Style Editor .devtools-monospace seems to be used on different elements and not on body, so presumably the font-size 85% gets overridden by sth. else there to be the desired 100%. Workaround is to set font-size: 100% in userChrome.css

I can confirm the same problem on Arch x86_64 with XFCE. The devtools-monospace is 85% but 85% of what? I guess its presuming the font size somewhere from Gnome? But not everyone uses Gnome. This thing is a real pain in the eye. There should be an option to set devtools inspector font size, just like webconsole's font size. Screenshot attached.

On Mac OS X with Retina display the font is also pretty hard to read (too small). I with their was a way to easily adjust it rather than have to tweak a CSS file hiding somewhere on my disk.

(In reply to ncancelliere from comment #3) > On Mac OS X with Retina display the font is also pretty hard to read (too > small). I with their was a way to easily adjust it rather than have to tweak > a CSS file hiding somewhere on my disk. The font size can be adjusted with cmd + / cmd -.

(In reply to Benedikt Breinbauer from comment #0) > On Linux the font-size in Inspector is too small and thus hard to read. It > is smaller than in the Style Editor. (not on Win, OS X untested). > > The cause might be in: > http://mxr.mozilla.org/mozilla-release/source/browser/themes/linux/devtools/ > common.css > > 12 .devtools-monospace { > 13 font-family: monospace; > 14 font-size: 85%; > > In the Style Editor .devtools-monospace seems to be used on different > elements and not on body, so presumably the font-size 85% gets overridden by > sth. else there to be the desired 100%. > > Workaround is to set font-size: 100% in userChrome.css This could be a problem if there is a nesting of 80%. I believe that the inspector case pictured lower on may be resolved by now. Is this still an issue in the style editor?

(In reply to Brian Grinstead [:bgrins] from comment #4) > (In reply to ncancelliere from comment #3) > > On Mac OS X with Retina display the font is also pretty hard to read (too > > small). I with their was a way to easily adjust it rather than have to tweak > > a CSS file hiding somewhere on my disk. > > The font size can be adjusted with cmd + / cmd -. Yes an no. It increases the size of everything in the inspector. The icons and title-bars are all okay. The fonts of stuff in some windows is okay - but whenever source code is shown it's too small. I don't want to increase the size of everything, just the size of the source-code font (which is smaller than the other stuff for whatever reason).

(In reply to Brian Grinstead [:bgrins] from comment #5) > (In reply to Benedikt Breinbauer from comment #0) [...] > This could be a problem if there is a nesting of 80%. I believe that the > inspector case pictured lower on may be resolved by now. Is this still an > issue in the style editor? The style editor seems fine, just added screenshots of the inspector (too small) and the style editor to compare. I don't know how the css files are organised (inheritance) so like bassu I'm wondering 80% of what? My preference for monospace is 11 (default is 12) but that doesn't affect it at all (affects the view source text). Funnily enough by now the font-size in linux/devtools/common.css is now 80% as you say, and not 85% anymore so the problem got worse. (If I'm looking at the correct file at all [1]? For OS X it's 108% [2]. and for Win it's not set [3].) Btw. the workaround in userChrome.css that fixes the inspector is simply: .devtools-monospace { font-size: 100% !important; } Haven't noticed any sideeffects of that workaround yet so /possibly/ the 80% property could be removed (or should be solved differently if there was a reason for it in the first place). [1] http://mxr.mozilla.org/mozilla-release/source/browser/themes/linux/devtools/common.css [2] http://mxr.mozilla.org/mozilla-release/source/browser/themes/osx/devtools/common.css [3] http://mxr.mozilla.org/mozilla-release/source/browser/themes/windows/devtools/common.css

(In reply to Benedikt Breinbauer from comment #9) > (In reply to Brian Grinstead [:bgrins] from comment #5) > > (In reply to Benedikt Breinbauer from comment #0) > [...] > > This could be a problem if there is a nesting of 80%. I believe that the > > inspector case pictured lower on may be resolved by now. Is this still an > > issue in the style editor? > > The style editor seems fine, just added screenshots of the inspector (too > small) and the style editor to compare. > > I don't know how the css files are organised (inheritance) so like bassu I'm > wondering 80% of what? My preference for monospace is 11 (default is 12) but > that doesn't affect it at all (affects the view source text). > > Funnily enough by now the font-size in linux/devtools/common.css is now 80% > as you say, and not 85% anymore so the problem got worse. > (If I'm looking at the correct file at all [1]? For OS X it's 108% [2]. and > for Win it's not set [3].) > > Btw. the workaround in userChrome.css that fixes the inspector is simply: > .devtools-monospace { > font-size: 100% !important; > } > > Haven't noticed any sideeffects of that workaround yet so /possibly/ the 80% > property could be removed (or should be solved differently if there was a > reason for it in the first place). > > [1] > http://mxr.mozilla.org/mozilla-release/source/browser/themes/linux/devtools/ > common.css > [2] > http://mxr.mozilla.org/mozilla-release/source/browser/themes/osx/devtools/ > common.css > [3] > http://mxr.mozilla.org/mozilla-release/source/browser/themes/windows/ > devtools/common.css I'm actually not seeing any nesting of the devtools-monospace class, at least in the markup view. Are you using any custom font sizes for your browser, besides the .devtools-monospace override you found? Paul, what is the reasoning behind the 80% default size for fonts in Linux? Do the screenshots in Comment 2 and Comment 7 look similar to what you see on your system?

(In reply to Brian Grinstead [:bgrins] from comment #10) [...] > I'm actually not seeing any nesting of the devtools-monospace class, at > least in the markup view. Are you using any custom font sizes for your > browser, besides the .devtools-monospace override you found? Nope, no other userChrome styles, same with a fresh profile. Monospace font-setting in preferences also has no effect as mentioned above.

I can't say that I can spot any difference in the style inspector and style editor fonts on Ubuntu 13.10.

Benedikt, in a new tab, can you open this URL: data:text/html;charset=utf-8,<!DOCTYPE><code>foo Then, open the inspector, and tell me which font is bigger. The one in the page or the one in the inspector?

(In reply to Paul Rouget [:paul] from comment #13) > Benedikt, in a new tab, can you open this URL: > > data:text/html;charset=utf-8,<!DOCTYPE><code>foo > > Then, open the inspector, and tell me which font is bigger. The one in the > page or the one in the inspector? Without the userChrome workaround the font on the page is bigger. With the workaround it is the same size. NB: The Fx font preference for monospace does affect the size on the page but not the size in the inspector. The default for monospace is 12, but I've set it to 11 because 12 is too big for the monospace used (Deja Vu Sans Mono). Ergo, the size with the workaround in the inspector is 11 (because it is the same size as on the page). And 85% of that would be 9.35px. Hope that makes sense and helps? The system wide monospace setting for Ubuntu doesn't affect either of those sizes as far as I tested. Anything else I could test? A comparison with Panos' settings might be useful if he doesn't have the same problem on Ubuntu 13.10 (I'm on 12.04).

I'll try it with Ubuntu 13.10 in the next couple of days and post back.

Just tested with a fresh Ubuntu 13.10 install: The system wide monospace setting doesn't affect it, however the system wide default font does (of course). On my 12.04 install I had to decrease that setting because the default is just too big. So that could explain why Panos couldn't spot a difference. The Style Editor font was unaffected by any system wide setting. It is, however, affected by the Fx monospace preference. (Which is expected behaviour IMHO.) So why can't the inspector behave the same way, i.e. inherit from the Fx monospace preference rather than a percentage of a system wide setting (which could lead to side effects like in my case)? Wouldn't that be more consistent and intuitive?

(In reply to Benedikt Breinbauer from comment #16) > Just tested with a fresh Ubuntu 13.10 install: The system wide monospace > setting doesn't affect it, however the system wide default font does (of > course). On my 12.04 install I had to decrease that setting because the > default is just too big. So that could explain why Panos couldn't spot a > difference. > > The Style Editor font was unaffected by any system wide setting. It is, > however, affected by the Fx monospace preference. (Which is expected > behaviour IMHO.) > > So why can't the inspector behave the same way, i.e. inherit from the Fx > monospace preference rather than a percentage of a system wide setting > (which could lead to side effects like in my case)? Wouldn't that be more > consistent and intuitive? I'm not sure why the Style Editor isn't affected by the system wide default. Both frames have the devtools-monospace class applied to the body. The CodeMirror class explicitly has `font-size: inherit` set to override an unrelated rule, but that is inheriting from devtools-monospace, not a system wide default. If you have any ideas why it is working this way on your system, this would be helpful. Regarding the default font sizes - when I test on Ubuntu 12.04 and go to Universal Access -> Text Size -> Small, both the inspector and style editor appear quite (and equally) small - though to be fair, not much smaller than notification messages and the like. I'm guessing the 80% is set to accommodate the most common default font sizings. When I use the default OS font sizing and remove this 80% rule, the markup tree in the inspector seems too big, so the 80% is actually helping in this case.

Screenshot of default OS font sizing in Ubuntu 12.04 with the 80% CSS rule removed for the inspector. The markup tree on the left does not have the 80% rule, while the rule view on the right does.

I still experience this issue on latest Elementary OS (0.2.1) based on Ubuntu 12.04. Where do I find the abovementioned css to resolve this?

(In reply to viktor.eriksson2 from comment #19) > I still experience this issue on latest Elementary OS (0.2.1) based on > Ubuntu 12.04. Where do I find the abovementioned css to resolve this? In the screenshot in Commment 18 I removed the 80% size located here: http://dxr.mozilla.org/mozilla-central/source/browser/themes/shared/devtools/common.css#20. You should be able to apply a user style that does something like: .devtools-monospace { font-size: 100%; }

Benedikt, bassu and others, Just for your information: Bug 964346 Add a font-size options in the devtools options' panel Work around: cmd/ctrl +/-/0 on the focused devtools frame hmm ... just like Brian said in comment 4

Have all Ubuntu users here confirmed the monospace font actually used in Inspector is actually DejaVu rather than Ubuntu Mono? Most monospace fonts are roughly the same physical x-height and width, but there are some distinctly smaller exceptions, among which include Ubuntu Mono. Note such differences vary with logical DPI, one reason why this attachment is from logical 120 DPI, so most viewers of it (using 96 DPI) will be able to note differences that are due to DPI rather than to font family by theirselves opening http://fm.no-ip.com/Auth/Font/fonts-face-samplesM.html in a Gecko (or KHTML) browser.

(In reply to Felix Miata from comment #22) > Have all Ubuntu users here confirmed the monospace font actually used in > Inspector is actually DejaVu rather than Ubuntu Mono? The font actually used in Inspector is the font the user has selected (or the default one) in Edition/Preferences/Content/Advanced/Fixed Width If I set Edition/Preferences/Content/Advanced/Fixed Width to monospace (which I believe is the default setting in Firefox), then the monospace font actually used in Inspector is "DejaVu Sans Mono" which is the one assigned by the os $ fc-match monospace DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book" If I set Edition/Preferences/Content/Advanced/Fixed Width to "Ubuntu Mono", then the glyphs seems to me to be harder to read than if "DejaVu Sans Mono" had been chosen. I am using Kubuntu 14.04.4 LTS (trusty).

This provides a more expansive way to peruse the wide disparity in physical sizes among various monospace font families at identical nominal sizes. Hopefully it makes obvious why Ubuntu Mono might be harder to read than DejaVu Sans Mono, and why for some, fonts in Domi might be truly painful to try to read even on a relatively low DPI display. Source URL is currently at: http://fm.no-ip.com/Auth/Font/fonts-comps-linuxmono.html

Duping this to Bug 1319079, where we are going to set the monospace font size to 11px in linux