Bugzilla – Bug 1765
Non-functional header links in ExBrowse2 skin
Last modified: 2008-08-18 10:54:16 UTC
I've been using 6.1 checked out of svn for a while now. Updated this evening to 3613 and noticed that some of the ExBrowse2 files had changed. When I started the server, it seemed to have forgotten my preferences. When I clicked any of the links in the header of the web interface (home, server settings, help) I would get no response. No error messages, either. Thinking my checkout was biffed somewhere, I removed svn files and SlimServer cache directory and downloaded the 6.1 nightly for 7-5. I get the same behavior. MacOS X 10.4.1 Firefox 1.0.4 ExBrowse2 skin Default2 skin, BTW, seems to be okay.
By "the same behavior" from the nightly, I meant the non-working header links and not forgotten preferences. The nightly found my preferences file and I'm listening to SoftSqueeze on my PowerBook again. I would update and try this on my Gentoo Linux box, but I'm reluctant to break functionality on my main home SlimServer install.
jacob, anything you can do with this?
Some addtional info: Safari 2.0 (412) does not exhibit this problem with the header links, but it is quite an ordeal to get everything loaded completely. Safari loops between Connecting... Initializing... Loading... Lost connection, reloading... over and over. After fiddling with the stop/reload button I can get it loaded and everything functions correctly. Enabling debug for ui and http just shows the same resources accessed again and again. No apparent errors. Firefox has less of an issue loading and initializing, but clicking any of the header links generates NO output to the log with the ui and http debug options enabled. The problem seems to be on the Firefox end. A Firefox bug, perhaps? Hope this helps. Can send log info if that is useful.
I needed to remove a drive from the Linux box, so I decided to update from svn and try to reproduce this with Linux Firefox. No issues; ExBrowse2 works perfectly. So, I tried the 7-6 nightly for MacOS X and I get the same behavior as before with Firefox - no response clicking any of the header links. I'm willing to bet this is only an issue with FF 1.0.4 on MacOS X - at least with 10.4.1.
Jacob - think this can be fixed for 6.1?
Fixed in change 3636. Turns out Firefox is picky about modifying Event objects, so the code in JXTK to standardize the event properties was dying. This probably broke a lot of other things as well, but it's fixed now.
Fix verified - header links now work properly. Also, initialization seems much faster. Thanks, Jacob.
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!