Closed
Bug 36914
Opened 25 years ago
Closed 25 years ago
FRAMESETs ignored in utf-8 pages
Categories
(Core :: Internationalization, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: vladnc, Assigned: ftang)
References
()
Details
Attachments
(2 files)
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID: 2000041805
Pages saved in utf-8 format from Win2k+NotePad don't display any frames.
Reproducible: Always
Steps to Reproduce:
1. Start Notepad from Win2k;
2. Create a page with frames;
3. Add the following lines to the HEAD area:
<meta http-equiv = "Content-Type" content = "text/html; charset=utf-8">
<meta http-equiv = "Content-Language" content = "ro">
4. Save the file using Save As; Specify utf-8 for the encoding in the Save As
dialog;
5. Start Mozzila.
6. Open the file in Mozzila.
Actual Results: No frames are displayed, or strange characters are displayed.
Expected Results: The page should display the frames.
|
Reporter | |
Comment 1•25 years ago
|
||
|
|
||
Comment 2•25 years ago
|
||
Note that the testcase doesn't work in Netscape Communicator 4.7.
It only displays as a "?". And mozilla on PC/Linux, build 2000042113
seems to do the same. And there seem to be some characters before the
beginning <html> that cause this question mark to appear. If you remove
them you will see two frames as intended.
If this is a bug, it does not have anything to do with FRAMESETs, but with
non-ASCII characters starting an HTML document. Changing component to
from HTMLFrames to Internationalization.
Assignee: pollmann → ftang
Component: HTMLFrames → Internationalization
QA Contact: petersen → teruko
|
|
||
Comment 3•25 years ago
|
||
CC'ing Harish.
|
|
||
Updated•25 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
|
||
Comment 4•25 years ago
|
||
This is the content model I get when visiting the page in question:
docshell=00CE33A0
html@02811378 refcount=3<
head@02811318 http-equiv=Content-Type content=text/html; charset=utf-8 refcoun
t=2<
meta@02AA8EC8 http-equiv=Content-Type content=text/html; charset=utf-8 refco
unt=2<>
Text@02AA8A90 refcount=2<\n >
meta@02AA8968 http-equiv=Content-Language content=ro refcount=2<>
>
body@0288B078 refcount=3<
Text@02AA84D0 refcount=4<\ufeff\n \n \n \n \n \n>
>
>
|
|
Reporter | |
Comment 5•25 years ago
|
||
To afranke@ags.uni-sb.de, about "it does not have anything to do with FRAMESETs"
If I use <body> instead of <frameset> the page works just fine. So the
<frameset> and/or <frame> tags generate the problem. By the way, the non-ASCII
characters indicate a utf-8 text file.
I'll submit a test case to illustrate this.
|
|
Reporter | |
Comment 6•25 years ago
|
||
|
|
Assignee | |
Comment 7•25 years ago
|
||
The beginning BOM in utf8 cause some problem. We probably should not generate
any BOM when we convert from UTF8 to PRUnicode. Also, if we hit any BOM in the
mid of the text, we should not render it as ? cc erik
Status: NEW → ASSIGNED
|
|
Assignee | |
Comment 8•25 years ago
|
||
here is the fix
Z:\mozilla\intl\uconv\ucvlatin>cvs diff -u nsUTF8ToUnicode.cpp
Index: nsUTF8ToUnicode.cpp
===================================================================
RCS file: /m/pub/mozilla/intl/uconv/ucvlatin/nsUTF8ToUnicode.cpp,v
retrieving revision 1.6
diff -u -r1.6 nsUTF8ToUnicode.cpp
--- nsUTF8ToUnicode.cpp 2000/02/05 02:20:36 1.6
+++ nsUTF8ToUnicode.cpp 2000/04/24 18:33:17
@@ -146,7 +146,8 @@
*out++ = 0xDC00 | (0x000003FF & mUcs4);
}
} else {
- *out++ = mUcs4;
+ if( 0xfeff != mUcs4 ) // ignore BOM
+ *out++ = mUcs4;
}
//initialize UTF8 cache
|
|
Assignee | |
Comment 9•25 years ago
|
||
add jbetak to the cc
notice 0xfeff is the BOM
|
|
Assignee | |
Comment 10•25 years ago
|
||
make the UTF8 to Unicode converter *eat* the UTF-8 BOM
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 11•25 years ago
|
||
On build 2000042508/Win2k both attachments cause Mozilla to crash. Then why
is this bug marked as RESOLVED & FIXED?
|
||
Comment 12•25 years ago
|
||
"04/23/00 21:46 Test case" makes build 2000042512 crash
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
Reporter | |
Updated•25 years ago
|
Severity: major → critical
|
|
||
Comment 13•25 years ago
|
||
On PC/Linux, build 2000042609, the testcase works fine.
Note that the early 4/25 builds crash very frequently in
other situations, too, whereas both the 4/24 and 4/26 builds
do not show this crashy behaviour. Thus I think this bug
can be closed again.
vladnc@hotmail.com: My main point was that the problem disappears
if you remove the BOM at the beginning of the HTML file. Sorry for
the aggressive formulation.
I leave it up to you to mark this bug fixed again.
|
|
Reporter | |
Comment 14•25 years ago
|
||
Bug looks dead in build 2000042708...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
|
|
||
Comment 15•25 years ago
|
||
I verified this in 2000042809 Win32 build with Window 2000.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•