195428 - Rendering bug on \x97 character

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Rishi Khan]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030210

Under the section "Venezuela Falling Behind" today Feb, 28. Mozilla does some
funky big space after the \x97 character (right after "dragging for an
impossibly long time") and the \x92 character. I've seen this happen on slashdot
before. Strangely, it renders properly if I downnload the page (via wget) and
view it locally. Also, it works right in the archive:
http://slashdot.org/index.pl?issue=20030228&mode= 
Beats me, why it works in all of these cases, but not on the main page. I'll try
to find a more persitent example.

Reproducible: Sometimes

Steps to Reproduce:
1. You have to go to slashdot pronto and hope the article is still on the main
page. It seems to render fine from the archive.

Actual Results:  
see this picture:
www.dbi.tju.edu/bugzilla_error/actual.jpg

Expected Results:  
www.dbi.tju.edu/bugzilla_error/expected.jpg

Comment 1

[Greg K.]

Rishi, this is probably due to bad Character Coding autodetection. Do you have
that enabled?

If that's the case, there's already a bug about this somewhere.

Comment 2

[Rishi Khan]

How do I check if I have Character Coding autodetection enabled?

Comment 3

[Rishi Khan]

*** Bug 195470 has been marked as a duplicate of this bug. ***

Comment 4

[Greg K.]

View/Character Coding/Auto-Detect.

Comment 5

[Rishi Khan]

I have that option set to "(Off)". So, that's not the issue here. I'll work on
trying to find a more reporducible example.

Comment 6

[Frankie]

WFM Moz 2004092005 OSX