User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 In Firefox 3 and other browsers it's possible to click on individual transactions on this page and edit their name, category, etc. either inline or in a javascript drop-down box. In Firefox 3.1 clicking does nothing. There are no errors in the error console. Reproducible: Always Steps to Reproduce: 1. Go to Mint.com transactions page 2. Click on any transaction 3. Actual Results: Nothing happens Expected Results: Javascript drop-down box opens I do not believe there's a workaround for this bug.

First try the firefox safemode: http://support.mozilla.com/en-US/kb/Safe+Mode If you get the issue still in the safemode then please open about:config , confirm the warning, enter jit in the search box and disable the jit.content to false. Try your page and if that doesn't change the issue then switch it back on.

I still have the problem in Safe Mode, and with JIT.content = false.

Problem is that it can't be tested because the page requires a login. A testcase or a test login would be required, especially if it worked correctly in earlier versions: https://developer.mozilla.org/en/Reducing_testcases

Shawn, is this the bug you were seeing?

(In reply to comment #4) > Shawn, is this the bug you were seeing? Yes, and I believe vlad was seeing this too.

Getting a reduced testcase seems difficult, it's a fairly large web 2.0 page and there's a lot of javascript for the UI. But, unless someone else has already found a regression window, I will try to get one tonight.

Regressed between 2008-10-17-03-mozilla-central firefox-3.1b2pre.en-US.win32 and 2008-10-18-03-mozilla-central firefox-3.1b2pre.en-US.win32

Based on comment 7, it would be something in here-ish: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-10-17+04%3A00&enddate=2008-10-18+04%3A00 Wonder if it was bug 460333, or bug 415707? --> Core::General, regardless.

Just from the bug description, sounds most likely to be 415707. But we won't be able to fix it without a testcase.

(In reply to comment #5) > (In reply to comment #4) > > Shawn, is this the bug you were seeing? > Yes, and I believe vlad was seeing this too. Actually, now that I read this bug closer, I don't even get to this point -- 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 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. I don't have to attempt to edit anything; same errors happen with or without jit enabled, with or without addons. This might well be a different bug, it looks like, since for me the site is completely broken, as opposed to just double-clicks not doing anything.

Vlad, this bug doesn't require double-click, you just have to click once on the transaction and it should be editable. I can't reproduce your bug -- I don't see any other problems when loading mint.com.

Using DOM inspector and Firefox 3.0, I was able to reproduce the buggy 3.1 behavior when I deleted an invisible layer containing a table which apparently overlays the visible table containing transactions. After doing so, transactions would no longer be highlighted/editable when clicked. The top-level structure of that DIV element is as follows: <DIV id="layer"><DIV id="mask" class="hide" style="opacity: 0;"> </DIV><div xmlns="http://www.w3.org/1999/xhtml" style="overflow: visible; height: 0px;"><DIV xmlns="" id="pop-categories" class="pop" style="left: -9999px; z-index: 106;"> etc... I've also attached one highlighted transaction element which is contained in the DIV above -- when it's deleted by itself, I also reproduce the bug.

The transaction edit bar you see when clicking on a transaction, is actually an overlay in the div#layer that is absolutely positioned. Unfortunately, as it is currently written, JavaScript errors occurring before the overlay is rendered, cause the overlay to never be rendered and the page to not work. This is probably related to the Line: 950 issue with "https://wwws.mint.com/sc/ph767.38/js/transaction.js". I'll download the beta release and see if I can't figure out the cause. -matt snider @ Mint.com

On closer inspection my initial thoughts were probably wrong, I was just misreading the venkman debugger. What is actually happening is that at mint we extend String.prototype with a method 'toJSON', which wraps the 'json.js' logic from http://www.json.org/ to work properly with large string in Safari 2. This call works in FF2 and previous version of FF3, however, it doesn't seem to work with the 3.1.2 beta. Instead, my 'toJSON' method is never called and instead of creating a JSON object, the value remains as a string. Is there a new method 'toJSON' added to String.prototype in FF3.1.2 that could be breaking this logic?

(In reply to comment #15) > Is there a new method 'toJSON' added to String.prototype in FF3.1.2 that could > be breaking this logic? Yes - String.prototype.toJSON does not evaluate to undefined. I can't find the bug that added this though...

Shawn, I'm pretty sure that toJSON change (460333) is in the regression window I found (see comment 7 and comment 9).

(In reply to comment #17) > Shawn, I'm pretty sure that toJSON change (460333) is in the regression window > I found (see comment 7 and comment 9). When I looked at the patch in that bug I only saw the Date changes, but I see that it also did it for Number and String now. Bug 460333 did cause this. I guess the question now is how can we make this not break, or do we need to get the word out that people should be checking for this. This did make it into beta 2, which we said would be the last time we made web compat breaking changes, but that doesn't always mean we should take them. CC'ing blizzard from evangelism. Not sure if we should get json.org to update their source (and then have all the sites that use it update), or find a fix on our end (or both!).

(In reply to comment #15) > > Is there a new method 'toJSON' added to String.prototype in FF3.1.2 that could > be breaking this logic? Hi Matt, Sorry I broke mint.com. That said, this should be writable, so you can override String.prototype.toJSON with your own. Are you checking that it doesn't exist before doing so? This is part of ES3.1, and it's caused some small similar problems. I'd be curious to know whether the latest IE8 beta exhibits these issues, since it should contain the same functionality.

I don't have specific data, but I have to imagine that the json.org libraries are widely used. We had to make a change for the top level JSON object. I think the issue was that it wasn't writable. I take it this is, but is still causing issues?

(In reply to comment #20) > I don't have specific data, but I have to imagine that the json.org libraries > are widely used. Per comment 15, they are patching String.prototype.toJSON with a fix for Safari 2. I don't think 3.1 breaks the json.org libraries themselves.

'k, thanks.

Moving to JS Engine given that this seems to be an issue with String.prototype.toJSON per comment 15, etc.

This works for me now in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20090109 Shiretoko/3.1b3pre RTSE/1.1.0.20081207 ID:20090109054324 Should we morph this to just the JS bug now?

Mint has just released version ph767.53, which fixed the conflicting function name, so that it should work correctly in FF3 beta now. thanks, -matt

matt, could you show us the code you had to change to make this work?

Rereading this bug, it looks like a name detection test gone awry. The same thing happened to Facebook when they were looking for the global JSON object (this bit IE8 before us).