Bugzilla – Bug 5821
Web interface quirks when using Firefox 3.0 alpha releases ("minefield")
Last modified: 2009-07-31 10:15:03 UTC
I've been following the Firefox 3.0 development tree (Ubuntu gutsy) for a month or so now and also the SqueezeCenter 7.0 nightlies. I've found that the left pane (my music, internet radio, etc) will not show with FF3 unless you first hit 'reload'. Works fine on FF2. I can post a screenshot if necessary, but the left pane text simply doesn't display. All of the other UI elements do. I realize the FF3 effort is in alpha but I don't have any rendering problems on any other sites so I figured I would start here.
That's very likely a caching issue. Clean the cache and reload again - it should be working then. We've had similar reports for almost any browser out there. I'll have to come up with some better way to prevent this type of problem.
I've cleaned the cache many times, it doesn't seem to be the problem. I can use a brand new FF profile and it still occurs on the first load (and subsequent loads). The only way to get the pane to display is to actually hit the refresh button. Once you close the browser and type in the link (or use a bookmark), you again are faced with the blank left pane. Hitting refresh again loads the content.
probably going to need a version of firebug that runs with FF3 in order to debug any problem loading the scripts for FF3.0
This is still happening as of the 10/22 nightlies of both FF 3.0a9pre and SlimServer 7.0a. I also noticed that the new settings page has a similar problem. The content pane is blank until you click a tab, even though the 'basic settings' tab is active at the start. I just verified that this does not occur on FF2. There are going to be a lot of people upgrading to FF3 soon with the upcoming beta release. It should be out generally before the end of the year and then there will be even more. kdf, it doesn't look like anyone is working on a FF3 version of firebug. Is there any other technique that you can suggest to help diagnose the problem?
Another quirk is that using the default skin, changing the volume control by clicking the tickmarks on the now playing screen is 'off by one'. In other words, click the last tick '11' and the volume display goes to second to last '10'. The only way to get 100% volume is to use the button to the right of the tickmarks to increment to 11. Again, not observed on FF2.
Not going to sweat these issues for the 7.0 release.
OK, I've been keeping tabs on the latest from Firefox and SqueezeCenter 7.0. The latest builds of both have almost completely resolved the compatibility issues. The only remaining issue is that the volume buttons are 'one off' still on FireFox 3.0b1. In other words if you click the button corresponding to 10/11, you actually get 9/11 volume.
As FF3 is getting closer... do you still see these issues?
The only remaining FF3 issue (using FF3 beta4 on Ubuntu) is that the volume control buttons are still offset by nearly one "block". The only way to get 100% volume is to click on the extreme right edge of the 11th block. Currently running: SqueezeCenter Version: 7.0.1 - 17976 - Debian - EN - iso-8859-1
change 19020 - remove (broken) browser specific correction values using correct maths...
Looks great now, thanks Michael.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC