Closed Bug 272385 Opened 20 years ago Closed 19 years ago

No rendering for XSLT combined with CSS in Unicode

Categories

(Core :: XSLT, defect)

Product:
Core
Component:
XSLT
Version:
1.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED EXPIRED

People

(Reporter: stude05f, Assigned: peterv)

Details

Attachments

(1 file)

Examples to reproduce the errors
2.25 KB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0

I transform XML-files with XSLT-files to html pages. The XSLT includes CSS-files.
The rendering goes fine if I use the following encodings:
the xslt-file: Unicode UTF-8 without signature
the css-file: Unicode UTF-8 with signature

If I use "Unicode UTF-8 with signature" for the xslt-file the window in the
firefox (and in the mozilla) is shown as a blank grey page.
If I use "Unicode UTF-8 without signature" for the css-file the html-page gets
correctly rendered on screen, but no css-information gets used from the css-file.

Reproducible: Always
Steps to Reproduce:
already descriped under details

Actual Results:  
already descriped under details

Expected Results:  
always render the page correct (like for example the internet explorer does).
Please provide a sample to reproduce. You can put the files inside a zip file
and provide as an attachment, or best give an url where you have set up the
required files.

I suspect 'Unicode UTF-8 with signature' is a UTF-8 file with a BOM at the
start, and 'Unicode UTF-8 without signature' has no BOM, but I have no proof
without your files.

If my hypothesis is correct, the expected behaviour is that all files should NOT
have a BOM in order to work correctly. 
There *might* be a special provision that allows BOM for CSS files, which would
explain what you see.

Is the CSS sent from the server with the correct information, so that Mozilla
can know it's encoding ?
( Check here about how to do that correctly :
http://www.w3.org/International/questions/qa-css-charset )

The examples in the three directories have the same content. The difference is
just the coding an withit the different behaviour in mozilla / firefox
(same correct behaviour for all three in internet explorer).
Short discription to all three directories an their behaviour:
okay: redering is okay
css_error: the css-file has a different encoding and gets not used by
mozilla/firefox
xsl_error: the xsl-file has a different encoding and no rendering happens at
all.
Okay I've attached some examples with the encoding setting, descriped in first
description.
The files where loaded straight from the harddisk.
I'm not sure yet what is happening in "xsl_error", but "css_error" seems to me
INVALID:

We determine the encoding of a .css file according to a slightly extended
version of the rules at http://www.w3.org/TR/REC-CSS2/syndata.html#q23:

(from highest priority to lowest)
1 An HTTP "charset" parameter in a "Content-Type" field.
2 The @charset at-rule.
3 Encoding corresponding to a BOM in the.css file
4 "charset" attribute of an HTML LINK element or <?xml-stylesheet?> processing
instruction that referenced the style sheet
5 The encoding of the parent sheet
6 The encoding of the referencing document
7 Fall back to ISO-8859-1

In the case of css_error 1-5 are missing so we end up using the encoding of the
referencing document, which is the transformed HTML in UTF-16, so we fail to
decode the stylesheet.
does the XSLT still fail if you're not using CSS at all? I.e. is it a pure XSLT
bug or is there some problem with interaction between XSLT and CSS?
Reporter, please note that this component is for the actual Website of Firefox,
not for website problems with Firefox.
Component: Web Site → XSLT
Product: Firefox → Core
Summary: No rendering for XSLT compined with CSS in Unicode → No rendering for XSLT combined with CSS in Unicode
Version: unspecified → 1.0 Branch
Component: XSLT → Style System (CSS)
I think it is a general problem for all kind of documents. As I already
descripted, the xslt-rendering can fail if I use an encoding like "Unicode UTF-8
with signature". But for some encodings I use for css, the html-pages gets
rendered, but no css-information gets used.
And by the way. If attached already three different examples for reproduction.
I'm still confused. In which of these cases does the problem occur?

A. Using CSS with HTML
B. Using CSS with XML (without xslt)
C. Using CSS with XSLT
D. Using XSLT without CSS
I've tried it with html and css. Loading was done just right from harddisk.
There I didn't get any problems with the encoding of the css-file.
By the way - did you try any of my examples? Didn't you get any problems /
different results. All three have the same content, but different file encodings
(as described earlier). 
It's not enough that I get different result. I also need to understand what the
desired result is and in what situations I don't get that result. It could
simply be that you missunderstand how things are supposed to work.

In what situations in comment 8 does the problem occur?
I had the troubles in situations C and D (of comment 8).
ok, sounds like this isn't related to css at all then, no?

Could you please provide a testcase that uses only xslt with no css.
Assignee: bugs → peterv
Component: Style System (CSS) → XSLT
QA Contact: keith
ok so the problems are as follows:

The reason css_error doesn't render is as described in comment 4. There is no
encoding information given which means that we ultimatly fallback to using the
encoding in the document. In the xslt you specify that the document should have
UTF-16 encoding which is not the encoding of the CSS file.

Either specify an encoding in the css file, or make the result document use
UTF-8 encoding (by explicitly specifying it in the xslt, or by removing any
explicit mention of the encoding since it'll fallback to the encoding of the
source document which is utf8 encoded.)

No bug here.


The reason xsl_error doesn't render is because we don't recognize it as an xml
file. Since the file has extension .xslt your OS won't recognize the filetype so
mozilla won't be told any mimetype for the document and will have to guess.
However the code that guesses mimetypes is unable to deal with BOMs which means
that we give up and declare the file unknown.

In order to get things to work either configure your OS to recognize .xslt as a
"text/xml" file. Or rename your file with an extension that the OS does already
recognize such as .xsl or .xml. Or upload the file to a webserver and configure
that so that mozilla gets a proper mimetype.

There is no real bug here since you shouldn't rely on mimetype guessing. However
we could certainly do better guessing. We could either make the loop in
nsUnknownDecoder::DetermineContentType BOM and encoding aware, or we could add
more entries in the nsUnknownDecoder::sSnifferEntries table for various
combinations.
bz: do you have an oppinion on modifying the unknown-decoder as above?
It could be done, I guess.... it just didn't seem worth the time when I was
hacking on that code.  The HTML branch would be pretty hard to make work with
BOMs.  The XML branch is a little better, but still rather annoying (see the big
if/else cascade in GetCharsetFromData() in nsCSSLoader.cpp for the sort of code
it would need; if this is done, I'd like to share that code somehow in a
slightly more generic function....).  Supporting just UTF8 with BOM would be
easy, as you noted -- just an entry in sSnifferEntries.
One question is, are we interested in supporting charsets (BOMs and charsizes
bigger then 1) for anything other then xml in nsUnknownDecoder? I.e. can
text/plain or application/postscript be downloaded in any exotic encodings?

If so I would say it's worth to teach the unknowndecoder about BOMs and the likes.
Postscript is ascii-ish by definition.

text/plain could happen in a non-ascii-compatible encoding, yes.  Perhaps it
would be worth checking for a BOM up front, grabbing just the relevant chars
from our buffer to a new buffer (a la the CSSLoader code, essentially skipping
the nulls), then calling the existing sniffer on the culled data?  It'd break
for something like UTF-7, but....
Yeah, something like that is what i had in mind too. Maybe if we had a function
like:

GetAsciiData(char* aData, PRUint32 aLength, nsCString& aReturn)

that tried to create an ascii string by looking for BOMs and nulls, we could use
that both from the cssloader and the unknowndecoder. It could also have
outparams for steplength and such that the cssloader needs.
The CSSLoader would not need the steplength if the function just returned an
"ascii-fied" representation, I don't think.
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: