bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

XSLT documents sporadically fail to render (after transforming correctly) until browser restart

NEW
Unassigned

Status

()

Core
XSLT
8 years ago
5 years ago

People

(Reporter: kmag, Unassigned)

Tracking

unspecified
x86_64
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101022 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101022 Firefox/4.0b8pre                     

This bug happens sporadically, and I haven't been able to find any conditions that affect the frequency of occurrence, but it happens often enough that I've seen it many times and several of my users have complained. The problem occurs just after an XSL transformed XHTML document is opened. When the page loads, some of the page's text content appears briefly, followed by an empty viewport. From then on, any XSLT page opened in the browser is transformed properly (its DOM tree is correctly shown in the DOM inspector, and is accessible from JavaScript as usual), but nothing is rendered.

I can't provide a testcase because I don't have any reliable method of reproducing the problem. The stylesheet in use when I've come across the problem can be found here:

http://code.google.com/p/dactyl/source/browse/common/content/help.xsl

Reproducible: Sometimes
Could this be because we don't execute <script>s in the correct order? There is a known bug on this.

Otherwise it'd be great to get a minimized testcase.

Also, does this happen in Firefox 3.6?
(Reporter)

Comment 2

8 years ago
I'm sorry I've been so long in responding, but this bug is difficult to duplicate on demand so it's been difficult to find more information.

It happens on documents with or without script tags, so that's not relevant. It does happen in 3.6 and before, I believe. It's difficult to create a minimized testcase. It appears to happen with any XSLT document, and when it happens once, it affects every XSLT document, but beyond that it's hard to say what triggers it.

I do have more information, though.

1) Once the problem occurs, it doesn't affect documents loaded in background tabs.
2) Navigating to a new XSL transformed document leaves the contents of the previously displayed document intact, scrollable, and otherwise completely functional, but inaccessible to the likes of Firebug and the DOM inspector. Context menus also do not open. The DOM tree of window.content is the DOM of the XSL document which is not displayed. Reloading the page results in a blank viewport.
Even though you can't provide a testcase which fails every time, can you provide a testcase which does fail sometimes?
(Reporter)

Comment 4

8 years ago
I'm not sure that I can. The above stylesheet will cause a failure when processing a document such as http://code.google.com/p/dactyl/source/browse/pentadactyl/locale/en-US/intro.xml but I suspect that any stylesheet might do it. The problem is that it happens seldom enough that I don't really have any means to narrow down the cause, and as the above is the only XSL stylesheet that I or any of my users use with any regularity, it's hard to say.
Well, feel free to attach the linked to stylesheet along with the xml you just mentioned :)

Point is that it's much easier to work with this if the attachments are in bugzilla (so they are still there in 5 years), and by clicking a single link in bugzilla without having to download and edit attachments.
(Reporter)

Comment 6

8 years ago
Created attachment 494813 [details]
Testcase
(Reporter)

Comment 7

8 years ago
This appears to be related to bug 591425. Although it definitely happens with or without Panorama, opening Panorama appears to be a sure way to trigger it.

Updated

8 years ago
blocking2.0: ? → -
status2.0: --- → wanted
(Reporter)

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.