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

Status: NEW

(Core :: XSLT, defect)

Description

[Kris Maglione [:kmag]]

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

Comment 1

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

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?

Comment 2

[Kris Maglione [:kmag]]

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.

Comment 3

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

Even though you can't provide a testcase which fails every time, can you provide a testcase which does fail sometimes?

Comment 4

[Kris Maglione [:kmag]]

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.

Comment 5

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

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.

Comment 6

[Kris Maglione [:kmag]]

Attachment: Testcase

Comment 7

[Kris Maglione [:kmag]]

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.