The "Inline MP3 Player Example" seems to have broken in Firefox 13.
I have the code working fine here http://alan-ng.net/irish/westwind/ but only when running on:
* Chrome on Mac OS 10.6
* Safari in iOS 5.1.1
* Safari on Mac OS 10.6
* IE 8.0 on Windows 7
But in FF 13 (on Mac OS 10.6) clicking the MP3 link just causes the browser to open a new window directly to the MP3 file. Tests in SM2 debug mode show that SM2 is not even loading far enough to instantiate itself, much less report anything in the debug div.
P.s. this is using a fresh download of soundmanagerv297a-20120527 which does not work even as-is, opened when "play-mp3-links/index.html" is opened as a local file in FF 13.
Whereas the public demo, which presumably uses an older version of SM2, does work for me in FF13:
Try removing display: none from #sm2-container on line 68 of flashblock.css. I know it creates a big ugly space on the page but, soundmanger2 doesn't seem to work in firefox without it. Thats actually why I came here when I saw your question.
I hid the big space like this:
EMPLOYEE1It's hard to debug SM2's start-up since you're using soundmanager2-nodebug-jsmin.js.To make that easier, you should use the regular, debug-enabled version during development.
Nonetheless, it looks to be a domain / redirect issue.
This will work in Firefox:
This will fail.
The crux of the problem here is that since the HTML page does not redirect to www.alan-ng.net, the host domain differs from the SWF domain and thus flash security blocks JS/Flash from working.
Additionally, all requests from the page on alan-ng.net result in HTTP 301 redirects to www.alan-ng.net - which is OK, but the top-level HTML page should also do that.
So the solution is to make sure your HTML page request redirects to www.alang.net, ensuring the browser loads the SWF from the same domain.
Oh, sorry, you're quite right. Apparently there have been competing .htaccess files on my server - affecting only this folder - which I didn't notice for years. You're right, once I fixed the .htaccess problem (to restore the rule of enforcing the canonical url of www.alan-ng.net) for this folder, the SM2 problem in FF13 went away, too.
EMPLOYEE0Ah, good stuff. I had a sneaky suspicion that there was a separate issue here, unrelated to a Firefox 13 upgrade.
Once in a blue moon, a browser or Flash plugin update can mess up the interaction between JS/Flash and that's usually fixed by an uninstall and clean install of Flash. Sounds like you got it sorted, though!
Nevertheless, there is still something unique to SM2 in FF13 (and perhaps FF12 or 11, who knows) that made domain-name disagreement kill SM2, whereas the domain-name disagreement did not affect the other browsers. And why did the demo files run as-is a local file fail in FF13? Seems worth investigating ...
In any case, thanks for your diagnosis, much appreciated!
EMPLOYEE0Ah yes, I forgot to mention - it appears there has been some sort of regression beginning with Firefox 9 or 10, I think, where offline (file:// or c:// based, offline, non-HTTP) pages with SM2 stopped working due to JS Flash interaction (ExternalInterface) being blocked or broken somehow even with Flash's security permissions being granted via the Flash Player Security Settings panel.
I think I need to make a test case for this issue and submit it to Mozilla, if one hasn't already been made. It's a rather weird issue, and I overlooked it myself if only because I have been in the habit of testing and developing SM2 over HTTP rather than purely offline for the better part of the last year.
Regarding the domain stuff, I'm not sure what is going on there; it may be that security rules were tightened up, but my recollection is that www.example.com vs. example.com have always been considered as different domains by Flash in terms of security, and thus JS+Flash would break down in the mixed-domain case.