Bugzilla – Bug 2199
Exbrowse 3 "Internet Radio" link redirects to an external site
Last modified: 2006-08-05 17:56:58 UTC
clicking on the "Internet Radio" link in the latest version of ExBrowse 3 opens up http://www.htmlgoodies.com/ in the "radioframe". See image posted here: http://forums.slimdevices.com/showthread.php?t=16621
Jacob, any thoughts? can't seem to reproduce this one myself.
Nor can I... Yann - does this happen on any other browsers / systems?
was the server still running after you got this link? if a local address fails to respond, some systems will end up grabbing another bogus site that has been rigged to come up via a dns on the local host name. The proxy at work used to really annoy me when it would redirect to localhost.com, for instance.
I'm running Firefox (latest version)... haven't tried it in IE yet. I don't beleive I'm running any sort of proxy (except for MMM... which connects to Slimserver via it's internal proxy). Does that count? As far as I know the server was up and running.... no crashes. Just this wierd page loading in the frame. All the other links work just fine. I'm away from my slimserver rig right now (I'm at work) but let me know what things I can test tonight, and I'll try to do some troubleshooting.
Does anybody know where that htmlgoodies URL came from? I'm betting that this is a browser bug where it's grabbing the wrong URL or page from the cache...
I have no idea where it's getting that URL. The weird thing is, the Radio page uses the same JS pseudo-frame code as the Help page (the links themselves are actually in index.html; the link loads blank.html with a callback to swap out the content). If that was breaking somehow, it should affect both Radio and Help. Huh. Adware of some sort maybe? (Grasping at straws here...)
Hah! Funny you should mention Help... it =does do= the same thing (just noticed a minute ago)
In IE both the radio and help links bring up a "The page cannot be displayed" page. Looks like the JS pseudo-frame code (er... whatever that is) may be the problem afterall.
d_http and d_remotestream perhaps? both links work fine in ie and firefox at work, safari and firefox at home so can't offer much aside from more straws. I'd say it isn't anything wrong with the links, or the ls code behind it but obviously this case doesn't like the url used in the js code.
I"m not sure that there's anything we can do in slimserver to fix this. Closing, reopen if you have an idea.
Whoops! Turns out it is reproducible - provided ExBrowse3 is set as the /default/ skin. There was a wayward slash in the URL (being appended to webroot) that caused the URL to wind up as "//html/home.html?...", which causes Firefox to try to resolve http://html/ and go to the external site. Fixed in change 4699.
Woo Hoo! Thanks Jacob!
Remarking this as FIXED.