[SOLVED] Why do my Firefox URL bar fonts look like this?

[willrose]

I'm running Porteus LXDE 3.0.1 i486 from a frugal ISO install, but even when running from a LiveCD my Firefox URL bar fonts look like this.


Anybody have any idea what's going here? Thanks.

[brokenman]

Bizarre. Do you get any error output when running firefox from a guest terminal (apart from the glib-critical error)?

Can you try updating your cache?

Code: Select all

/usr/bin/update-gtk-immodules
/usr/bin/update-gtk-immodules-3.0
/usr/bin/update-pango-querymodules
/usr/bin/update-gdk-pixbuf-loaders
/usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas

[willrose]

No errors from the terminal aside from the glib-critical one.

I ran the code above from a root terminal, but it doesn't seem to have helped. I did get some warnings from the last command though.

Code: Select all

root@porteus:/home/guest# /usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas
warning: Schema 'apps.gecko-mediaplayer.preferences' has path '/apps/gecko-mediaplayer/preferences/'.  Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated.
warning: Schema 'apps.gnome-mplayer.preferences' has path '/apps/gnome-mplayer/preferences/'.  Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated.
warning: Schema 'org.gnome.crypto.cache' has path '/desktop/gnome/crypto/cache/'.  Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated.
warning: Schema 'org.gnome.crypto.pgp' has path '/desktop/gnome/crypto/pgp/'.  Paths starting with '/apps/', '/desktop/' or '/system/' are deprecated.

[brokenman]

https://support.mozilla.org/en-US/questions/999333

IT sounds like a theme or font problem with your particular video card rending. Strange that nobody else has reported it though.

[willrose]

Ah thanks for the link. It did lead me to two working solutions.

1. Install the FxChrome theme add-on, as per this suggestion. I tried it out for kicks and it did fix the problem, but I don't like running custom themes or extraneous add-ons if I don't have to.

2. As per this suggestion, enter about:config and set the gfx.xrender.enabled boolean to false.

As for nobody else here reporting it, it might not be too surprising. There seem to be similar reports from users of other distros on old hardware. I'm running a pretty old Toshiba laptop here with a 2GHz Mobile Celeron and an integrated Intel 82852/855GM. I wasn't getting the font rendering issue on my primary Crunchbang install, but then again they're use a slightly older version of Debian's Iceweasel instead of Firefox. There are some mentions of Fx 29 being the version that started causing problems.

On perhaps a related note, while waiting for a Fx fix, I downloaded Opera through USM and immediately ran into another issue as detailed here.

Anyways, thanks for the help!

[fanthom]

could be due to the SNA acceleration still troubling with older chipsets. please try reverting to UXA as per this post:
http://forum.porteus.org/viewtopic.php? ... 092#p15092

[willrose]

Hmm... I might need some guidance here. I seem to be doing something wrong. Sorry in advance for the long description.

I couldn't find the file "/etc/X11/xorg.conf" in Porteus, so as per the directions in your link, performed the following steps:
- Booted Porteus from SDA2 into text mode by adding "3" to the GRUB2 kernel parameters
- Typed in "X -configure", let it run
- Typed in "init 4" to enter graphics mode
- Found the generated /root/Xorg.conf.new file and saved it somewhere I could retrieve it later

Now, because I boot into a Porteus ISO file on SDA2, in order to copy that "Xorg.conf.new" file into "/porteus/rootcopy/etc/X11/xorg.conf.d/" as "10-uxa.conf", I need to extract the ISO, make modifications, and then recreate the ISO. To do this, I did the following:
- Booted into CrunchBang on SDA1
- Used file-roller to extract the Porteus .iso to a directory called ISO on SDA2
- Pasted the renamed "10-uxa.conf" file in the proper place
- Recreated the ISO by running "genisoimage -R -o Porteus-LXDE-v3.0.1-i486-mod.iso ISO"
- Modified the GRUB2 menu entry to point to this new ISO

When I tried to reboot in Porteus, the startup got all the way through the text output, but once it came time to load the GUI, all I got was a black screen. In order to make sure the problem was with the UXA setting and not anything else, I recreated my own ISO once again without the "10-uxa.conf" file. When I tried to boot into this one, I got stuck on a black screen once again, which makes me believe I messed up somewhere in the ISO extraction or recreation. Any idea what I might have done wrong? Thanks.

[fanthom]

better use /porteus/make_iso.sh script for ISO generation.

anyway - no need to do it yet. please confirm that UXE works first.
boot Porteus as normal -> create /etc/X11/xorg.conf.d/10-uxa.conf -> reload Xorg with 'init 3', then 'init 4' commands -> confirm that you can see UXA string instead of SNA in /var/log/Xorg.0.log.

[willrose]

Ah ok. I didn't realize I could slip back to text mode once booted into graphics mode. I also thought that the 10-uxa.conf file had to be there on boot (hence trying to rebuild the ISO), but obviously that's not the case, and I am now just figuring out that everything in the "rootcopy" folder within the ISO gets copied onto the root filesystem on boot. Duh.

Anyways, I reset my Firefox about:config entry which re-broke the URL bar, and instead tried what you suggested. Everything seems fine. When I look in the "Xorg.0.log" file, I do see "UXA" mentioned a couple times instead of "SNA".

Code: Select all

[   343.066] (**) intel(0): Option "AccelMethod" "UXA"
...
[   343.644] (II) UXA(0): Driver registered support for the following operations:
[   343.644] (II)         solid
[   343.644] (II)         copy
[   343.644] (II)         composite (RENDER acceleration)
[   343.644] (II)         put_image
[   343.644] (II)         get_image

I'm assuming this is a better solution than simply setting Fx's "gfx.xrender.enabled" boolean to false? From what I'm gathering, I'm assuming that the Fx solution turns off 2D acceleration altogether, while your solution just falls back to an older implementation?

[fanthom]

I'm assuming that the Fx solution turns off 2D acceleration altogether, while your solution just falls back to an older implementation?

not 100% sure about the first one but second one is correct. if it works fine with UXE then leave it like that.

thanks