note to self....

Okay, here's a solution to one that's been bugging me for awhile:

The problem is that Mozilla Firefox 1.x under SuSE 9.2 KDE 3.3 has some weirdness with the text select foreground / background color. The fix for this was found [tweaked] from http://www.mozilla.org/unix/customizing.html#prefs.

This fix is documented on the mozilla.org website for Mozilla, but this works [seems to] for Mozilla Firefox [curr ver 1.5.0.4], as well.

The tweak was that my X server didn't like the color names that were used in the example from the website - not sure why "green" or "white" are not being mapped by the X RGB color database, but using the [somewhat] standard HTML color hex number format ('#rrggbb', where rr == red, gg == green, bb == blue, and each color is a 2-digit (8-bit) hexadecimal color component value) seems to work fine.

Note that this fix might be possible in the ${ff_user_app_dir}/chrome/userChrome.css file, but I haven't found the CSS definitions of Firefox user interface elements, yet. That should exist, I believe, but it may be wrapped some sort of XUL implementation verbiage.

Anyway - here are the pertinent entries from my newly created ${ff_user_prof_dir}/user.js file [user.js did not exist by default for Firefox - simply create it and add whatever of the available Javascsript UI style commands are desired - the page linked above has more examples]:

// Set select colors for text:
user_pref("ui.textSelectBackground", "#00ff00");
user_pref("ui.textSelectForeground", "#000000");
// Select color for typeahead find is slightly different:
user_pref("ui.textSelectBackgroundAttention", "blue");
// Not clear when/if widgetSelectBackground ever gets called: let's find out.
user_pref("ui.widgetSelectBackground", "orange");

Notes:

For the shell variables used above -

${ff_user_app_dir} - this is the user's application config and state directory (typically something like $HOME/$USER/.mozilla/firefox/)

${ff_user_prof_dir} - this is the Firefox user profile directory (typically something like $HOME/$USER/.mozilla/firefox/${profilename} where ${profilename} is a string randomly generated for the [default] profile when Firefox starts up - usually the first time.

Labels: 1.5, 3.3, 9.2, color, config, firefox, fix, hack, kde, linux, mozilla, rgb, suse, x

Apparently the blogger.com | "Publish Status" | "Publishing in progress..." throbber page is causing memory leakage and ultimately crashage in Mozilla Firefox 1.5.0.2 (Linux) - I caught it when the CPU load was up to 37%, and the available RAM was down to around 20M (these numbers according to Gkrellm) - I killed it (successfully) before it locked up X, but I am becoming more convinced that it is page content like this that is crashing the bitch...

Labels: 1.5, firefox, linux, mozilla

Fukking Klipper! Goddess save us all, the Advertisers have learned what a browser extension is. Can the spyware spooks and the virus kiddies be far behind?

A little while ago, as Firefox 1.5.0.2 (Linux) was crashing spectacularly on one workstation (vertigo) - and this time w/o the help of any extensions or themes, i might add - I was browsing the prefs.js file for another Firefox install on another workstation (spirit).

The first thing I noticed about the install on spirit (and this would have been true for the vertigo install until I blew away the user profile directory in an effort to get Firefox to quit locking up the X server) is that there are an entire assload of settings that are added by extensions, and (in one case) by something that is not even an extension (I think - still looking at this one).

The next thing I noticed was that certain of the settings contained information about me - or rather, about some things that were on my disc drive.

Some examples - not all of these are "intrusive", I suppose, but most of them are remarkable (in some way), to me:
Interesting - Firefox Edit menu options don't seem to interoperate as expected with the Klipboard tool under KDE - more of Gnomish foolishness.

Labels: add-ons, extensions, firefox, howto, linux

I had some problems getting Firefox to accept/provide arguments to a protocol handler command entered in the about:config page [see previous post for about:config settings], but I have found a workaround, and posted a HOWTO document about it. See: HOWTO Enable Telnet URI Handling in Firefox.

The gripe here is that telnet://host.name:portnum/ URLs didn't work by default in Firefox. The HOWTO gives a fix.

Labels: bash, config, firefox, hack, howto, linux, protocol, script, telnet, x11, xterm

Register Protocol from the Mozillazine Knowledge Base.

Gecko DOM Reference

About:config entries from the Mozillazine Knowledge Base.

pound-perl perl mongers wiki posting about settings for telnet URL.

Labels: config, firefox, gui, hack, howto, linux, x11

Well, it seems like it's been about a day now, and wurx is still up and running - have not started Mozilla Firefox this session. Posting this under Opera 8.52 -

Went so far before now - okay here it is:

a) Firefox 1.0.7 with various extensions and themes loading was crashing a not-quite-stock install of whatever X server shipped with SuSE 9.2

2) Remove 1.0.7 and install Newest Whizbang 2.5.0.2 or something

[NOTE: Couldn't figure out how to do a system-wide, multi-user install for the newest Firefox - may want to look into that later - running local this time]

3) Only a few extensions plugged in this time.

BANG) it didn't work anyway.

So what do YOU think. This is not life it is a SOAP-OPERA

For the record, just a few moments ago,

$uptime
10:01pm up 10:29, 3 users, load average: 0.05, 0.31, 0.31

Labels: 10.07, 2.5, add-ons, crash, extensions, firefox, linux, mozilla, opera, problem, suse

From a comment on the Slashdot discussion Firefox Memory Leak is a Feature (bracketed info is from other posts in the same thread) - these steps describe how to turn off the memory intensive tab history caching Firefox is doing:

[0. type 'about:config' in the Location bar to get the configuration settings page]

1. set browser.sessionhistory.max_total_viewers to "0"

2. It does (try opening a huge Fark photohop thread, huge as in multiple hundreds of pictures, see Firefox ramp up to 600 or 700Mb ram consumption, close the fark tab, see firefox' ram usage drop dramatically to regular ram usage levels)

[more info at >mozillazine]

[some posts suggest this may not be available in versions before 1.5]

Labels: firefox