250940 - nodes from transformToFragment inserted into document are FUBAR regarding CSS

Status: RESOLVED WORKSFORME

(Core :: XSLT, defect)

Description

[Dave Mason]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

In the page that gets generated through a combinations of xlst and javascript,
CSS annotations based on the class of DOM objects don't consistently get noticed.

Reproducible: Always
Steps to Reproduce:
The URL is a directory where you can see most of the relevant files.

1. Open courses.html
2. Click on the link
3. Click on the line in the top left of the left frame.
4. Open the DOM Inspector.

Actual Results:  
a line with no mark in front
1 line with a fuzzy ball in front
2 lines with arrows in front
1 line with a fuzzy ball in front

Expected Results:  
The lines with the fuzzy balls in front should instead have arrows... which will
appear if you click the line with the first fuzzy ball.  The DOM Inspector will
show that the class of the LI elements were closed, but the display is still as
if they were loading.  (See contents.css in the original directory.)

It appears that this is because one of the files was not loaded (because of an
XML syntax error).  It's the second line with an arrow.  I did have an error in
both of the lines that currently show an arrow... then all the lines had fuzzy
balls in front of them.

When you click on the fuzzy ball, it correcly opens the directory, but all the
lines in the directory should have nothing in front of them (they're class page,
as the Inspector will show), but instead have an open arrow.

transformToFragment also makes attributes that behave somewhat strangely. 
Sometimes the deprecated foo.bar syntax works, and sometimes
foo.getAttribute("bar") is required, but it is highly variable.  I mention this
because it suggests that xslt, javascript and Gecko aren't all on the same page
regarding attributes.

I've marked it as major because it makes transformToFragment difficult to use in
any at-all-sophisticated way, although it isn't a major Mozilla feature (yet).

Comment 1

[Dave Mason]

The main point is valid, but the point about the class="page" incorrectly having
an arrow may not be a bug... or at least it happens with a static page and the
same .css file.  That's what the file contents2.html is.  I'm exploring it further.

Argh!  Sorry.  I had it working before with static pages, and I didn't realize
that I'd done something to break it.

Comment 2

[Dave Mason]

Sure enough, the second part of my problem was a pure CSS problem.  I had to add
a list-style-image declaration, because a list-style-type:none wasn't enough.  I
definitely didn't need this in an earlier version, but it's fine.

li.page {
  list-style-type: none;
  list-style-image: none;
}

Sorry I didn't catch this before I posted the bug.

Rest of bug remains.

Comment 3

[Axel Hecht]

I can't reproduce anything that is mentioned in the bug report.

Please supply a single file (or at least few files) testcase with static content, 
so we can at least check the source of the transformation.

And file a bug per issue. Fix issues a, b, c on page foo is nothing we can do.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

And try to see if this has something to do with XSLT (which would be really
surpricing, a fragment is a fragment, weather created by XSLT or DOM). Try
creating the same fragment through normal DOM and see if the bug remains.

Comment 5

[Dave Mason]

The bug that remains is that if asynchronous file loads fail, CSS may not get
updated properly.

Unfortunately, I am headed on vacation today for a month, and probably will not
have a good opportunity to create a static (or at least much simpler) example
any time soon.

If you can't duplicate it, I suggest you resolve it as worksforme and I'll try
to produce a simpler failure file later.

Comment 6

[Dave Mason]

I just updated my files so that all the files load correctly and the images are
(randomly) messed up, still, so I think there is a real bug still.  I can't tell
if it's an interaction between Javascript and Gecko/CSS or between XSLT and
Gecko/CSS, but it only seems to apply to dynamically created nodes.  My static
file displays fine.

I will put all the files and directories inside the original directory so you
can see everything in one place.  The courses.html file will have links to good
and broken courses.

Comment 7

[Dave Mason]

The directory is all there... and everything works... from the web site!

From a local disk, however, it's randomly broken.

I have put a gzipped tar file of the directory there, so you can test it.

Remember the file to open is courses.html

Weird behaviour!

Comment 8

[Gervase Markham [:gerv]]

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/

Comment 9

[Boris Zbarsky [:bzbarsky]]

If it's only a problem from local disk, sounds like this might be caused by bug
282432

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Dave, does your testcase refer to any non-existing files?

Comment 11

[Peter Magyari (Desktop QA)]

Since this is a very old report and I cannot reproduce it myself, I'm going to close it.
If the issue still occurs, feel free to re-open it.

Thanks!