IE10 vs sound-plugin

While testing the krPano with the newly released Internet Explorer 10 i found out, that the sound plugin doesn't work.
I made a test scenario which can be found here:

http://goo.gl/HBQB9

Important to say is, that the problem only occurs with the html5-verison of the plugin (the one used in the metro version of IE10).
Furthermore (and this is the more annoying part of the problem) if the preload attribute of the plugin is set to true, then the metro IE wont even load the panorama.

So Klaus...heeeelp...

That is strange indeed...

After your recent post i tried to open the link again just to have a look.
I did not expect it to work tough. But...surprise surprise it did work.
Panorama was loaded, sound played (both Metro and Desktop IE10).

So i switched to my localhost to test the page there (the online/offline files
are exactly the same ones) and it did NOT work there. I remember you saying
something about security settings and testing locally in IE10. Therefor i checked
these setting only to find them already set to the lowest level (i set them to this
without resetting them the first time the described error occurred).

The next thing i did was to delete all the files on the webserver and reuploading them.
No change here, the online one was still working correctly.

Okay, since this demo page only displays a part of the problem and i usually use the
setting preload="true" for the sound plugin (this resulted in the pano not even getting
loaded at all) i made the necessary adjustments and tried it again.
-> localhost: pano is not loaded (network action stops after loading the krpano_sound.xml)
-> online: 100% working

Finally i resetted the security settings of the IE10, restared it and BOOM:
-> online not working anymore

And now, that i eventually though i found what is causing this error the really odd
part starts. I switched the security settings back to low (the ones concerning internet and local),
restarted my favorite browser again in the hopes of getting a working panorama with
sound playback from the webserver only to be very disappointed. The webpage did
not work anymore. Nothing i did since got it working again. PC reboot, IE restart (with different
settings), etc...

I have tested this now on two different Windows 8 machines.
The first one is a laptop where Windows 8 is directly installed.
This one produced the original error. At one time the sound plugin was working
there too, but back then i was researching the gyro-plugin and deemed it as cause
of all this trouble.

The second one is a virtual Windows 8 on my desktop pc (running Windows 7 as host).
This configuration was used and produced the above description.

And to top it all, now (after writing this little assay) i just hit reload on
both the online and offline demo page and:
-> localhost: 100% working
-> online: pano is not loaded (network action stops after loading the krpano_sound.xml)

WTF...???

Can some of you please test the following link and just make a quick post, whether it is working or not?
Not that i am the only one out there...
http://goo.gl/HBQB9

Since this problem is still bugging me and I'm getting a little desperate in finding a solution (or the cause if nothing else) i did some further testing.

This time I made a video capture from my desktop that shows what i found out
(better to watch than to read i guess) :
https://www.dropbox.com/s/5y59fmr5f3cvltx/krPano.avi

So...bottom line is, if the created example page gets called via the shortened url I have posted here twice now, the error does not occur. But if I open the link directly in my browser, than the krPano wont even show the panorama. It gets stuck after loading the corresponding pano xml.

Here are the two links:
shortened link
http://felix-leistner.de/krpano-1.0.8.1…pano_sound.html
EDIT: directly linking from this forum seems to make it work...so copy the above link and open it in a new tab.

If the second link still works, please try and just copy the link destination, open a new tap in IE10 and paste it there.

Well Klaus, any chance your IE10 is not showing a panorama either

While testing what the source of all the problems is, I found out, that there is a major problem, on how krPano treads the alturl attribute of plugins/hotspots/etc. It depends on the order that the attributes have within their corresponding nodes. So it is of the utmost importance, that the alturl attribute has to be declared AFTER the url attribute. So far nothing new here, it is well documented in the detail section of all alturl attributes. Sadly that is not really good practice.
Lets say for example that a certain browser (we will call it IE10 for now) chooses to ignore this order (which it has every right to do) an parses attributes in some different manner. This could lead to all plugins depending on the alturl source to malfunction.

To test my theory i made a simple console log for attributes of the following plugin:

<plugin name="soundinterface" url="%SWFPATH%/soundinterface.swf" alturl="%SWFPATH%/soundinterface.js" volume="0.2" mute="false" preload="false" onloaded="js(...)"/>

Chrome says:

name
url
alturl
volume
mute
preload
onloaded

IE9 says:

name 
url 
alturl 
volume 
mute 
preload 
onloaded

and finally the IE10 prints the following:

preload
mute
volume
alturl <- omg...declared before url...
url
name
onloaded

So here it is...a complete example the leads to my plugins not working in IE10 (html5) because the order of xml-node attributes gets parsed a little different and krPano therefor stops working correctly.

I hope that this gets fixed real soon.

Unfortunately for both of us (and all other web-developers) Microsoft's Internet Explorer makes it a habit of just screwing around when it comes to such "standards".
But to not lash out against the IE family now, i want to state, that this behavior is according to the w3.org:
http://www.w3.org/TR/REC-xml/#sec-starttags
Their one can read:
"Note that the order of attribute specifications in a start-tag or empty-element tag is not significant."

It would be nice to have an update available some time soon, but until then i will program my own workaround.
I also ditched the whole preloading="true"-setting, because i was not able to further pinpoint the problem. Maybe it has something to do with the attribute order, too...?! I don't really know...let's see what happens after the next update.

Thanks again