Jump to article
< >

Active GUI element

Static GUI element

Code

WPS object

File/Path

Command line

Entry-field content

[Key combination]

more

Tips

We scan the Web, Usenet and the OS/2 mailing lists looking for these gems. Have you run across an interesting bit of information about OS/2 or eComStation recently? Please share it with all our readers. Send your tips to tips@os2voice.org. If you are interested in joining a particular OS/2 mailing list, check out the VOICE Mailing List page for subscribing instructions for a large variety of existing lists - http://www.os2voice.org/mailinglists.html.

These tips are from OS/2-eComStation users and in some cases can not be verified by myself. Please heed this as a warning that if you are not sure about something, don't do it.

New Tips Editor
July 1, 2008

We finally have a new Tips Editor. Mark D. Overholser has kindly agreed to take the position. He is currently in the process of making himself acquainted with the VOICE Newsletter environment. If you happen to find interesting bits of information about working with OS/2, eComStation, and computers in general, please contact Mark.

top top

Firefox 3.0 Responsiveness
June 2008

Our Editor-in-Chief reported a problem with the newly released Firefox 3.0 at bugzilla.mozilla.org:

After a while of inactivity, Firefox starts some cleanup actions in the background. On OS/2, this causes the whole desktop interface to be blocked for a short time.

Reproducible: Always

Steps to Reproduce:

  1. Start Firefox
  2. Do nothing
  3. When Firefox starts cleanup activities in the background, move the mouse.

Actual Results:

If you move the mouse during this period, the pointer does not follow. After the blocking period, it is drawn at the correct new location.

Expected Results:

The pointer position should be updated continuously.

I also suspect that the user inactivity detection via Doodle's Screensaver (using 1.9pre here) does not work as it should. The problem described above occurs after not using Firefox for a while and regardless of the use of other applications.

Others had the same problem, and after a few tests, it turned out that the anti-phishing database in urlclassifier3.sqlite can get very large (over 50 MB) and cause the problem as explained by Dave Camp:

OK, a few notes:

  • Unfortunately, 50 megs is not unusually large for right now—in addition to the fact the size of the file for malware and phishing data is a lot bigger than just phishing data (urlclassifier2.sqlite only had phishing data), there are a few artifacts of the updating process that are making it bigger than it should be. After some fixes on the Google side, this size needed will go down.
  • What's happening in the background is updating the DB with new data from Google.
  • OS/2 is probably hitting the same problem Linux was hitting in bug 430530. The solution there was to trade some memory for disk IO. The patch sets pref("urlclassifier.updatecachemax", 104857600) on Linux—you might need to do the same on OS/2.

Peter Weilbacher conducted some tests together with a few users, and after positive feedback committed the change to the code. Until a new version is released, you can set the value yourself:

Happy browsing!

Formatting: Christian Hennecke
Editing: James Moe