Closed Bug 305997 Opened 19 years ago Closed 15 years ago

window in frame w/diff encoding from main frame not displayed correctly

Categories

(Firefox :: General, defect)

1.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: flamingspinach, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

The webserver for this site, for some reason, sends the HTML pages variously in
UTF-16 Little Endian encoding, and ISO-8859-1 (I believe this is called
Latin-1?). The main page contains three frames - a top frame, a sidebar, and a
content frame. The links in the sidebar frame open pages in the content frame,
but many of these links, when clicked, cause the content frame to be filled with
garbage, mostly Asian language characters. Which links invoke the bug and which
do not seems to vary, according to the webmaster, who I am in contact with, but
this appears to be an issue with the webserver and not with Firefox.

When a link that, when opened in the content frame, would produce garbage, is
instead opened in a new tab or new window, the page loads correctly.

THEREFORE:

I believe Firefox contains a bug, involving the character encoding used to
display HTML files within frames - namely, that it assumes that the encoding of
the main page containing the frames, in this case UTF-16 Little Endian, is the
same as that of the HTML file within the frame, which in many cases is an
erroneous assumption (i.e. when such a page is actually in ISO-8859-1).

Reproducible: Always

Steps to Reproduce:
1. Open http://www.kuro-rpg.com/ in a tab.
2. On the sidebar, click various links, which will open in the content frame.
Some of these links should produce the problem. For me, these are always the
same links, and include all the links under "Misc" at the bottom of the sidebar,
among others.
Actual Results:  
The content frame contains a plain text file, encoding UTF-16 Little Endian,
full of gibberish involving various Asian language characters. By navigating in
the context menu to This Frame -> View Source, then going to the View menu and
selecting Character Encoding -> Western (ISO-8859-1), I noticed the text in the
View Source window change from the same gibberish in the frame to an orderly
HTML file, viewed in plaintext.

Expected Results:  
Instead, Firefox should have not assumed that the frame's contents were of the
same encoding as the main page, and rendered it in ISO-8859-1.

I am using the default theme. Nothing crashed, therefore there is no Talkback
crash ID. My computer is running Microsoft Windows XP, Service Pack 1.

The Firefox extensions I have installed are: DOM Inspector 1.0, FlashGot
0.5.9.6, Adblock v.5 d2 * nightly 39, ChatZilla 0.9.68a, Tabbrowser Preferences
1.2.7.1, Wayback 0.2, Wikipedia 0.6.0.7, Nuke Anything 0.2, Mozilla Archive
Format 0.6.2, Live HTTP Headers 0.10, and SETI@home User Stats 0.3.6 .
WFM - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050825
Firefox/1.0+
this is actually a feature

the guessing code guesses when your server doesn't provide a hint that the frame
host is a good hint.
(In reply to comment #2)
> this is actually a feature
> 
> the guessing code guesses when your server doesn't provide a hint that the frame
> host is a good hint.

Am I correct in believing that Firefox is able to guess the proper encoding of
the page by analysis of the content, with fairly good accuracy? If so, shouldn't
that process override the "guess by main frame" approach? Also, don't know if
you meant this but kuro-rpg.com is not my server.

-fs
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode
Version: unspecified → 1.0 Branch
As the cited URL has disappeared in the almost 5 years since this bug report was filed, I am unable to retest. I am also unable to set up similar conditions, because I have no idea how to do so. If anyone else could contrive to do this, that'd be great.
Going to WFM this unless some else can repro
No reply, INCOMPLETE. Please retest with Firefox 3.6.3 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.