http://www.axelmusic.com/productDetails/883929099252 fails to load in FF4.0b7, but loads in Safari.

RESOLVED WORKSFORME

Status

()

Core
Networking
RESOLVED WORKSFORME
8 years ago
8 years ago

People

(Reporter: bwinton, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
I think all the info is in the title, but am happy to provide any extra info you may think is helpful.

Thanks,
Blake.

Comment 1

8 years ago
WFM on linux32 on trunk nightlies.
wfm on Seamonkey trunk, win32

Comment 3

8 years ago
Wfm also on linux 64, but loading the url does trigger assertions from nsHTMLDocument.cpp line 945 (cache-entry in nsHttpChannel is not available).

CCing bz who knows nsHTTPChannel

Comment 4

8 years ago
Forgot to mention that comment #3 refers to a trunk build. Can reporter indicate whether this is still a problem with e.g. a recent nightly build?
(Reporter)

Comment 5

8 years ago
It works for me, now that I've upgraded to 4.0b8, so I'm marking it as resolved.

Thanks everyone!
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Bjarne, what's the actual question for me?

Comment 7

8 years ago
(In reply to comment #6)
> Bjarne, what's the actual question for me?

I was curious about that assertion (nsHTMLDocument line 945): The fact is that the charset is not stored in this case (since the cache-entry is unavailable at the time of the call), and the question is what the consequence this has for nsHTMLDocument (comment #3 says "bz who knows nsHttpChannel" but I meant to say "bz who knows nsHTMLDocument"). If there is no consequence, I'd suggest to remove the assertion, otherwise we can easily store the charset-setting temporarily in nsHttpChannel and move the setting to the cache-entry whet it becomes available.
There's a consequence: subsequent reloads might end up with the wrong charset.

Comment 9

8 years ago
I guess this is undesirable?

Comment 11

8 years ago
Glad we sorted that out...  ;) I've created bug #622357 to track this issue.
You need to log in before you can comment on or make changes to this bug.