Closed Bug 3264 Opened 25 years ago Closed 25 years ago

Tables ignore font-size property

Categories

(Core :: Preferences: Backend, defect, P1)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: ian, Assigned: mcmullen)

References

()

Details

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

See also bug #3263.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
This is a Nav compatibility mode quirk. In Nav, font style doesn't penetrate
into table cells. Try it in standard mode.
Status: RESOLVED → VERIFIED
Hmm. Fair enough.
Status: VERIFIED → REOPENED
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.
Assignee: peterl → hshaw
Status: REOPENED → NEW
Component: Style System → libPref
The problem is a failure in the prefs system. The presentation context never
sees the standard mode pref and defaults to compatibility mode.
Assignee: hshaw → mcmullen
Reassigning to McMullen
Is this bug resolved, invalid? If so, please update status to resolved.
Target Milestone: M6
Resolution: INVALID → ---
Target Milestone: M6
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.
Target Milestone: M5
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
Priority: P2 → P1
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.
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend
You need to log in before you can comment on or make changes to this bug.