The following test pages are to test browser functionality as it relates to features used by the Insurrection Web Tools for Subversion.  Where ever possible, the tests have been broken out into individual situations such that the core issues can be identified.  The tests require at least and HTML 4.0 browser in order to view the reference samples as they are presented in HTML.

The reference pages are rendered using plain HTML plus style sheets.  The test pages should render just like the reference pages.  The links below will load the two pages within frames in your browser such that you can see the test page and reference page at the same time using frames.

Just because your browser fails one or more of these tests does not mean it will fail to work with Insurrection.  Insurrection code has some browser specific workarounds in it for XSLT failures in certain browsers as noted below.  These tests do not show the use of the workarounds in order to show the raw browser failures.

Test	Description
Test #1	Basic Browser based XML Request loading. Mozilla - tested and working. Windows-IE - tested and working.  Note that Windows-IE currently uses a built-in ActiveX control to load the fragment and may complain about scripting of the control, depending on your security settings. Safari - tested and working. Opera - tested and working.
Test #2	Basic Browser based XSLT transform. Mozilla - tested and working. Windows-IE - tested and working. Safari - tested and almost working.  Some CSS styles are not correctly applied and the relative links in the banner go to the wrong location.  Note: it is the lack of correct path behavior that causes this problem.  It seems that the base path is not that of the document/frame but of the containing document but only when the page is created via the XSLT translation. Opera - tested and working.
Test #3	Browser based XSLT with XPath/document() function usage.  Note: Insurrection no longer depends on the XPath/document() function due to the lack of support within Safari. Mozilla - tested and working. Windows-IE - tested and working. Safari - tested and mostly not working.  The XSLT/XPath document() function seems to be at fault. Opera - tested and not working at all.  The XSLT/XPath document() function seems to be at fault.
Test #4	JavaScript based XML loading, parsing, and DOM creation. Mozilla - tested and working. Windows-IE - tested and working.  Note that Windows-IE currently uses a built-in ActiveX control to load the XML and may complain about scripting of the control, depending on your security settings. Safari - tested and working. Opera - tested and mostly working.  There are some strange layout problems as part of the clicking of the links but they are consistent between the test page and the reference page.
Test #5	XSLT based pages with JavaScript called within the generated page. Mozilla - tested and working. Windows-IE - tested and working.  Note that Windows-IE currently uses a built-in ActiveX control to load the XML and may complain about scripting of the control, depending on your security settings. Safari - tested and mostly not working.  For the same reason that the styles don't render correctly in Test #2, the JavaScript is not executed.  It is interesting in that the page should look just like the page in Test #1 only this page is generated from XML via client side XSLT and this causes the URL reference problems and JavaScript execution problems.  Note: it is the lack of correct path behavior that causes some of these problems.  It seems that the base path is not that of the document/frame but of the containing document but only when the page is created via the XSLT translation. Opera - tested and not working.  It seems that XML/XSLT support within Opera does not support the running of JavaScript.
Test #6	Basic Browser based XSLT transform with HTML output format. Mozilla - tested and working in newer (1.8+/Firefox 1.5+) versions.  Test #2 shows this exact same test setup with the CSS formatted in a way such that rendering works.  Certain prior version failed for a period of time but Mozilla 1.7.x and Firefox 1.0.x did work. Windows-IE - tested and working. Safari - tested and almost working.  Some CSS styles are not correctly applied and the relative links in the banner go to the wrong location.  Note: it is the lack of correct path behavior that causes this problem.  It seems that the base path is not that of the document/frame but of the containing document but only when the page is created via the XSLT translation. Opera - tested and working.  There seems to be a minor behavior/layout difference due to the behavior of the XSLT generated page but it basically works.

Notes on the browsers I have tested:

• Mozilla includes all Mozilla technology based browsers including Firefox, Camino, etc. Mozilla 1.8+ and Firefox 1.5+ currently fail test #6 but the workaround so trivial that it does not matter.
• Windows-IE is IE6.  This is the default browser that came with Windows XP.  My Testing was done on Windows XP with Service Pack 2 installed.
• Safari is Mac OSX 10.3.9 release and 10.4 release.  Safari with Webkit 420+ is now working.
• Opera is the Linux generic build of 9.0 Final.  Note that prior Opera versions did not have any client-side XSLT support and thus failed all of the XSLT tests.  Opera still has some strange layout issues.

What this means is that Mozilla/Firefox/etc, upcoming Safari versions, and Windows-IE comply with the standards enough to use the Insurrection tools without some help.  This does, however, cover over 98% of the browsers in use.  Insurrection has some browser compatibility checks that check for Konqueror, Safari, and Opera. These checks then remove the client side XSLT processing and move it to server-side XSLT processing.  This is not the preferred solution as it significantly increases the amount of data that needs to be sent to the client.  Insurrection specifically checks for only those browsers (via the USER_AGENT header) in order to enable the workaround so as to not reduce the performance of browsers that do support the standards.