Closed Bug 93343 Opened 23 years ago Closed 23 years ago

UTF-16 page displayed incorrectly

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: mseitz, Assigned: ftang)

References

(
URL
)

Details

(Keywords: intl, regression)

Attachments

(1 file)

patch
(deleted), patch
harishd
: review+
vidur
: superreview+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010628 BuildID: 2001080203 Instead of rendering the page, Mozilla displays the page source. The source appears as ASCII characters with rectangle characters between each ASCII character. It appears the page source is in UCS16 format but Mozilla is treating it as an ASCII text file. Reproducible: Always Steps to Reproduce: 1. Go to www.sellsbrothers.com/tools Actual Results: A distorted version of the page source was displayed Expected Results: The page source should be interpreted and rendered.
Interesting.... here's what I see with linux build 2001080208. The page source is shown. If I delete the first two bytes of the file, the source is only shown if charset autodetect is: Off, Russian, Ukrainian, East Asian, Japanese, For other values of autodetect (Korean and the various Chinese ones), the page is detected as UTF-16LE and shown correctly...
Assignee: asa → yokoyama
Status: UNCONFIRMED → NEW
Component: Browser-General → Internationalization
Ever confirmed: true
QA Contact: doronr → andreasb
Keywords: intl
QA Contact: andreasb → ylong
I checked the nsParser code but it's still there. http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsParser.cpp#2601 ylong: Is this regression? I can't reproduce this using NS6.1 However, I see it using trunk 20010730 ==== assigning to ftang.========
Assignee: yokoyama → ftang
I guess it's a regression: I can reproduce it on my Win2k-CN on 07-25 branch build, but 07-19 branch build is OK.
N4.x display them correctly.
Status: NEW → ASSIGNED
*** Bug 94225 has been marked as a duplicate of this bug. ***
reassigning per ftang's request
Assignee: ftang → jbetak
Status: ASSIGNED → NEW
accepting and targeting post-0.9.4. Will clarify with ftang, whether this is acceptable...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
The meta tag said charset=unicode It does have a BOM in front. move back to ftang to look at
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
mark it as assign
Status: NEW → ASSIGNED
Summary: UCS16 page displayed incorrectly → TF-16 page displayed incorrectly
It looks like vidur's 3.254 check in cause this problem. Vidur, we should only ignore those UTF-16/32 when we get them from meta tag. We should not ignore them if we get them from the byte order mark.
Summary: TF-16 page displayed incorrectly → UTF-16 page displayed incorrectly
Attached patch patch (deleted) — — Splinter Review
I think this is introduce after n6.1 beta. regression. harishd- can you r= this vidur- can you sr= this?
Keywords: regression
Blocks: 104056
Comment on attachment 53819 [details] [diff] [review] patch r=harishd. Suggestion: nsICharsetAlias creation could be delayed.
Attachment #53819 - Flags: review+
Blocks: 104060
No longer blocks: 104056
Blocks: 104148
No longer blocks: 104060
Comment on attachment 53819 [details] [diff] [review] patch sr=vidur
Attachment #53819 - Flags: superreview+
Blocks: 104060
No longer blocks: 104148
fixed and check in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
No longer blocks: 104060
Works for me in build 2001110903
It display fine on 11-16 trunk build, mark it as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: