323612 - XSLT transformation in javascript returns empty XMLDoc with hash(#) in location

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[ibjoel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

An xslt transformation in javascript will not return the expected XMLDocument but rather an empty one, if the page which contains the javascript has a location with a hash in it.

Reproducible: Always

Steps to Reproduce:
1. Write an xslt file and an xml file to be transformed by it.
2. Write javascript to transform the xml file with the xslt file.
3. Load the page and see it work.
4. Then add a hash value to the location (e.g.#test), refresh, and see it not work.

Actual Results:  
returned empty XMLDocument Object

Expected Results:  
the correct XMLDocument Object

The page must be loaded with the hash in the location. The transformation will work if the hash is added to the location (manually or dynamically) after the page has been loaded.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060115 Firefox/1.6a1 ID:2006011522

This seems to work in trunk but not in the build you're using.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Fixed on 16-Dec-2005.
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-12-16+13%3A00%3A00&maxdate=2005-12-16+22%3A00%3A00&cvsroot=%2Fcvsroot

Comment 3

[ibjoel]

(In reply to comment #2)
> Fixed on 16-Dec-2005.
> 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-12-16+13%3A00%3A00&maxdate=2005-12-16+22%3A00%3A00&cvsroot=%2Fcvsroot
> 

This does not work correctly in the newest build 
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060115 Firefox/1.6a1)

Unfortunately my example was too simplified to show it.  It appears now instead of returning an empty XMLDocument Object, the transformation returns a XMLDoc containing all text nodes of the xml document being transformed.  I'm including a new link to show that an issue still remains.

http://testing.tryiton-line.com/bugs/test2.php

ps. sorry for not submitting this bug with the latest build 

Comment 4

[Ria Klaassen (not reading all bugmail)]

In that case I misunderstood the testcase :)

Comment 5

[Brad Neuberg]

This bug is hitting my project as well and is real.

Comment 6

[Brad Neuberg]

This is actually a serious bug. Think about it; if there is ANY anchor in the location bar, and you programmatically use XSLT, then you get no HTML results! This seems to rule out using client-side XSLT and JavaScript on the Mozilla platform.

It also potentially points to other strange bugs; why should the location bar affect an XSLT transform? These components should be decoupled, and the fact that they are not points to badly written code that might be the source of other strange bugs.

I vote that this bug should end up on someone's radar.

Comment 7

[Brad Neuberg]

I have found a workaround and a simplification of this bug! Here is the code below for the simplification, with comments; feel free to use this code below. I have also incorporated this into Sarissa (http://sarissa.sourceforge.net/doc/) and submitted a patch to the Sarissa author:

/**
  Mozilla has a serious bug related to transforming an XSLT document if the 
  brower's window location has a # in it. What occurs is if the browser 
  location has a # in it, and we transform a document, we get a blank HTML
  document instead of the correct results! This bug is Mozilla bug 323612
  and is documented at https://bugzilla.mozilla.org/show_bug.cgi?id=323612.
  
  I simplified the bug and found a workaround. The bug is actually
  related to when you create an XML DOM representation of an XSLT stylesheet,
  then pass this to an XSLTProcessor's transformToDocument method.
  
  The workaround basicly involves 'tricking' the XSLTProcessor into
  'seeing' a different window.location.href than the 
  containing document; this can be done using
  a hidden iframe, which we do. For example, if our browser's location
  is http://hyperscope.org/arch.opml#6:x, while our iframe's
  location is about:blank, then the XSLTProcessor is 'tricked' into
  seeing it's location as about:blank and everything works fine.
				  
  Once you have an iframe, you need to get it to 'execute' our code.
  There are three ways to do this:
  1) Have an external .html file that is loaded that executes the code
  we want.
  2) Do a document.write into this iframe with the code to execute
  3) Using a javascript: url
  
  We don't want to use 1, since this will get bulky and slow and have
  to be distributed with applications, while 2 doesn't work since
  a document.write resets a document's location to be the same as the
  document that is doing the writing (in our case keeping the hash). Only
  3 will work, which is a bookmarklet. The great thing about using
  a bookmarklet in the way we do as well is that all the code is now
  synchronous, and we can 'hide' this behind a traditional 
  DOMParser.parseFromString method, which is synchronous.
				  
  Let's take a look at the bookmarklet:
  
  doc.location.href = 
		'javascript:(function(){'
		+ ' document.__xmlDoc__ = new DOMParser().parseFromString(document.__xmlDoc__, "text/xml"); '	
		+ '})()';
		
  This line basicly parses a string representation of the XML document, which we 
  saved into 'document.__xmlDoc__' before calling this, and then resaves the
  XML DOM back into 'document.__xmlDoc__' for later retrieval.
  
  This solve's the problem, and we can now instantiate an XSLTProcessor 
  without running into the bug.
 */

// if we are dealing with Gecko.... (fill this in using your own browser detection routine to detect Gecko-based browsers)

	DOMParser.prototype.__parseFromString = DOMParser.prototype.parseFromString;
	DOMParser.prototype.parseFromString = function(xmlDoc, contentType){
		// create our hidden iframe
		var iframe = document.createElement("iframe");
		iframe.setAttribute("src", "about:blank");
		iframe.style.position = "absolute";
		iframe.style.top = "-1000px";
		iframe.style.left = "-1000px";
			
		// get the document body; some XHTML doctypes don't have
		// a document.body
		var body = document.body;
		if(body == null || typeof body == "undefined"){
			body = document.getElementsByTagName("body")[0];
		}
		if(body == null || typeof body == "undefined"){
			var msg = "Programming error: You must wait for the page "
						+ "to fully load before using DOMParser.parseFromString "
						+ "to fix Mozilla bug 323612; set an onload handler.";
			throw msg;
		}
		body.appendChild(iframe);
			
		// get it's document object
		var doc = iframe.contentDocument;
		
		// save a reference to our string XML representation
		doc.__xmlDoc__ = xmlDoc;
		
		// execute our offending code
		doc.location.href = 
				'javascript:(function(){'
				+ ' document.__xmlDoc__ = new DOMParser().parseFromString(document.__xmlDoc, "text/xml"); '	
				+ '})()';
			
		// get the results
		xmlDoc = doc.__xmlDoc;
		
		// clean up the iframe
		iframe.parentNode.removeChild(iframe);
			
		return xmlDoc;
	};
};

Comment 8

[Sjoerd Mulder]

This bug is a duplicate of bug 212362

Comment 9

[Tyler Downer [He/Him]]

This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode

Comment 10

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.