(Split off from bug 469627 comment 11 -- i'm only guessing this is core:js, but i'm not sure) Upon loading mint.com, eventually I see this error: Error: F.response.getStatus is not a function Source File: https://wwws.mint.com/sc/ph767.38/js/library.js Line: 4455 That one might be harmless though, but the following isn't.. If I then click on an account, I'll see that error again when load finishes. If I click on a page # to go to a next page, the contents get grayed out (as normal), and then: Error: h.getCount is not a function Source File: https://wwws.mint.com/sc/ph767.38/js/transaction.js Line: 950 And things break at that point. Same errors happen with or without jit enabled, with or without addons.
The line 4455 shouldn't be the problem. That is related to the update message that appears on the top of the page and should be self-contained. The second error line 950 is more serious and 'h.getCount' should not be null. I'd have to see the response of 'https://wwwws.mint.com/listTransaction.xevent' to know for sure what the issue is. The server sends a JSON response, which is converted to an object before being passed into the 'onTransactionList' function, where the null pointer is occurring. -Matt Snider @ Mint.com
Hmm.. Jonas, could the access controls stuff in XHR have caused the above? It sounds like getResponseHeader isn't returning the right thing here. The server is sending back "text/json;charset=UTF-8" according to tamper data.
9 years ago
Assignee: general → nobody
QA Contact: general → general
The Access-Control stuff really shouldn't be the problem here. It stays out of the way when doing a same-site request. Additionally, even if this was a cross-site request (or if there is a bug causing us to think it is), the "content-type" header can be read cross site. You are using data.getResponseHeader("Content-Type") though, right? Not the brackets used in comment 3?
Jonas, One of my comments seems to be missing. I realized later that it wasn't an issue with the content type, I was just misreading the venkman debugger, as I haven't used it in almost 2 years. The issue is that in FF3.0.2b the native String has a 'toJSON' method added to it. At Mint, we add our own 'toJSON' string to String.prototype, but only if it didn't already exist. I'm not sure what the 'toJSON' method Mozilla attaches does, but without passing any parameters it does not return an Object like our method does. This causes the program to crash @ line 950 of transaction.js, when it attempts to read a value from the JSON object. I have fixed the issue on our test server by overriding the Mozilla attached 'toJSON' method. However, we don't have another public site rollout scheduled until after the holidays, so you won't see it fixed until sometime in January. -matt @ Mint.com
Cool, sounds like this is a WONTFIX bug then. I think the toJSON function actually converts js objects *into* JSON format. I.e. it creates the serialization. I think it's there so that you can override the default serialization of a given object. IIRC this is part of ECMAScript 3.1. So in other words I'd probably stay away from using the function name 'toJSON' for what you are doing, as it's intended for something else. Maybe calling it 'parseAsJSON' or something would be more safe in case you start using the built-in JSON object that is available in FF3.1
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
(actually, it's invalid given that adding .toJSON was by design)
Resolution: WONTFIX → INVALID
You need to log in before you can comment on or make changes to this bug.