Closed Bug 292058 Opened 20 years ago Closed 19 years ago

Inconsistent font rendering between page refreshes

Categories

(Firefox :: General, defect)

All
Windows 2000
defect
Not set
trivial

Tracking

()

RESOLVED EXPIRED

People

(Reporter: moz-spam-filtered.20.nickj, Assigned: bugzilla)

References

()

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Please see URL: http://nickj.org/misc/not-obeying-pre.html 

Press refresh a few times (make take around 5 times), and sometimes it will
display one or two rows of the 'message' column in a different font, and
sometimes it won't.

Yes, I know this is page is not valid HTML 4.01 (see:
http://validator.w3.org/check?uri=http%3A%2F%2Fnickj.org%2Fmisc%2Fnot-obeying-pre.html)
. However, I would still expect it to render consistently between refreshes,
given the same input, but it does not. I'm marking the reproducibility as 'every
time' as I can consistently reproduce it after 5 or so refreshes, even though it
doesn't happen on every page view.

Reproducible: Always




I'm running Win2000, but I have also seen the same problem on Linux (might have
been Gnome's Epiphany browser), so I think this means it's a
platform-independent Gecko font rendering problem.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050426
Firefox/1.0+

Reloaded the page 20 - 40 times on a current nightly and 1.0.3 no changes. The
middle line always always uses a proportional font which is the first screenshot.
i dont see any difference upon refresh either BUT i still beleve him because i
get same troubles with Tables resizing randomly in refresh.. even a whole image
and a table is dublicating on a page at random refresh... 
the bug is really that same code can get RANDOM RESULT.
> Reloaded the page 20 - 40 times on a current nightly and 1.0.3 no changes.

That's weird. I can't explain the difference - I can only describe the symptoms
that I'm experiencing.

> The middle line always uses a proportional font
> which is the first screenshot.

The first one? (i.e. attachment 181942 [details]) 

Well, that's weird too. All the of the 'message' cells use the same html code
(i.e. start a cell, open a pre tag, display some content, close the pre tag,
close the cell).

Therefore, for it to render consistently, you should always get the _second_
screenshot (i.e. attachment 181943 [details]), where they all those cells are in the same
font.

For it to render the first screenshot is still inconsistent - except this time,
the inconsistency is between cells within the same table that use the same
structure, rather than between refreshes.

> the bug is really that same code can get RANDOM RESULT.

Exactly - well put.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050428
Firefox/1.0+

WFM
I signed up for a trial account at BrowserCam, and pointed it at this test page
to see how the message cells are rendered in different browsers. The results are
available for the next 24 hours at:
http://www.browsercam.com/public.aspx?proj_id=159428 (Limited to 24 hours as
it's only a freebie trial account)

The results were as follows:

Same font rendering in all 'message' cells:
-------------------------------------------
AOL 9.0 on Windows 2000 Pro
Internet Explorer 4.0 on Windows 98
Internet Explorer 5.0 on Windows 2000 Pro
Internet Explorer 5.2 on Mac OSX 10.3
Internet Explorer 5.5 on Windows 2000 Pro
Internet Explorer 6.0 on Windows 2000 Pro
Internet Explorer 6.0 on Windows XP
Konqueror on Red Hat Linux 8.0
Netscape 4.78 on Windows 2000 Pro
Netscape 4.8 on Red Hat Linux 8.0
Opera 6.0 on Mac OSX 10.3
Opera 7 on Windows 2000 Pro
Opera 7 on Windows XP
Safari 1.2 on Mac OSX 10.3

Different font rendering in the middle 'message' cell:
------------------------------------------------------
Firefox 1.0 on Red Hat Linux 8.0
Firefox 1.0 on Windows 2000 Pro
Firefox 1.0 on Windows XP
Mozilla 1.6 on Mac OSX 10.3
Mozilla 1.7 on Red Hat Linux 8.0
Mozilla 1.7 on Windows XP
Mozilla 1.7.5 on Windows 2000 Pro
Netscape 6.2 on Windows 2000 Pro
Netscape 7.0 on Mac OSX 10.3
Netscape 7.2 on Red Hat Linux 8.0
Netscape 7.2 on Windows 2000 Pro
Netscape 7.2 on Windows XP


Please feel to verify these results for yourself at the above URL.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: