Closed mjslee closed 13 years ago
If we end up not supporting Windows Safari, we need to uncomment initialize.js:103 so that it will be added to the unsupported browser/os list.
I'll try to diagnose this today after my Windows 7 install finishes updating. I've waited 2.5 hours now...
Wow. that's a very long time!
I can't reproduce this on a fresh install of Safari 5. It successfully loads. I've heard that the
I do not have quicktime installed, so that is probably the culprit. How shall we handle this situation?
According to stackoverflow, this javascript code can detect if quicktime is installed: var QtPlugin = navigator.plugins["Quicktime"]; if (QtPlugin) {//QuickTime is installed}
If it quicktime isn't installed and they are using Safari, should we politely tell them to install it or use another browser to continue?
This seems like a good solution. Can you add it as part of your browser check in initialize.js?
Yes, I'll take this ticket over. Sorry about all the issues that turned out not to be bugs! :(
I'm going to install Linux on Parallels since it's a good idea to test to make sure everything works on a fresh install (of browsers).
I tried several quicktime detectors in Javascript (including the one referenced above) and found that there was no consistency across browsers. Most of the scripts have a dependency on Netscape plugin architecture or MSIE ActiveX architecture to work correctly, which the WebKit and Safari browsers don't support.
Since the number of Windows Safari users will be slim, I'm currently taking it off the whitelist until a better, more consistent script that doesn't mess up Gidget is working and tested.
We discussed this briefly and thought one solution would be implementing a time-out for loading. However, this might mean that they won't see the intro, or play the game without any sounds.
Observations: