.axelmusic fails to load in FF4.0b7, but loads in Safari .com/product Details/883929099252 .
I think all the info is in the title, but am happy to provide any extra info you may think is helpful. Thanks, Blake.
WFM on linux32 on trunk nightlies.
wfm on Seamonkey trunk, win32
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
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?
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?
(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.
I guess this is undesirable?
Well... generally, yes. ;)
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.