mint.com has problems moving between transaction list pages

RESOLVED INVALID

Status

()

Core
General
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: vlad, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(Not tracked)

Details

(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.

Comment 1

9 years ago
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
I only see a listTransaction request when I hit the "next" link on a transaction list; the data that's returned is:

{"count":377,"account":{"schema":["count","id"],"set":[[1268,0],[13,809172],[15,959848],[686,809173],[377,809171],[23,959843],[154,959847]]},"detailAccount":"","pagination":"<li class=\"prev wide\"><a href=\"javascript:void(null);\" rel=\"0\">prev<\/a><\/li><li class=\"\"><a href=\"javascript:void(null);\" rel=\"0\">1<\/a><\/li><li class=\"empty\">2<\/li><li class=\"\"><a href=\"javascript:void(null);\" rel=\"100\">3<\/a><\/li><li class=\"\"><a href=\"javascript:void(null);\" rel=\"150\">4<\/a><\/li><li class=\"\"><a href=\"javascript:void(null);\" rel=\"200\">5<\/a><\/li><li class=\"\"><a href=\"javascript:void(null);\" rel=\"250\">6<\/a><\/li><li class=\"\"><a href=\"javascript:void(null);\" rel=\"300\">7<\/a><\/li><li class=\"\"><a href=\"javascript:void(null);\" rel=\"350\">8<\/a><\/li><li class=\"next wide\"><a href=\"javascript:void(null);\" rel=\"100\">next<\/a><\/li>","maxTxnRows":50}

(Hopefully I'm not handing out account numbers here, but none of that looks sensitive ;)

Comment 3

9 years ago
Looks like the data.getResponseHeader["Content-Type"] provided by the YUI JavaScript Framework AJAX system is empty. This is causing the code to not understand that it was passed a JSON object. So instead it passes the textual string through to line 950 in transaction.js. Then when it tries to access a function of the expected JSON object, it crashes.
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.
Assignee: general → nobody
Component: JavaScript Engine → General
Flags: blocking1.9.1+
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?

Comment 6

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

Updated

9 years ago
Flags: blocking1.9.1+ → blocking1.9.1-
You need to log in before you can comment on or make changes to this bug.