mac.com (MobileMe) - Firefox 3 beta 5 does not work with iDisk web interface

RESOLVED INVALID

Status

Tech Evangelism
Desktop
--
major
RESOLVED INVALID
10 years ago
4 years ago

People

(Reporter: CaptSaltyJack, Unassigned)

Tracking

({regression, relnote})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.

Comment 1

10 years ago
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
(Reporter)

Comment 2

10 years ago
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?
(Reporter)

Comment 3

10 years ago
Marking as critical.  Also modified OS's this bug exists on, fails on Windows, Mac, & Linux.
Severity: normal → critical
Flags: blocking-firefox3?
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
Flags: blocking1.9.0.1?
Flags: blocking-firefox3?
Flags: blocking-firefox3.1?
Flags: blocking-firefox3-
Keywords: regression, relnote
(Reporter)

Comment 5

10 years ago
Thanks for confirming this, Mike.  Hope it's ironed out.
Regression range is
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-01-31+12%3A00&maxdate=2006-01-31+23%3A00
When I switch off JavaScript I see the same incomplete screen on all builds, so maybe there is something wrong with the script (Bug 305873). 
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
Flags: blocking1.9.0.1?
Flags: blocking-firefox3.1?
Flags: blocking-firefox3-
Product: Firefox → Tech Evangelism
QA Contact: general → english-us
Version: 3.0 Branch → unspecified
Indeed:

	var isIE = (document.all);
	if (isIE) {
...
	} else {
...
		'<script src="/js/web/DavUtil.js" TYPE="text/javascript" />' +
...
Duplicate of this bug: 440725
(Reporter)

Comment 10

10 years ago
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 />.
(Reporter)

Comment 11

10 years ago
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?

Updated

10 years ago
Duplicate of this bug: 441983

Comment 13

9 years ago
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?
Blocks: 334967
(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

Comment 15

8 years ago
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

Updated

8 years ago
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.