Closed
Bug 322461
Opened 19 years ago
Closed 19 years ago
[FIX]FF 1.5 doesn't apply CSS stylesheets in document after XSLT transformation
Categories
(Core :: XSLT, defect, P1)
Core
XSLT
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: p.franc, Assigned: bzbarsky)
References
Details
(4 keywords, Whiteboard: [rft-dl])
Attachments
(4 files)
633 bytes,
application/xml
|
Details | |
382 bytes,
text/html
|
Details | |
2.91 KB,
patch
|
jst
:
review+
jst
:
superreview+
dveditz
:
approval1.8.0.1-
dveditz
:
approval1.8.1+
|
Details | Diff | Splinter Review |
2.95 KB,
patch
|
dveditz
:
approval1.8.0.2+
|
Details | Diff | Splinter Review |
FF 1.5 doesn't apply CSS rules with selector in uppercase in document after XSLT transformation with the output set to html.
Reporter | ||
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
For reference, this is the output of the transform, as html.
Comment 3•19 years ago
|
||
As result of the testcase of comment #1 the culprit must be in this list: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-18+08%3A00%3A00&maxdate=2005-04-19+06%3A00%3A00&cvsroot=%2Fcvsroot
Comment 4•19 years ago
|
||
Ria, could you explain that with a bit more detail? Did you test nightlies between 1.7 and 1.8?
Comment 5•19 years ago
|
||
Yes, that's what she did. From that regression range, I would think this could be a regression from bug 290068.
Keywords: regression,
testcase
Comment 6•19 years ago
|
||
Seems like we're setting case sensitivity eagerly, too.
Assignee | ||
Comment 7•19 years ago
|
||
So we call SetCaseSensitive() in the nsDocument Init() (and at this point we're assuming case-sensitive). Then we reset it once we know whether we're HTML or XHTML, which is in nsHTMLDocument::StartDocumentLoad(). Of course XSLT doesn't call StartDocumentLoad(), right? So how does XSLT actually create the document? How is the document supposed to know it's an HTML document and not an XHTML one?
Assignee | ||
Comment 8•19 years ago
|
||
OK, I see what's up. The document is created via createInstance, which never initializes the mDefaultNamespaceID member of HTMLDocument. That means the zeroing allocator sets it to 0, which happens to be kNamespaceID_None. We should probably fix this part. But anyway, it looks like creating by contract id gives us an HTML document, not an XHTML one. So we should probably override Init() in nsHTMLDocument to call the superclass Init() and then reset the case-sensitivity as needed...
Assignee | ||
Comment 9•19 years ago
|
||
Assignee: xslt → bzbarsky
Status: NEW → ASSIGNED
Attachment #207628 -
Flags: superreview?(jst)
Attachment #207628 -
Flags: review?(jst)
Assignee | ||
Updated•19 years ago
|
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Summary: FF 1.5 doesn't apply CSS stylesheets in document after XSLT transformation → [FIX]FF 1.5 doesn't apply CSS stylesheets in document after XSLT transformation
Target Milestone: --- → mozilla1.9alpha
Version: 1.8 Branch → Trunk
Why bother setting mDefaultNamespace to kNameSpaceID_None (== 0)? This is a pretty bad regression (one that we should test for when we get automated tests), would be good to get this on the branches.
Assignee | ||
Comment 11•19 years ago
|
||
> Why bother setting mDefaultNamespace to kNameSpaceID_None (== 0)?
Because I think depending on kNameSpaceID_None == 0 is a bad idea.
Good point
Comment 13•19 years ago
|
||
Comment on attachment 207628 [details] [diff] [review] Fix r+sr=jst
Attachment #207628 -
Flags: superreview?(jst)
Attachment #207628 -
Flags: superreview+
Attachment #207628 -
Flags: review?(jst)
Attachment #207628 -
Flags: review+
Assignee | ||
Comment 14•19 years ago
|
||
Comment on attachment 207628 [details] [diff] [review] Fix This is probably serious enough a regression to be worth considering for 1.8.0.x. I definitely think we should take this for 1.8.1. The patch is very very safe. Only cases where the document is not actually being loaded (like XSLT) are affected.
Attachment #207628 -
Flags: approval1.8.1?
Attachment #207628 -
Flags: approval1.8.0.1?
how will this affect things like document.implementation.createDocument? I guess not very much since such documents are never styled?
Assignee | ||
Comment 16•19 years ago
|
||
Fixed on trunk. Sicking, createDocument creates the same thing after this patch as it always did. But yes, those documents are never styled, at the moment.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 17•19 years ago
|
||
createDocument only creates XML documents anyway.
Comment 18•19 years ago
|
||
Comment on attachment 207628 [details] [diff] [review] Fix This has come in too late for 1.8.0.1 (no trunk-baking time) but we'll consider for 1.8.0.2
Attachment #207628 -
Flags: approval1.8.1?
Attachment #207628 -
Flags: approval1.8.1+
Attachment #207628 -
Flags: approval1.8.0.2?
Attachment #207628 -
Flags: approval1.8.0.1?
Attachment #207628 -
Flags: approval1.8.0.1-
Assignee | ||
Comment 19•19 years ago
|
||
Updated•19 years ago
|
Target Milestone: mozilla1.9alpha → mozilla1.8.1
Updated•18 years ago
|
Flags: blocking1.8.0.2+
Updated•18 years ago
|
Attachment #207628 -
Flags: approval1.8.0.2?
Comment 21•18 years ago
|
||
Comment on attachment 208126 [details] [diff] [review] Patch merged to 1.8.x branch approved for 1.8.0 branch, a=dveditz
Attachment #208126 -
Flags: approval1.8.0.2+
Comment 23•18 years ago
|
||
Marking [rft-dl] (ready for testing in Firefox 1.5.0.2 release candidates)
Whiteboard: [rft-dl]
Comment 24•18 years ago
|
||
v.fixed on 1.8.0 branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2, I see green.
Keywords: fixed1.8.0.2 → verified1.8.0.2
*** Bug 315380 has been marked as a duplicate of this bug. ***
*** Bug 327902 has been marked as a duplicate of this bug. ***
*** Bug 340980 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•18 years ago
|
Target Milestone: mozilla1.8.1 → mozilla1.9alpha
You need to log in
before you can comment on or make changes to this bug.
Description
•