{ib}CSS style sheet not working if XML is translated via XSL to XML-with-a-CSS-style-sheet

VERIFIED FIXED

Status

()

Core
XSLT
--
major
VERIFIED FIXED
16 years ago
3 years ago

People

(Reporter: Brian Downing, Assigned: sicking)

Tracking

Trunk
x86
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20021223

XML translated to XML with a CSS stylesheet processing tag does not appear to
run the CSS stylesheet correctly.  No visible output is generated if there is a
CSS stylesheet that styles the tags output by the XSL stylesheet.  If the CSS
file is missing or empty, you get unstyled output.  If the XSL processing is
done ahead of time and the postprocessed XML loaded into Mozilla, the CSS
styling works as expected.

Both files appear to have identical DOM trees.

I do not believe this is a dup of the stylesheet caching bugs (155715, etc.) as
a browser restart does not fix anything, and changes to the files as described
above appear on reload.

I'm classifying it as Major only because I don't know of another way to both
translate and style XML without resorting to XHTML.

Reproducible: Always

Steps to Reproduce:
1. Prepare directory with test.xml, test-processed.xml, test.xsl, and test.css
2. Load test.xml
3. Load test-processed.xml (which is test.xml with the XSLT processing already done)
4. Compare

Actual Results:  
test.xml is not rendered.  test-processed.xml is rendered fine.  Their resultant
DOM trees in the DOM inspector appear to be identical - they both have the
proper XML tags and stylesheets.

Expected Results:  
I think the results should be identical.
(Reporter)

Comment 1

16 years ago
Created attachment 110167 [details]
XML test case before XSL transformation
(Reporter)

Comment 2

16 years ago
Created attachment 110168 [details]
XML test case after XSL translation
(Reporter)

Comment 3

16 years ago
Created attachment 110169 [details]
XSL stylesheet for test case
(Reporter)

Comment 4

16 years ago
Created attachment 110170 [details]
CSS stylesheet for test case
Is this only a problem with current trunk builds, or also with 1.2.1?
(Reporter)

Comment 6

16 years ago
1.2.1 is affected as well.
OK.  Out of curiousity, does opening the "File" menu do anything to change the 
rendering in the "non-rendering" case?
(Reporter)

Comment 8

16 years ago
Just opening the file menu?  No, not in 1.2.1 or the trunk build from Dec. 23.
->XSLT
Assignee: dbaron → peterv
Component: Style System → XSLT
QA Contact: ian → keith
Strange, the stylesheet gets hooked up, but the rules in it cause everything to
get hidden. If I change the rule:

block {
  display: block;
}

to

block {
  display: inline;
}

everything works as expected.
Status: UNCONFIRMED → NEW
Ever confirmed: true
seems to be a block-in-inline problem. If I add a rule to make the root node a
block as well everything works as excepted.

so the following doesn't work if generated through XSLT:

inline          <- A
  block         <- B
    inline
      #text
    inline
      #text

but works fine if loaded directly. Whereas if the A node is changed to a block,
or if the B node is changed to a inline everything works even when loaded
through XSLT.
Hmm.. The only way an inline root node can work is if all the content gets 
frames constructed at once.  If the root node's frame is constructed and then 
we get some ContentInserted/ContentAppended calls, we will flub the frame 
construction.

I bet that's the difference between just loading the document (constructs the 
DOM and then kicks off frame construction) and building it via XSLT (builds DOM 
incrementally with notifications along the way??)
Summary: CSS style sheet not working if XML is translated via XSL to XML-with-a-CSS-style-sheet → {ib}CSS style sheet not working if XML is translated via XSL to XML-with-a-CSS-style-sheet
there should be no ContentInserted/ContentAppended calls after layout is
started. However the linked stylesheet won't be loaded until after the initial
reflow so that's probably what causes this to fail. 
Same thing; a reframe due to a display change is implemented via a pair of 
calls to 
nsCSSFrameConstructor::ContentRemoved/nsCSSFrameConstructor::ContentInserted.
Depends on: 168883
Created attachment 110250 [details] [diff] [review]
block layout until all stylesheets are loaded

This holds off the notification that ends up starting layout until all linked
stylesheets in the result document are loaded. This should take care of all
cases where the stylesystem or layout doesn't fully deal with the incremental
changes of stylesheets comming in after the initial reflow.

The patch uses the existing mechanism in the nsCSSLoader that notifies an
observer when a stylesheet is fully loaded (including child-sheets). To do this
i've added a parameter to nsIStyleSheetLinkingElement::UpdateStylesheet that
lets you specify an observer to be notified when the stylesheet for the element
is done loading.


As a sidenote, the contentsinks should be using this same mechanism to unblock
the parser. I've filed bug 186943 on this.
I removed the comment in txMozillaXMLOutput::startHTMLElement about "XXX Trick
nsCSSLoader into blocking/notifying us?" since this patch does just that.
Attachment #110250 - Flags: superreview?(bzbarsky)
Attachment #110250 - Flags: review?(peterv)
Comment on attachment 110250 [details] [diff] [review]
block layout until all stylesheets are loaded

> +    // aSheet might not be in our list if the load was done syncronously

"synchronously"

sr=me otherwise, though we should remove all this code once sheets no longer
block the parser...

That said, this is all wallpaper over the {ib} issues which we need to fix for
other reasons and I'm not completely convinced we want to spend time doing this
instead of addressing that core issue...
Attachment #110250 - Flags: superreview?(bzbarsky) → superreview+
bz: Agreed. The main reason i want to do this is that we will otherwise keep
getting bugs on XSLT where "it works for normal pages but not if I use XSLT".
Attachment #110250 - Flags: review?(peterv) → review+
->me
Assignee: peterv → bugmail
Checked in fix for XSLT.

Boris: Are there a bug on the underlying inline-in-block problem, or do you want
to use this bug for that?
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Um... see the "depends on" field of this bug, eh?  ;)  That will give you (via
its dependencies) all the {ib} goodness you want.

Comment 22

16 years ago
This commit have added a "uninitialized" warning on Brad TBox:

+extensions/transformiix/source/xslt/txMozillaXMLOutput.cpp:496
+ `nsresult rv' might be used uninitialized in this function

Indeed, it appears that the (rv == NS_ERROR_HTMLPARSER_BLOCK) comparison is
quite likely to be comparing an uninitialized rv. Is one of the previous lines
missing an "rv = "?

P.S. Per bug 179819 such warnings ought to be considered compilation errors.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 110811 [details] [diff] [review]
eek!

thanks for catching this
Attachment #110250 - Attachment is obsolete: true
Comment on attachment 110811 [details] [diff] [review]
eek!

got r=glazman over irc
Attachment #110811 - Flags: review+
Comment on attachment 110811 [details] [diff] [review]
eek!

r=glazman !!!
Comment on attachment 110811 [details] [diff] [review]
eek!

sr=jst
Attachment #110811 - Flags: superreview+
warning-fixes checked in
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Updated

15 years ago
Blocks: 186943

Comment 28

15 years ago
mass verifying
Status: RESOLVED → VERIFIED

Comment 29

3 years ago
Created attachment 8635746 [details]
testcase xml+xslt online

Just to check the original testcase in browser online (without downloading).
You need to log in before you can comment on or make changes to this bug.