User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 Going to a public folder (e.g. the URL I supplied above) or the private space (http://idisk.mac.com/sam247) results in a completely blank page. Reproducible: Always Steps to Reproduce: 1. Visit http://idisk.mac.com/sam247-Public Actual Results: Blank page comes up. Expected Results: Expected content to be displayed.
Created attachment 324494 [details] comparisation FF3&Safari3 Its a screenshot of Firefox Release Candidate 2(left) and Safari 3.1.1(right). Safari display's the page as it should, Firefox doesnt. Url: http://idisk.mac.com/pj.bos-Public?view=web or any other iDisk
As far as I'm concerned, this is a critical bug that needs to be addressed before final release. If Firefox 3 is released this way, NO one will be able to access iDisk, period. Unless, of course, until Apple rereleases .Mac as "MobileMe" and changes the interface. But who's to say MobileMe will show up properly, either?
Marking as critical. Also modified OS's this bug exists on, fails on Windows, Mac, & Linux.
Severity: normal → critical
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 3.0 Branch
Confirming and adding regression keyword: this worked in Firefox 2. Ria: can you help us find a regression range? It's a little too late in the game for us to block the final release on this issue at this time. We'll want to consider it for a branch release, though. I want to suspect that this is a dupe or similar to bug 405903, but I don't see anything in the error console when I load this page. As long as I'm using an RC, I can see that I'm getting the HTML content sent to me (nightlies get bounced to a page that tells them to use Firefox 1.0.4 or later) but it's not rendering.
Severity: critical → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, relnote
Thanks for confirming this, Mike. Hope it's ironed out.
If bug 305873 broke this, it's likely because the site is using unclosed script tags in HTML (e.g. <script src="..." />). It shouldn't do that - I don't think we're going to revert that change (it's compatible with IE, fwiw).
Assignee: nobody → english-us
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: general → english-us
Version: 3.0 Branch → unspecified
Thanks guys. I reported this to Apple, let's just hope I don't get some silly canned response asking me to check my Internet connection. :P I was very specific as to what the problem is. Strange, though, that even in XHTML, <script> is the only tag that breaks the rules and doesn't like being called as <script />.
Sorry guys, but I'm going to have to retract my agreement that Apple is at fault here. Look here: http://www.samhulick.com/script_test.html I have a proper DOCTYPE header and everything. It's XHTML 1.0 strict. W3C says it's A-OK: http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.samhulick.com%2Fscript_test.html So, is W3C wrong?
When I tried to use iDisk right now using Minefield, it redirected me to this page: http://idisk.mac.com/js/web/browser_req.html. Do we have any Apple contacts whom we can notify of this issue?
(In reply to comment #13) > Do we have any Apple contacts whom we can notify of this issue? When we had this problem before (e.g. bug 325962), I think we just had dotMac users complain about the UA sniffing via whatever channels are exposed to them :(
Summary: Firefox 3 beta 5 does not work with iDisk web interface → mac.com - Firefox 3 beta 5 does not work with iDisk web interface
Is this still a problem? I don't have a MobileMe subscription, so I can't test it, but I'd be mildly surprised if the Web interface is still broken after all this time. Comment 13 really ought to be filed as its own TE bug. cl
Summary: mac.com - Firefox 3 beta 5 does not work with iDisk web interface → mac.com (MobileMe) - Firefox 3 beta 5 does not work with iDisk web interface
> Http/1.1 Service Unavailable The service is long gone.
Assignee: english-us → nobody
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Component: English US → Desktop
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.