On this page, the three tables are not being resized by the CSS. (Works fine in IE4.) See also bug #3263.

This is a Nav compatibility mode quirk. In Nav, font style doesn't penetrate into table cells. Try it in standard mode.

Hmm. Fair enough.

This is happening again, even in Standard mode. I am using Viewer of 1999-03-22, and selecting Style|Compatibility Mode Pref|Standard ...from the menu. I then go to the page, http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/tablesize.html ...and the three tables render the same size. Is there something wrong with the quirk-mode flag, or has the bug actually regressed? When the bug was verified (1999-03-25) the three tables rendered at different sizes if standard mode was selected.

The problem is a failure in the prefs system. The presentation context never sees the standard mode pref and defaults to compatibility mode.

Reassigning to McMullen

Is this bug resolved, invalid? If so, please update status to resolved.

Are you aware that the prefs file is expected to be in a new location now, and with the name prefs50.js? My postings explain the details. However, somebody seems to have broken AppRunner's prefs today, too. It was all working last week, but today, no. I'll have to investigate.

Set milestone to M5. John, should we fix this for M5?

Apprunner's prefs are actually working. I have also verified that this bug occurs in viewer and apprunner. I have questions: What is the name of the pref that is supposed to be read (standard/ compatibility)? Did it ever work correctly in apprunner? (I removed the "invalid" status).

Since this is allegedly a regression, I do think I should fix it for M5

Upgrade to P1 since it's a regression.

The problem appears to be that the preferences service depends on the file locator service, which is not being registered in viewer. So I'll have a fix soon.

Groan. The file locator is in the appshell dll, which is not a part of viewer. This gets more compicated by the minute... what about embedding applications? The "right" fix is to make the file locator service an auto-registered component. The quick fix is to make the preferences do something sensible if the file locator service is absent. So I'll do the quick fix, and then file another bug.

I just checked in the quick fix. This now works in viewer, because if the file locator is absent, I use a file called 'default_prefs.js' in the current working directory. So now, the style pref menu works, the change sticks, and after switching it to "standard" the evil test passes. End of bug. I filed a new bug #5571 about the need for the file locator service to be in a separate, auto-registered dll.

Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.