1

Extensive research did not lead me to understanding why the below happens - I hope that the SO community can help...

I copied the files mentioned in Why HTML1113: Document mode restart from IE9 Standards to Quirks to local filesystem and opened the xml in IE9 (by specifying the path D:\... in the url bar).
Surprisingly, the behavior is quite different from opening the web version.
Now I can understand that "My Computer" zone settings differing from Internet zone ones explain the pop-up windows mentioned below, but I don't understand why the result is different and why quirks mode is not automatically chosen, just like was done when opening the xml on the web.

When I open the local file, I get the following:

AllowScripts

which no doubt is caused by a local zone setting. Next, the browser mode is IE9 (not auto quirks as earlier) and it fails on applying the XSLT:

XSLT8690

First I thought that this was caused by MSXML6 DOM basic settings like AllowXsltScript not being set to true, but I am not sure about that any more, because it all works OK when opening the web version.
So why does the local one fail?

Stranger still, opening the web version led to auto quirks mode and correct result, but when I switch to quirks mode for the local file, it fails on the MSXML6 DOM object - actually this makes more sense to me than no error, because quirks mode probably only offers MSXML3 (or should only offer that - but then why was auto quirks in web version OK?).

Quirks1

After accepting, it changes to

Quirks2

Now, when selecting IE9 standards mode again, I get

IE9take2_console

and the result is the expected

IE9take2

Reciting events when using local files (apart from zone setting differences):

  1. IE9 standards mode XSLT8690 error
  2. Switching to quirks mode errors
  3. Switching back to IE9 standards mode is OK now

Reciting the events when opening the web version (apart from differences due to zone settings):

  1. quirks mode automatically
  2. page opens correctly in quirks - apparently MSXML6 is still used here in the auto quirks mode
  3. switch to IE9 standards mode is OK too
  4. Back to quirks mode errors as above ("The parameter is incorrect'")

What is causing all these peculiar differences?

Community
  • 1
  • 1
Maestro13
  • 3,656
  • 8
  • 42
  • 72
  • The xsl:output element needs to be corrected to specify [UTF-8](http://www.dpawson.co.uk/xsl/sect1/N422.html) and the [standards mode HTML5 doctype](http://stackoverflow.com/questions/3387127/set-html5-doctype-with-xslt/8751243#8751243). – Paul Sweatte May 10 '12 at 19:10
  • 1
    The XHTML or HTML4 doctype reference generated by a local XSLT from IE is [blocked by w3](http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/), so using an HTML5 doctype without URI references is mandatory. – Paul Sweatte May 10 '12 at 19:33
  • Microsoft has support notes for [MSXML4](http://support.microsoft.com/kb/973688) and [MSXML6](http://support.microsoft.com/kb/973687) that may help. – Paul Sweatte May 10 '12 at 19:45
  • @PaulSweatte thanks for the links but I don't see anything there that explains why web version acts so different from local version (quirks / no quirks auto for starters - and where does the XSLT fail come from locally?). I may be missing something - in that case, could you be more specific? Your first comment may come in handy later, but I first wish to understand why differences occur as the files are now. This must have something to do with how IE9 handles things, I suppose. – Maestro13 May 10 '12 at 23:00
  • It is not safe to compile and execute an untrusted style sheet within a trusted page (such as a page from your local hard drive). The style sheet may contain the document() function or xsl:include / xsl:import statements, which are capable of loading trusted files and sending them back to the untrusted domain. [XSLT Security](http://msdn.microsoft.com/en-us/library/windows/desktop/ms763800) in IE9 as well as Webkit browsers limits local stylesheet processing to [inline XSLT](http://stackoverflow.com/questions/1868699/xslt-document-usage-with-webkit-browsers/9322185#9322185). – Paul Sweatte May 11 '12 at 01:43
  • If AllowXsltScript property has to be set to true, then how can I do that? It is not sufficient to do that for the dom used in the script - it will probably have toi be done for the dom loading the xslt - but where? By the way I don't think that this is the issue, because the xml is processed correctly after refreshing after going into quirks mode. – Maestro13 May 11 '12 at 11:04
  • Quirks mode [emulates IE5.5](http://www.quirksmode.org/iecompat/), which doesn't have the security restrictions of IE9 standards mode, so that's a false positive. – Paul Sweatte May 11 '12 at 15:10
  • AllowXSLTScript will only allow the msxsl:script, but will not affect the local stylesheet permissions. Either both files have to be in the [trusted zone](http://msdn.microsoft.com/en-us/library/windows/desktop/ms762300), or the 'Access data sources across domains' flag needs to be enabled. – Paul Sweatte May 11 '12 at 15:30
  • @PaulSweatte I found the answer to my question myself: see below. – Maestro13 May 12 '12 at 21:38

1 Answers1

3

This one took me some time but I've got it!

Paul Sweatte's comments led me to a lot of already charted but also to some uncharted waters, but eventually I started experimenting with IE9 My Computer zone security settings directly via the registry, alas to no avail, until.....I looked at the Internet Options popup window again and noticed that there's more than one place where security settings may be updated .....

Walking through all none-zone related IE9 settings, I selected the "Advanced" tab and encountered a promising unchecked one in the security subsection:

Allow active content to run in files on My computer

Changing it (in this case to checked) requires a restart but when I did and reopened my local xml file, it suddenly behaved as the web one did: it opened in quirks mode correctly. Also, switching to IE9 standards mode and back to quirks mode gave the same behaviour as for the web one. Also the popup warning about "scripts usually being safe" was not there anymore.

So that explains why the XSLT8690 error occurs: xslt, or maybe just javascript in there is considered to be active content.

End of story?
For this question yes, but I still wonder why auto quirks mode is OK but manually selected quirks is not.
I suspect that at the first run the xslt is processed before the auto switch to quirks takes place, and at that time the MSXML6 is not needed anymore because the result page is already available. But when you open the xml in quirks mode, then it tries to execute the xslt in quirks mode, and can't because of the available MSXML3 instead of MSXML6.

Maestro13
  • 3,656
  • 8
  • 42
  • 72